From duke at openjdk.org Sun Sep 1 03:53:28 2024 From: duke at openjdk.org (Oliver Schmidtmer) Date: Sun, 1 Sep 2024 03:53:28 GMT Subject: Integrated: 8334124: Rendering issues with CSS "text-shadow" in WebView In-Reply-To: References: Message-ID: <6MAwkjP-SVkl_hAfW8syRqRORUUY5Yc8M-nMV8IL_lg=.5f461f7e-88b5-436c-adef-78bd084caf24@github.com> On Tue, 27 Aug 2024 15:55:47 GMT, Oliver Schmidtmer wrote: > On a Shadow state update with cleared shadow, the new values were not transmitted to the Java GraphicsDecoder This pull request has now been integrated. Changeset: e0ceafb7 Author: Oliver Schmidtmer Committer: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/e0ceafb7dba15b4faa683c336828e79f19a59d30 Stats: 84 lines in 2 files changed: 84 ins; 0 del; 0 mod 8334124: Rendering issues with CSS "text-shadow" in WebView Reviewed-by: kcr, jbhaskar ------------- PR: https://git.openjdk.org/jfx/pull/1547 From mstrauss at openjdk.org Sun Sep 1 12:31:06 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 1 Sep 2024 12:31:06 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v26] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 48 additional commits since the last revision: - Merge branch 'master' into feature/interpolatable - remove StyleConverter.WithReconstructionSupport - fix line separators - StyleableStringProperty should be transitionable - non-interpolatable values should always transition discretely - only call get() when necessary - add more documentation - replace reconstruction annotation with interface - interpolate integers in real number space - replace StyleConverter.SupportsDeconstruction interface with annotation - ... and 38 more: https://git.openjdk.org/jfx/compare/a8e9e109...2337ca98 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/9bdea0a4..2337ca98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=25 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=24-25 Stats: 28890 lines in 624 files changed: 15229 ins; 7889 del; 5772 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mariushanl at web.de Mon Sep 2 04:12:13 2024 From: mariushanl at web.de (Marius Hanl) Date: Mon, 2 Sep 2024 04:12:13 +0000 Subject: =?UTF-8?Q?Aw=3A=C2=A0New_CSS_parser_for_JavaFX?= In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From jvos at openjdk.org Mon Sep 2 07:25:55 2024 From: jvos at openjdk.org (Johan Vos) Date: Mon, 2 Sep 2024 07:25:55 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit Message-ID: When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. ------------- Commit messages: - Provide NUM_COMPILE_THREADS to webkit build, allowing to control the number of Changes: https://git.openjdk.org/jfx/pull/1554/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1554&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339335 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1554.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1554/head:pull/1554 PR: https://git.openjdk.org/jfx/pull/1554 From arapte at openjdk.org Mon Sep 2 09:42:24 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 2 Sep 2024 09:42:24 GMT Subject: RFR: 8338701: Provide media support for libavcodec version 61 In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 21:02:41 GMT, Alexander Matveev wrote: > - Added support for libavcodec 61. > - Updated AV plugins to use new APIs instead of APIs which were removed in 61. > - We still using some deprecated APIs. > - `reordered_opaque` replacement exist in 61 which is used to pass user data between compressed frame and uncompressed. In 61 this variable is pointer to `void` instead of `int64_t`. We can use new `opaque` to pass PTS, but it is not documented way to pass PTS between compressed and uncompressed frames. Updated code will be using `AVPacket.pts/AVFrame.pts` which is documented way to provide PTS. > - Tested on Ubuntu 24.10 with 61 and 24.04 with 60 with all supported formats. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1552#pullrequestreview-2275164133 From mstrauss at openjdk.org Mon Sep 2 12:11:29 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Sep 2024 12:11:29 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v16] In-Reply-To: References: Message-ID: On Sun, 4 Aug 2024 22:56:17 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> use HashMap.newHashMap() > > This is still a large PR, and I do want to help reviewing it, I will do my best to look it over further this week. @hjohn @andy-goryachev-oracle I think that I've addressed all comments so far. To summarize the aspects that will not be covered in this PR: Interpolation for fonts and a wholesale change of cssref (adding a new column for all properties) will be done separately. The discussion about a place to collect JEP-style design documents is not resolved yet, and will also be done separately. Do you think there is anything left preventing this PR from moving forward? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2324600126 From jbhaskar at openjdk.org Mon Sep 2 12:12:55 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 2 Sep 2024 12:12:55 GMT Subject: [jfx23u] RFR: 8334124: Rendering issues with CSS "text-shadow" in WebView Message-ID: A clean backport to jfx23u. The fix is for Rendering issues with CSS "text-shadow" in WebView . I have tested the fix it is working with the fix and failing without the fix. ------------- Commit messages: - Backport e0ceafb7dba15b4faa683c336828e79f19a59d30 Changes: https://git.openjdk.org/jfx23u/pull/17/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=17&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334124 Stats: 84 lines in 2 files changed: 84 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx23u/pull/17.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/17/head:pull/17 PR: https://git.openjdk.org/jfx23u/pull/17 From jhendrikx at openjdk.org Mon Sep 2 12:45:02 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 2 Sep 2024 12:45:02 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v9] In-Reply-To: References: Message-ID: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Reject CSS where compound selectors don't consist of simple selectors ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1333/files - new: https://git.openjdk.org/jfx/pull/1333/files/875c1a88..86e3f4fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=07-08 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1333.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333 PR: https://git.openjdk.org/jfx/pull/1333 From jhendrikx at openjdk.org Mon Sep 2 12:45:02 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 2 Sep 2024 12:45:02 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v7] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 12:05:43 GMT, John Hendrikx wrote: >> `SimpleSelector` was deprecated for removal (from the public javafx.css package). Now that it is moved to the internal package, the deprecation on that was also removed. The `SuppressWarnings` is therefore no longer needed here as the deprecation is no longer present on the now internal `SimpleSelector` type. > > The diff seems to show I did not remove that line, but it should no longer be needed. I'll check. The line was correctly removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1740868353 From jhendrikx at openjdk.org Mon Sep 2 12:47:28 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 2 Sep 2024 12:47:28 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v9] In-Reply-To: References: Message-ID: <6kY-kPHg9OJZUY2EwdY-PoJvHXeziZ9qIGeqWneusig=.424b016a-3541-4de9-8c07-10f5cad0057f@github.com> On Mon, 2 Sep 2024 12:45:02 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Reject CSS where compound selectors don't consist of simple selectors I made the small change suggested in `BinarySerializer` and created a CSR. I wasn't entirely sure on the "compatability" part and whether or not it should take into account removal of deprecated classes. With the removal of `SimpleSelector` and `CompoundSelector` code that managed to use them (by casting) will no longer compile for sure. I'm not 100% sure if it could possibly be binary compatible (ie. if a previously compiled class casts to these types) but I suspect it won't be. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2324677111 From jhendrikx at openjdk.org Mon Sep 2 15:40:33 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 2 Sep 2024 15:40:33 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v26] In-Reply-To: References: Message-ID: On Sun, 1 Sep 2024 12:31:06 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 48 additional commits since the last revision: > > - Merge branch 'master' into feature/interpolatable > - remove StyleConverter.WithReconstructionSupport > - fix line separators > - StyleableStringProperty should be transitionable > - non-interpolatable values should always transition discretely > - only call get() when necessary > - add more documentation > - replace reconstruction annotation with interface > - interpolate integers in real number space > - replace StyleConverter.SupportsDeconstruction interface with annotation > - ... and 38 more: https://git.openjdk.org/jfx/compare/37c6136d...2337ca98 Q1: I see a lot of work in the code to handle reverse transitions. Is this actually part of the CSS specification? Q2: Reversal detection seems very limited. If I change a value multiple times within the duration of the animation, then reset it to its original value, then I think the reversal code will not trigger. As an example, let's say I'm animating scrolling. I'm at the top. I press page down once and then press home. The value changes for example from 0 -> 20 -> 0 -- this triggers the reversal code, and the animated scrolling will quickly return to its top position. However, if I do 0 -> 20 -> 40 -> 0 (page down, page down, home), then I think the reversal is not detected and I'm left with a very slow return to the top position. Q3: How does the user do calculations for properties that are being interpolated? Let's say I have a simple system where the `+` and `-` change a value by +10 and -10. So I press `+`; I read the current value, add 10 and set it (say from 0 to 10). Now I press `+` again. Reading the current value would get me some intermediate animated value. Adding 10 to this is not what the user would expect (they would expect to go to 20, not to 15 if the animation was only halfway completed). As an example, I've implemented (without CSS transitions) a smooth scrolling system; this system tracks the target value to do the scrolling. Pressing 3x page down in a row will go 3 pages down, no matter what the state of the animation. With CSS transitions, should the programmer be aware of the interpolation (which may be added later in CSS) and track their own "target" value to make this work as you'd expect? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2325001849 From mstrauss at openjdk.org Mon Sep 2 16:27:28 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Sep 2024 16:27:28 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v26] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 15:37:38 GMT, John Hendrikx wrote: > Q1: I see a lot of work in the code to handle reverse transitions. Is this actually part of the CSS specification? Yes, it's a sizable chunk of the specification: https://www.w3.org/TR/css-transitions-1/#starting > Q2: Reversal detection seems very limited. If I change a value multiple times within the duration of the animation, then reset it to its original value, then I think the reversal code will not trigger. As an example, let's say I'm animating scrolling. I'm at the top. I press page down once and then press home. The value changes for example from 0 -> 20 -> 0 -- this triggers the reversal code, and the animated scrolling will quickly return to its top position. However, if I do 0 -> 20 -> 40 -> 0 (page down, page down, home), then I think the reversal is not detected and I'm left with a very slow return to the top position. There doesn't seem to be a one-size-fits-all solution for faster transition reversal. The CSS specification [acknowledges](https://www.w3.org/TR/css-transitions-1/#reversing) this: _Note that these rules do not fully address the problem for transition patterns that involve more than two states._ The algorithm as prescribed by the specification is one of several algorithms that were considered by the W3C working group back in 2013. It is clearly tuned for two-state application scenarios, and might simply not be the right solution for your problem. I've thought a lot about the problem, and while it may be possible to come up with an algorithm that covers more edge cases, that takes a huge toll on the complexity/maintainability budget. > > Q3: How does the user do calculations for properties that are being interpolated? Let's say I have a simple system where the `+` and `-` change a value by +10 and -10. So I press `+`; I read the current value, add 10 and set it (say from 0 to 10). Now I press `+` again. Reading the current value would get me some intermediate animated value. Adding 10 to this is not what the user would expect (they would expect to go to 20, not to 15 if the animation was only halfway completed). > > As an example, I've implemented (without CSS transitions) a smooth scrolling system; this system tracks the target value to do the scrolling. Pressing 3x page down in a row will go 3 pages down, no matter what the state of the animation. With CSS transitions, should the programmer be aware of the interpolation (which may be added later in CSS) and track their own "target" value to make this work as you'd expect? I don't think this would work at all, because you're setting the value programmatically. You'll only get a transition if you let the CSS system set the value. If you do this, and then query the value of the property under transition, you will get an intermediate value. This simply wouldn't work otherwise, considering how JavaFX properties work. We can't have properties change their value over time, but when you look at them programmatically, they already have the target value. This behavior is also consistent with the [specification](https://www.w3.org/TR/css-transitions-1/#transitions): _Transitions are a presentational effect. The computed value of a property transitions over time from the old value to the new value. Therefore if a script queries the computed value of a property (or other data depending on it) as it is transitioning, it will see an intermediate value that represents the current animated value of the property._ ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2325065092 From jhendrikx at openjdk.org Mon Sep 2 16:36:31 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 2 Sep 2024 16:36:31 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v26] In-Reply-To: References: Message-ID: <05CaXerrdKVe3nPPSbFAZo8RxO7X0QFvcIGM0SWwd9s=.ce734cb5-49a5-4bdc-bd3c-881b5e9a608f@github.com> On Sun, 1 Sep 2024 12:31:06 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 48 additional commits since the last revision: > > - Merge branch 'master' into feature/interpolatable > - remove StyleConverter.WithReconstructionSupport > - fix line separators > - StyleableStringProperty should be transitionable > - non-interpolatable values should always transition discretely > - only call get() when necessary > - add more documentation > - replace reconstruction annotation with interface > - interpolate integers in real number space > - replace StyleConverter.SupportsDeconstruction interface with annotation > - ... and 38 more: https://git.openjdk.org/jfx/compare/8080d15f...2337ca98 I've been looking at `TransitionMediator`s and `TransitionTimer`s -- these two classes seem to always go together. There is some nasty bookkeeping going on that requires clearing a reference of the mediator. I've had some success just eliminating the Mediator code and storing the timer directly. It works something like this: In the styleable property implementations, create and store a `TransitionTimer` directly. Provide it with a lambda that would do the `onUpdate` code. Also store the `endValue`. So for `StyleableDoubleProperty` it be something like: private TransitionTimer tt; private double endValue; Then in `set` clear the timer if needed: if (tt != null && v == endValue) { tt = null; endValue = 0; // important for reference types } I'd also do this in `bind` instead of relying on the `onStop` callback. You could return just a `Future` from `TransitionTimer.run` as all that is needed is the ability to cancel. To make reversal detection work, you may need to pass something more to `TransitionTimer.run` -- however, see Q1 -- is this something FX has decided to provide that is not part of CSS? Should we consider making this smarter (Q2)? I could imagine the reversal detection should be working with a start value that only resets on animation completion (ie. when `tt` is set back to `null`). The reversal should then be calculated based on how much time we've been animating already since `tt` became non-null (transition time minus time spent animating already). If this is negative, then animate normally. Is it positive, then shorten the transition. If we're still interested in doing reversals, storing a start time + start value would also be needed. These values should only reset when an animation ends (ie. whenever we clear `tt` to `null`). All this can be wrapped together in a helper class managed by the property, something like: record AnimationInfo(Future transitionTimer, T startValue, T endValue, long startTime) {} In a field: AnimationInfo info; If that field is non-null, it should "derive" a new AnimationInfo without altering the startValue and startTime: AnimationInfo derive(Future newTimer, T newEndValue); I don't think TransitionTimer needs to be aware of any of this, as long as it has the `onUpdate` lambda provided. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2325076593 From mstrauss at openjdk.org Mon Sep 2 17:22:30 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Sep 2024 17:22:30 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v26] In-Reply-To: <05CaXerrdKVe3nPPSbFAZo8RxO7X0QFvcIGM0SWwd9s=.ce734cb5-49a5-4bdc-bd3c-881b5e9a608f@github.com> References: <05CaXerrdKVe3nPPSbFAZo8RxO7X0QFvcIGM0SWwd9s=.ce734cb5-49a5-4bdc-bd3c-881b5e9a608f@github.com> Message-ID: On Mon, 2 Sep 2024 16:31:53 GMT, John Hendrikx wrote: > I've been looking at `TransitionMediator`s and `TransitionTimer`s -- these two classes seem to always go together. There is some nasty bookkeeping going on that requires clearing a reference of the mediator. I've had some success just eliminating the Mediator code and storing the timer directly. Yes, having an adapter between the styleable property implementation and the transition timer was an improvement that [you suggested](https://github.com/openjdk/jfx/pull/870#discussion_r1392551399); it seems like we've come full circle. Sure, clearing the mediator reference is not great, but it is a tiny and isolated part (as in, this implementation detail doesn't leak out of the class in which it is used). I wouldn't call this a serious problem of the design. > To make reversal detection work, you may need to pass something more to `TransitionTimer.run` -- however, see Q1 -- is this something FX has decided to provide that is not part of CSS? Should we consider making this smarter (Q2)? Reversal detection requires each styleable property implementation to be able to update their reversing-adjusted start value. This interaction is one of the purposes of `TransitionMediator`. Should we make this smarter as prescribed by the specification? I don't think so. CSS transitions is not the right tool if you need more than simple animated state transitions. I want to stress the fact that these are _CSS_ transitions, not general-purpose transitions that can be triggered programmatically. This means that, while in theory there are multi-state transitions, these _always_ involve multiple pseudo-class states (for example, scenarios involving both :hover and :pressed). It is not possible to accumulate pseudo-class states in a way that would be similar to your Q2 scenario, where you programmatically set different values. > I could imagine the reversal detection should be working with a start value that only resets on animation completion (ie. when `tt` is set back to `null`). The reversal should then be calculated based on how much time we've been animating already since `tt` became non-null (transition time minus time spent animating already). If this is negative, then animate normally. Is it positive, then shorten the transition. I don't think this would support a scenario where a transition is interrupted many times in a row, for example by moving the cursor across a button repeatedly, such that the :hover state is set, unset, then set again, and so on, and none of the transitions are allowed to run to completion. Pretty soon, the time already spent animating will exceed the total time of any single transition, which will prevent faster reversing for all future transitions. This is not what we would want to see. As for your ideas about refactoring the code to get rid of `TransitionMediator`, I'd like to understand a bit more context because this seems pretty random to me. Sure, I can imagine any number of implementations that would do the job, but what is your main motivation for rejecting the current implementation in favor for another approach? The purpose of `TransitionMediator` and `TransitionTimer` seem sufficiently clear-cut to me, and the implementation is reasonably clean given the complex problem being solved. I don't see an _obvious_ shortcoming of the current implementation. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2325124450 From mmack at openjdk.org Mon Sep 2 18:31:30 2024 From: mmack at openjdk.org (Markus Mack) Date: Mon, 2 Sep 2024 18:31:30 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v26] In-Reply-To: References: Message-ID: On Sun, 1 Sep 2024 12:31:06 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 48 additional commits since the last revision: > > - Merge branch 'master' into feature/interpolatable > - remove StyleConverter.WithReconstructionSupport > - fix line separators > - StyleableStringProperty should be transitionable > - non-interpolatable values should always transition discretely > - only call get() when necessary > - add more documentation > - replace reconstruction annotation with interface > - interpolate integers in real number space > - replace StyleConverter.SupportsDeconstruction interface with annotation > - ... and 38 more: https://git.openjdk.org/jfx/compare/38e61055...2337ca98 I did some manual testing on the current iteration of this PR, including transitions between multiple pseudoclasses (including the back transitions). From an aesthetics point of view that looked good! Easing modes were honored, I didn't see any glitches, final states were correct. So I'm not sure there's a big need to outdo the CSS spec here, considering this is a CSS-only feature where end values are static, and it's not programmatically accessible API. (If the latter is needed, one can always just refrain from using CSS transitions and do everything manually). I've also had a look at the proposed implementation. Looks like the important decision is how/where the currently running transition is being tracked. John's suggestions seem valid, but I don't see how they really simplify things compared to the current proposal. I'd say the private `mediator` fields in the stylable Property classes are ok the way they are currently proposed, they are updated whenever the Property changes. A logically sound alternative may be to let `Node` track transitions, but I doubt we want to add more details there when the issue can be solved with private implementation fields in the Property implementations. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2325184408 From azvegint at openjdk.org Tue Sep 3 01:34:29 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 3 Sep 2024 01:34:29 GMT Subject: RFR: 8339178: [macos] Swing InterOp Platform.exit() crash [v3] In-Reply-To: References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com> Message-ID: On Thu, 29 Aug 2024 15:56:59 GMT, Kevin Rushforth wrote: >> A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall. >> >> This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed. >> >> This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR. >> >> Summary of the changes: >> >> * Attach the AppKit thread to the JVM as a daemon >> * Do not detach the thread when the FX main event loop terminates >> * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts >> * Terminate the KeepAlive thread when the FX toolkit finishes >> >> Testing: >> >> I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years Marked as reviewed by azvegint (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1545#pullrequestreview-2276266868 From jhendrikx at openjdk.org Tue Sep 3 02:17:30 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 3 Sep 2024 02:17:30 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v26] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 16:24:33 GMT, Michael Strau? wrote: > Yes, it's a sizable chunk of the specification: https://www.w3.org/TR/css-transitions-1/#starting Thanks, somehow I had trouble finding it. > The algorithm as prescribed by the specification is one of several algorithms that were considered by the W3C working group back in 2013. It is clearly tuned for two-state application scenarios, and might simply not be the right solution for your problem. I've thought a lot about the problem, and while it may be possible to come up with an algorithm that covers more edge cases, that takes a huge toll on the complexity/maintainability budget. Alright, if CSS specifies it like this, then there's little point discussing improvements here. > I don't think this would work at all, because you're setting the value programmatically. You'll only get a transition if you let the CSS system set the value. If you do this, and then query the value of the property under transition, you will get an intermediate value. This simply wouldn't work otherwise, considering how JavaFX properties work. We can't have properties change their value over time, but when you look at them programmatically, they already have the target value. Yeah, I starting seeing this halfway through my review and playing with the code. It just doesn't apply to programmatically set values at all; my own work on throttled and animated bindings may have contributed to the confusion. > Yes, having an adapter between the styleable property implementation and the transition timer was an improvement that [you suggested](https://github.com/openjdk/jfx/pull/870#discussion_r1392551399); it seems like we've come full circle. Sure, clearing the mediator reference is not great, but it is a tiny and isolated part (as in, this implementation detail doesn't leak out of the class in which it is used). I wouldn't call this a serious problem of the design. It's been a while, and I didn't even remember suggesting that anymore, so imagine my surprise when I see my own suggestion reflected in `TransitionMediator`. My responses are usually triggered because of something in the solution that I find confusing or overly complicated. What I didn't like in the original was the subclassing and passing in that subclass to a static method of the same class. What I'm not liking in the current one is the married nature of the two classes, where a mediator is both tracked and passed to the timer. The conditional cancellation and reference clearing logic are the primary things that trigger me here, but also the new reversing logic where a mediator is passed in, then casted. I'm just making suggestions for you to think about (after spending hours looking at the code and trying to follow its logic). The suggestions usually originate from something in the code that is hard to follow or doing things in a seemingly roundabout way. They're suggestions as I may not be seeing all the edge cases, and you should be able to see much better than I if these suggestions have merit. I didn't quite see the conditional way you are clearing a reference in the previous PR (I may have missed it, or perhaps I didn't review it again afterwards). I still think there's room for improvement, which perhaps will allow you to eliminate some of the duplication and confusing parts: 1. You can have `TransitionTimer.run` return an object for cancellation. This is IMHO nicer than tracking an object you passed to it. What I'm further disliking here is that it returns a timer, which is already started, and which you're not supposed to start/stop, and which has an extra method `cancel` (which differs from `stop`). This would be better separated, either by hiding its `AnimationTimer` nature (by using composition) or by not returning a full timer. The opposite is also possible (ie. do expose its `AnimationTimer` nature, but then don't auto start it; have the caller start it. Use `stop` for cancels, not have two methods for similar purposes). 2. You can move the check if a timer should be started based on the target value to `TransitionTimer.run`; if the end value is the same as the timer is already aware off then have it return the existing timer. Callers of `TransitionTimer.run` could look something like: this.timer = TransitionTimer.run( this, newValue, this::callback, transitionDefinition, Toolkit.getToolkit().getPrimaryTimer().nanos() ); To find the startValue it can call `getValue`. For component transitionables, `equals` implementation should do a deep equals. Motivation: eliminates some of the code duplication in the property implementations and leaves the decision whether a new timer is started (or perhaps even internally re-purposed) up to `TransitionTimer`. 3. You can avoid the `cancel(false)` by calling `super.set` from a method other than `set`. For example: private void callback(double progress, double startValue, double endValue) { super.set(progress < 1 ? startValue + (endValue - startValue) * progress : endValue); if (progress >= 1) { timer = null; } } You can now always clear the timer reference in `set` and `bind`: private void clearTransition() { origin = StyleOrigin.USER; if (timer != null) { timer .cancel(true); timer = null; } } Motivation: timer management is a bit more compact and clear. Timers always get cancelled and cleared in `set` and `bind`, and the callback will know exactly when the timer has served its purpose. No need to do a reference equality check to conditionally clear the reference even for reversals. 4. Reversing should be determinable now within `TransitionTimer.run` instead of needing a custom implementation for each type. I think you may be able to avoid `deepEquals`, or have the wrapper around multiple properties handle this in its own `equals`. Motivation: removes ugly casting in `updateReversingAdjustedStartValue` 5. Not a point of improvement, but something that I think is poorly implemented currently in FX (similar to a post from a few weeks ago on the mailinglist). I see that you are passing in the nano time each time, and it seems we may have no choice to do this because `Toolkit.getToolkit().getPrimaryTimer().nanos()` is not returning a constant value within the scope of a single pulse. This is IMHO a serious oversight; what's the point of adding a random number of nanos depending on the exact time it is called during a pulse. This should have been constant, in which case the nanos could simply be obtained by `TransitionTimer.run` instead of having it passed in each time. You could consider providing an overloaded variant where the nanos are optional to avoid the ugly `Toolkit.getToolkit().getPrimaryTimer().nanos()` incantation except where you have no choice. > As for your ideas about refactoring the code to get rid of `TransitionMediator`, I'd like to understand a bit more context because this seems pretty random to me. Sure, I can imagine any number of implementations that would do the job, but what is your main motivation for rejecting the current implementation in favor for another approach? The purpose of `TransitionMediator` and `TransitionTimer` seem sufficiently clear-cut to me, and the implementation is reasonably clean given the complex problem being solved. I don't see an _obvious_ shortcoming of the current implementation. They're only suggestions (or ideas as you call them). IMHO you as the author know best if there is merit in these suggestions. Perhaps a suggestion contains something you didn't think of allowing you to simplify the code a bit further. I've tried adding my reasoning now. As for the current implementation, I think it works, but it is a bit hard to see if all edge cases are covered. I did notice one thing while experimenting with the code that you may want to address. `StyleableProperty_transition_Test` doesn't seem to care for reversal logic. If I mess it up (always return `false` for one of the properties), the test still passes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2325475048 From jhendrikx at openjdk.org Tue Sep 3 03:28:31 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 3 Sep 2024 03:28:31 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v26] In-Reply-To: References: Message-ID: On Sun, 1 Sep 2024 12:31:06 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 48 additional commits since the last revision: > > - Merge branch 'master' into feature/interpolatable > - remove StyleConverter.WithReconstructionSupport > - fix line separators > - StyleableStringProperty should be transitionable > - non-interpolatable values should always transition discretely > - only call get() when necessary > - add more documentation > - replace reconstruction annotation with interface > - interpolate integers in real number space > - replace StyleConverter.SupportsDeconstruction interface with annotation > - ... and 38 more: https://git.openjdk.org/jfx/compare/ca9f51c5...2337ca98 modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 57: > 55: * > 56: * > 57: * (see prose) This could just be a comment below the table? Not sure what "(see prose)" means here. modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 137: > 135: public void onUpdate(double progress) { > 136: // Longs are interpolated in real number space and rounded to the nearest long. > 137: set(progress < 1 ? Math.round(startValue + (endValue - startValue) * progress) : endValue); I don't think this will produce correct start values for all longs, and it may produce values outside [start,end] range I think. Here is a bad start value for example: double progress = 0; long startValue = Long.MAX_VALUE - 1; long endValue = 0; System.out.println(progress < 1 ? Math.round(startValue + (endValue - startValue) * progress) : endValue); System.out.println(startValue); The calculated value will be `Long.MAX_VALUE` which is outside the [startValue, endValue] range. Furthermore, when the longs are large (>49 bits), then interpolation will be terrible: public static void main(String[] args) { long startValue = 1000000000000000000L; long endValue = 1000000000000000100L; for (double progress : new double[] {0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0}) { System.out.println(progress < 1 ? Math.round(startValue + (endValue - startValue) * progress) : endValue); } } Prints: 1000000000000000000 1000000000000000000 1000000000000000000 1000000000000000000 1000000000000000000 1000000000000000000 1000000000000000000 1000000000000000128 1000000000000000128 1000000000000000128 1000000000000000128 I think if you make sure that the subtraction and addition are done as `long` (instead of as `double`) it will be far more accurate: long diff = endValue - startValue; long result = startValue + Math.round(progress * diff); You still will need to ensure the result is clamped I think, and I you'll need to make an exception for `1.0` as it is the result of a double calculation + rounding which can be off. The start value should always be correct I think, even if `progress` is some tiny value like `0.0000000000000000001`. public static void main(String[] args) { long startValue = 1000000000000000333L; long endValue = 2000000000000000100L; for (double progress : new double[] {0.0000000000000000001, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0}) { long diff = endValue - startValue; long interpolatedValue = startValue + Math.round(progress * diff); System.out.println(interpolatedValue); } } Prints: 1000000000000000333 1100000000000000317 1200000000000000301 1300000000000000269 1400000000000000269 1500000000000000205 1600000000000000205 1700000000000000077 1800000000000000205 1900000000000000077 2000000000000000077 So the final `1.0` is not calculated correctly, and so should be handled as a special case. modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 112: > 110: super(Objects.requireNonNull(eventType, "eventType cannot be null")); > 111: this.property = Objects.requireNonNull(property, "property cannot be null"); > 112: this.propertyName = Objects.requireNonNull(propertyName, "propertyName cannot be null"); Can this be different from `property.getCssMetadata().getProperty()`? What does it mean if it is? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1741355798 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1741361742 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1741376154 From johan.vos at gluonhq.com Tue Sep 3 07:45:27 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 3 Sep 2024 09:45:27 +0200 Subject: parallel threads when building webkit In-Reply-To: References: Message-ID: I filed https://bugs.openjdk.org/browse/JDK-8339335 for this, and I created a PR: https://github.com/openjdk/jfx/pull/1554 - Johan On Wed, Apr 24, 2024 at 12:14?PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Johan, > > I often have to try to build it a few times before it succeeds (on Linux). > And I used an old Ryzen 7 1700X with 16 threads, 16GB. I have now upgraded > it, but I haven't built webkit yet. I'm really scared of it :) > > So limiting the threads seems like a good idea. > > > Em qua., 24 de abr. de 2024 ?s 04:23, Johan Vos > escreveu: > >> Hi, >> >> When building WebKit from the sources, the perl script that invokes the >> cmake/make build (build-webkit) will by default set the number of build >> threads to the number of available cores. >> This is often a bad idea, e.g. with 20 cores and 32GB this leads to a >> freeze of the system. >> >> As far as I know, we do not allow passing the number of parallel build >> threads (I typically modify them in the perl script). We already have the >> "NUM_COMPILE_THREADS" property in the build.gradle but we do not use that >> when building webkit. We only pass `--cmakeargs` to the buildscript, and >> the number of threads is set via e.g. `--makeargs=-j16` >> >> Is there a known other way to do this, or should we add passing the >> NUM_COMPILE_THREADS via `--makeargs` in the build.gradle? >> >> - Johan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Tue Sep 3 12:25:52 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Sep 2024 12:25:52 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v27] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... 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/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/2337ca98..6218e9ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=26 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=25-26 Stats: 17 lines in 3 files changed: 12 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Tue Sep 3 12:37:15 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Sep 2024 12:37:15 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v28] In-Reply-To: References: Message-ID: <6hzR0iJbOZZyjCZhV3NwCc9NoY_8wlKdgzIRcUdU8H0=.caba716e-0790-4db1-a52f-3258266d0638@github.com> > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: typo ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/6218e9ab..74b23c43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=27 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=26-27 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Tue Sep 3 12:37:21 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Sep 2024 12:37:21 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v26] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 02:27:10 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 48 additional commits since the last revision: >> >> - Merge branch 'master' into feature/interpolatable >> - remove StyleConverter.WithReconstructionSupport >> - fix line separators >> - StyleableStringProperty should be transitionable >> - non-interpolatable values should always transition discretely >> - only call get() when necessary >> - add more documentation >> - replace reconstruction annotation with interface >> - interpolate integers in real number space >> - replace StyleConverter.SupportsDeconstruction interface with annotation >> - ... and 38 more: https://git.openjdk.org/jfx/compare/869f534a...2337ca98 > > modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 57: > >> 55: * >> 56: * >> 57: * (see prose) > > This could just be a comment below the table? Not sure what "(see prose)" means here. Yes, good idea. I've moved it to a comment below the table. > modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 112: > >> 110: super(Objects.requireNonNull(eventType, "eventType cannot be null")); >> 111: this.property = Objects.requireNonNull(property, "property cannot be null"); >> 112: this.propertyName = Objects.requireNonNull(propertyName, "propertyName cannot be null"); > > Can this be different from `property.getCssMetadata().getProperty()`? What does it mean if it is? It can be different. For example, a transition targeting `-fx-border-color` will show `property.getCssMetaData().getProperty()` == `-fx-region-border`. I've added a section to the javadoc explaining the difference. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1741976433 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1741982433 From jbhaskar at openjdk.org Tue Sep 3 12:52:28 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 3 Sep 2024 12:52:28 GMT Subject: [jfx23u] Integrated: 8334124: Rendering issues with CSS "text-shadow" in WebView In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:05:44 GMT, Jay Bhaskar wrote: > A clean backport to jfx23u. The fix is for Rendering issues with CSS "text-shadow" in WebView . I have tested the fix it is working with the fix and failing without the fix. This pull request has now been integrated. Changeset: ece461b3 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx23u/commit/ece461b33bc1e569facfa53c551e4f2aa760d542 Stats: 84 lines in 2 files changed: 84 ins; 0 del; 0 mod 8334124: Rendering issues with CSS "text-shadow" in WebView Backport-of: e0ceafb7dba15b4faa683c336828e79f19a59d30 ------------- PR: https://git.openjdk.org/jfx23u/pull/17 From jhendrikx at openjdk.org Tue Sep 3 13:13:32 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 3 Sep 2024 13:13:32 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v28] In-Reply-To: <6hzR0iJbOZZyjCZhV3NwCc9NoY_8wlKdgzIRcUdU8H0=.caba716e-0790-4db1-a52f-3258266d0638@github.com> References: <6hzR0iJbOZZyjCZhV3NwCc9NoY_8wlKdgzIRcUdU8H0=.caba716e-0790-4db1-a52f-3258266d0638@github.com> Message-ID: On Tue, 3 Sep 2024 12:37:15 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > typo modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 140: > 138: long diff = endValue - startValue; > 139: long result = startValue + Math.round(progress * diff); > 140: set(progress < 1 ? Utils.clamp(startValue, result, endValue) : endValue); `clamp` won't solve that if `progress = 1.0` that the calculation may result in a value less than `endValue`. You need both the `clamp` and a special case: set(progress == 1.0 ? endValue : progress < 1 ? Utils.clamp(startValue, result, endValue) : endValue); Use `==` or `>=` I don't know what's better. I'm assuming that it is important that `endValue` is returned when `progress = 1.0` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1742034915 From mstrauss at openjdk.org Tue Sep 3 13:50:32 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Sep 2024 13:50:32 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v28] In-Reply-To: References: <6hzR0iJbOZZyjCZhV3NwCc9NoY_8wlKdgzIRcUdU8H0=.caba716e-0790-4db1-a52f-3258266d0638@github.com> Message-ID: On Tue, 3 Sep 2024 13:08:01 GMT, John Hendrikx wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> typo > > modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 140: > >> 138: long diff = endValue - startValue; >> 139: long result = startValue + Math.round(progress * diff); >> 140: set(progress < 1 ? Utils.clamp(startValue, result, endValue) : endValue); > > `clamp` won't solve that if `progress = 1.0` that the calculation may result in a value less than `endValue`. You need both the `clamp` and a special case: > > set(progress == 1.0 ? endValue : progress < 1 ? Utils.clamp(startValue, result, endValue) : endValue); > > Use `==` or `>=` I don't know what's better. > > I'm assuming that it is important that `endValue` is returned when `progress = 1.0` I don't understand this. If progress != 1, then it must be < 1 by definition. It can never be > 1. So the current implementation will just ignore the result of the computation for the special case (result = 1): set(progress < 1 ? Utils.clamp(startValue, result, endValue) : endValue); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1742098330 From kcr at openjdk.org Tue Sep 3 14:12:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 14:12:23 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. I'll run this through or CI as well as do some local builds. The one concern I have is that `NUM_COMPILE_THREADS` is set to 1 on macOS, meaning that this will increase the build time on macOS. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2326627374 From jvos at openjdk.org Tue Sep 3 14:22:22 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 3 Sep 2024 14:22:22 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. It is easy to create (yet) another property for this, but that will make the already complicated build.gradle even more complicated, so if possible I'd like to avoid that. I read the cryptic comment in build.gradle `// On Mac we limit it to 1 by default due to problems running gcc in parallel` What is the problem that is being referred to here? And why would that problem occur in the other native compile jobs but not in the (resource intensive) webkit compile jobs? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2326652996 From jhendrikx at openjdk.org Tue Sep 3 14:43:31 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 3 Sep 2024 14:43:31 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v28] In-Reply-To: References: <6hzR0iJbOZZyjCZhV3NwCc9NoY_8wlKdgzIRcUdU8H0=.caba716e-0790-4db1-a52f-3258266d0638@github.com> Message-ID: On Tue, 3 Sep 2024 13:48:06 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java line 140: >> >>> 138: long diff = endValue - startValue; >>> 139: long result = startValue + Math.round(progress * diff); >>> 140: set(progress < 1 ? Utils.clamp(startValue, result, endValue) : endValue); >> >> `clamp` won't solve that if `progress = 1.0` that the calculation may result in a value less than `endValue`. You need both the `clamp` and a special case: >> >> set(progress == 1.0 ? endValue : progress < 1 ? Utils.clamp(startValue, result, endValue) : endValue); >> >> Use `==` or `>=` I don't know what's better. >> >> I'm assuming that it is important that `endValue` is returned when `progress = 1.0` > > I don't understand this. If progress != 1, then it must be < 1 by definition. It can never be > 1. > So the current implementation will just ignore the result of the computation for the special case (result = 1): > > set(progress < 1 ? Utils.clamp(startValue, result, endValue) : endValue); Sorry, you're right. I completely missed it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1742196709 From mfox at openjdk.org Tue Sep 3 15:49:33 2024 From: mfox at openjdk.org (Martin Fox) Date: Tue, 3 Sep 2024 15:49:33 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v25] In-Reply-To: References: Message-ID: <9ZWIFbdElDh32PEkU06JqG1FpOCuW4y4Ufel-ImuSu8=.7a8bc697-09db-4eda-9917-2eb5784c9d40@github.com> On Wed, 21 Aug 2024 09:58:53 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 incrementally with one additional commit since the last revision: > > Remove negative checks Looks good to me. ------------- Marked as reviewed by mfox (Committer). PR Review: https://git.openjdk.org/jfx/pull/1080#pullrequestreview-2277841415 From kcr at openjdk.org Tue Sep 3 15:54:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 15:54:24 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. Here are the numbers for our CI build with / without the patch: OS / Arch|Current|This PR ---------|-------|------- macOS / aarch64|13m:41s|56m:36s macOS / x64|28m:30s|2h:24m:52s To answer your question: > I read the cryptic comment in build.gradle `// On Mac we limit it to 1 by default due to problems running gcc in parallel` What is the problem that is being referred to here? And why would that problem occur in the other native compile jobs but not in the (resource intensive) webkit compile jobs? That was added for this bug: [JDK-8094590](https://bugs.openjdk.org/browse/JDK-8094590): Mac: Intermittent build failures in task graphics:ccMacFontT2K When I "fixed" that bug (workaround, really) by disabling parallel compilation on macOS, I filed the following as a follow-up, but never got to it: [JDK-8089417](https://bugs.openjdk.org/browse/JDK-8089417): Mac: intermittent T2K gcc failure prevents parallel compilation It's quite possible that this was a bug in the Xcode gcc compiler, and if so, would be no longer relevant. Xcode switch from gcc to clang a long time ago. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2326872149 From angorya at openjdk.org Tue Sep 3 15:59:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Sep 2024 15:59:31 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v6] In-Reply-To: <9hMg8GoVqUtMNXDWm4szvyd8VFVVNOEmGZYnmfvTJY8=.282e77f5-d631-46dc-b337-fec7bada3921@github.com> References: <9hMg8GoVqUtMNXDWm4szvyd8VFVVNOEmGZYnmfvTJY8=.282e77f5-d631-46dc-b337-fec7bada3921@github.com> Message-ID: On Fri, 30 Aug 2024 20:20:22 GMT, Kevin Rushforth 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 10 additional commits since the last revision: >> >> - improved vertical scrolling >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - cleanup >> - navigation >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - update + review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - 8301121: RichTextArea Control (Incubator) > > I was looking into what "editable" does in `RichTextArea`, and I think we need a new name for one of the methods and might also need a second convenience method. There are at least three possible states that we need to consider: > > A. The model supports editing; the control's editable property is true > > This means that the document can be modified via the UI; it can be modified by calling control methods from the app (or by calling the editing methods on StyledTextModel, but apps don't typically do that). > > B. The model supports editing, the control's editable property is false > > This means that the document cannot be modified via the UI; it _can_ be modified by calling control methods from the app (or by calling the editing methods on StyledTextModel, but apps don't typically do that). > > C. The model does not support editing; it is read-only as far as the control and the StyledTextModel base class are concerned; the control's editable property is not relevant > > This means that the document cannot be modified via the UI; it cannot be modified by calling control methods from the app (nor by calling the editing methods on StyledTextModel, but apps don't typically do that). > > There are a couple of thoughts I have around this. > > First, `RichTextArea::canEdit` is not sufficient to distinguish these three cases; it will return false for both B and C. There are methods in RTA that say "if canEdit is false, then this method does nothing". That's correct for case C, but some of those methods -- namely the ones not tied to a UI action (e.g., `appendText`, `insertText`, `replaceText`, `applyStyle`, `setStyle`, `clear`) -- will intentionally do something in case B. Consider adding a second convenience method that returns `model != null && model.isUserEditable` or similar, and use that new method to qualify whether the non-UI mutator methods of RTA do anything. > > Second, `StyledTextModel::userEditable` doesn't seem like the right name for the method in the model to convey that it is effectively read-only as far as the control is concerned. Perhaps "writable" would be a better name, since from the point-of-view of the caller of the StyledTextModel, that's what it means. Maybe there is an even better name, but having "user" in the name is misleading (and editable by itself would be too confusing, since that's the name we want to keep for the control, and it doesn't have the same meaning). Or you could call it "readOnly", but then that would flip the sense of the boolean. Thank you @kevinrushforth . I just wanted to emphasize that unlike any other feature that goes into mainline, this module is an incubating module, with the primary goal of getting the new APIn the hands of the app developers, **in order to receive their feedback**. This makes the acceptance criteria a bit less stringent, as the incubator may incubate over several releases (or be dropped altogether). I would really like to target jfx24, even if the code and API has imperfections. And, as always, your feedback and suggestions are greatly appreciated! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2326881979 From duke at openjdk.org Tue Sep 3 16:14:36 2024 From: duke at openjdk.org (duke) Date: Tue, 3 Sep 2024 16:14:36 GMT Subject: RFR: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64 [v2] In-Reply-To: <6bijMKNiOG_fvBGsUBjQrnH74mUTpnW7qptZRkv5wa0=.65a58120-f893-4324-beb9-ac87ee3f6e39@github.com> References: <6bijMKNiOG_fvBGsUBjQrnH74mUTpnW7qptZRkv5wa0=.65a58120-f893-4324-beb9-ac87ee3f6e39@github.com> Message-ID: On Thu, 29 Aug 2024 14:43:39 GMT, ANUPAM DEV wrote: >> Hi, >> >> I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64. >> from: >> IS_LINUX ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : "" >> >> to: >> IS_LINUX && IS_AARCH64 ? "org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355" : >> IS_LINUX && !IS_AARCH64 ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : "" >> >> Please review. >> >> Regards, >> Anupam > > ANUPAM DEV has updated the pull request incrementally with one additional commit since the last revision: > > Updated verification-metadata.xml. Added sha256 for Linux /aarch64 jar @anupamdev20 Your change (at version b00c2f32eecc529277bdc44d118af8642b1b01c5) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1549#issuecomment-2326912345 From duke at openjdk.org Tue Sep 3 16:22:26 2024 From: duke at openjdk.org (ANUPAM DEV) Date: Tue, 3 Sep 2024 16:22:26 GMT Subject: Integrated: 8339212: gradle downloads x64 binary of SWT on Linux/aarch64 In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 04:46:05 GMT, ANUPAM DEV wrote: > Hi, > > I have updated the name of the SWT.jar that needs to be downloaded during the build process for Linux aarch64. > from: > IS_LINUX ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : "" > > to: > IS_LINUX && IS_AARCH64 ? "org.eclipse.swt.gtk.linux.aarch64_3.124.200.v20231113-1355" : > IS_LINUX && !IS_AARCH64 ? "org.eclipse.swt.gtk.linux.x86_64_3.124.200.v20231113-1355" : "" > > Please review. > > Regards, > Anupam This pull request has now been integrated. Changeset: 2bf8ffc4 Author: ANUPAM DEV Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/2bf8ffc411d404be2a3f9107a62ffa7a72fcccbd Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod 8339212: gradle downloads x64 binary of SWT on Linux/aarch64 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1549 From angorya at openjdk.org Tue Sep 3 16:49:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Sep 2024 16:49:33 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v9] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:45:02 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Reject CSS where compound selectors don't consist of simple selectors modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 109: > 107: > 108: if (type != TYPE_SIMPLE) { > 109: throw new IllegalStateException("Expected compound selector to consist of simple selectors only, but found type: " + type); minor: the output will be a signed decimal. would it be better if this can be formatted as hex? `String.format("Expected compound selector to consist of TYPE_SIMPLE only, but found type: 0x%02X", type)` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1742380640 From jvos at openjdk.org Tue Sep 3 16:55:23 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 3 Sep 2024 16:55:23 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. I see 4 options: 1. the current approach in this PR. Drawback: huge increase in build time on mac 2. a separate option for the number of parallel jobs for webkit. Drawbacks: not elegant because * we don't know why there are no issues compiling webkit with parallel jobs while there are issues compiling JavaFX native code with parallel jobs. * adding another property increases complexity 3. Finding and fixing the cause for the parallel compilation issues on mac (JDK-8089417). Drawback: finding the cause may take a very long time -- if it is even still possible to reproduce 4. Removing the 1-thread restriction for mac. Drawback: unless we do (3), we don't know if this is not going to cause issues. I'm ok with either approach. I consider option 3 the most elegant one, and option 2 the most pragmatic one (but also the least elegant). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327003871 From mstrauss at openjdk.org Tue Sep 3 17:09:51 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Sep 2024 17:09:51 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v29] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: refactoring ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/74b23c43..ba375b57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=28 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=27-28 Stats: 336 lines in 10 files changed: 78 ins; 180 del; 78 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From kcr at openjdk.org Tue Sep 3 17:13:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 17:13:23 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. As you say, option 3 is the cleanest, however I believe it will very quickly morph into option 4. I am reasonably certain that [JDK-8089417](https://bugs.openjdk.org/browse/JDK-8089417) can be closed as "Cannot reproduce" because: * The font T2K code that was hitting the failure is no longer part of our repo; T2K was a closed-source font rasterizer that we removed in JDK 10 via [JDK-8187147](https://bugs.openjdk.org/browse/JDK-8187147). * Xcode switched from gcc to clang by default several years ago I will locally remove the workaround, and then run the following in a loop a few hundred times to check whether we see any issues: $ gradle cleanNative sdk I did it a few times on my MacBook M1 and the only impact I see of removing the workaround is that a rebuild of the SDK without media or WebKit (so just rebuilding the graphics / glass native code) goes from 27 seconds to 12 seconds. :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327034232 From mstrauss at openjdk.org Tue Sep 3 17:20:32 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Sep 2024 17:20:32 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v29] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 17:09:51 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > refactoring I've made some changes as follows: 1. `TransitionTimer.run` returns a `CancellationToken` object instead of a timer reference, which is only used to cancel the timer. This removes all usages of `TransitionTimer` from `TransitionMediator` (except for the single call to the `run` method). 2. The `cancel` method doesn't use a `forceStop` flag any more, which also removes tracking of `updating` flags from implementations. Instead, `TransitionMediator.onUpdate` now directly calls the `super.set` method to avoid cancelling itself. 3. The conditional clearing of the `mediator` field is removed, it is now cleared unconditionally. To make this work, `TransitionTimer` internally detects situations when the field shouldn't be cleared, and then elides the call to `TransitionMediator.onStop`. This avoids having implementations follow a bespoke clearing protocol. 4. The methods that effectively stop a transition timer have been reduced to `stop`, `complete`, and `interrupt`, each having a precise definition. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2327046946 From kcr at openjdk.org Tue Sep 3 17:29:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 17:29:23 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. Presuming that my testing shows no problems, I propose the following: 1. I will close [JDK-8089417](https://bugs.openjdk.org/browse/JDK-8089417) as "Cannot reproduce" 2. I will file a new bug to remove the workaround that currently disabled parallel compilation on mac for the graphics module (I think that's cleaner from a bookkeeping perspective than repurposing JDK-8089417) 3. You can add the removal of the logic that forced `NUM_COMPILE_THREADS` to 1 on macOS to this PR, and `/issue add` the new JBS issue Thoughts? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327063495 From jvos at openjdk.org Tue Sep 3 17:38:23 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 3 Sep 2024 17:38:23 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 17:27:15 GMT, Kevin Rushforth wrote: > Presuming that my testing shows no problems, I propose the following: > > 1. I will close [JDK-8089417](https://bugs.openjdk.org/browse/JDK-8089417) as "Cannot reproduce" > 2. I will file a new bug to remove the workaround that currently disabled parallel compilation on mac for the graphics module (I think that's cleaner from a bookkeeping perspective than repurposing JDK-8089417) > 3. You can add the removal of the logic that forced `NUM_COMPILE_THREADS` to 1 on macOS to this PR, and `/issue add` the new JBS issue > > Thoughts? Sounds like a plan. I'll add that to the PR once you confirm testing went as expected. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327077637 From kcr at openjdk.org Tue Sep 3 17:50:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 17:50:24 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: <6A5KHnzrT6JNVl8HzHwHp5Aig_-3mRDBGvyxXMkpvvg=.4528e3de-cb1e-4418-8893-2f1091c2207e@github.com> On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. Btw, I ran another CI build with the `NUM_COMPILE_THREADS=1` workaround for Mac removed, and the build times are good again. In fact, the x64 build runs even faster than before -- possibly because WebKit build defaults to a lower number than num_processors, and it happens to be 12 on that x64 build system. Here are the updated numbers: OS / Arch|Current|This PR|PR + don't limit num threads on macOS ---------|-------|-------|------- macOS / aarch64|13m:41s|56m:36s|13m:43s macOS / x64|28m:30s|2h:24m:52s|23m:01s I should also add that the Linux and Windows build times are largely unaffected by this PR (which is good). They do run slightly faster with your patch than current, but the percentage gain is small. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327094270 From kcr at openjdk.org Tue Sep 3 17:50:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 17:50:24 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 17:35:49 GMT, Johan Vos wrote: > Sounds like a plan. I'll add that to the PR once you confirm testing went as expected. So far so good. I'll let it run a bit longer, but already I'm over 120 iterations with no failures. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327096207 From angorya at openjdk.org Tue Sep 3 18:00:23 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Sep 2024 18:00:23 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 12:47:38 GMT, Kevin Rushforth wrote: > This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo). > > The following filter was used to produce the list of issues fixed in JavaFX 23: > > https://bugs.openjdk.org/issues/?filter=45422 > > Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes. > > I will wait until closer to the September 17th release date to integrate this. > > > A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split: > > ## List of New Features > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls > [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls > [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics > [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics > [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media > > ## List of Other Enhancements > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build > [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls > [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics > [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics > [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics that's a lot of bug fixes! all that I wanted to be listed are listed. thank you. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1553#pullrequestreview-2278110382 From nlisker at openjdk.org Tue Sep 3 18:01:32 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 3 Sep 2024 18:01:32 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v29] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 17:09:51 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > refactoring Isn't `CancellationToken` a simplified `Subscription`? Won't the additional methods on the latter be of use here? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2327113682 From mstrauss at openjdk.org Tue Sep 3 18:06:30 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Sep 2024 18:06:30 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v29] In-Reply-To: References: Message-ID: <6d_hc8hIpJhmB9pDTp-Ya_Xqz0UkisXJEzV6gomD5CE=.8b90c8aa-3855-45bf-abb2-884a4ce81574@github.com> On Tue, 3 Sep 2024 17:58:40 GMT, Nir Lisker wrote: > Isn't `CancellationToken` a simplified `Subscription`? Won't the additional methods on the latter be of use here? Yes it is. I thought about using `Subscription`, but the method name `unsubscribe()` doesn't seem to match what is happening. Maybe we can add something like `Cancellable` in the future, if at any point in time we require similar semantics. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2327121283 From jvos at openjdk.org Tue Sep 3 18:38:22 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 3 Sep 2024 18:38:22 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: <6A5KHnzrT6JNVl8HzHwHp5Aig_-3mRDBGvyxXMkpvvg=.4528e3de-cb1e-4418-8893-2f1091c2207e@github.com> References: <6A5KHnzrT6JNVl8HzHwHp5Aig_-3mRDBGvyxXMkpvvg=.4528e3de-cb1e-4418-8893-2f1091c2207e@github.com> Message-ID: <7_Fpp-ncKfXSGErwTPjAKyZlNGJ2OULEpLU7HAjXbn8=.9b4b5839-6c37-4afc-81a3-66100f4c324d@github.com> On Tue, 3 Sep 2024 17:46:17 GMT, Kevin Rushforth wrote: > Btw, I ran another CI build with the `NUM_COMPILE_THREADS=1` workaround for Mac removed, and the build times are good again. In fact, the x64 build runs even faster than before -- possibly because WebKit build defaults to a lower number than num_processors, and it happens to be 12 on that x64 build system. > > Here are the updated numbers: > > OS / Arch Current This PR PR + don't limit num threads on macOS > macOS / aarch64 13m:41s 56m:36s 13m:43s > macOS / x64 28m:30s 2h:24m:52s 23m:01s > I should also add that the Linux and Windows build times are largely unaffected by this PR (which is good). They do run slightly faster with your patch than current, but the percentage gain is small. Interesting. The default NUM_COMPILE_THREADS comes from what Gradle gives us, using `${Runtime.runtime.availableProcessors()}` The default threads that webkit uses `numberOfCPUs()` which is on mac implemented as `sysctl -n hw.ncpu` On my macOS/aarch64, both implementations give "10", but this can indeed give different values. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327173344 From kcr at openjdk.org Tue Sep 3 18:43:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 18:43:25 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. It's probably coincidental then. Btw, my local test of `gradle cleanNative sdk` in a loop has hit 350 iterations with no errors. I'm running one last test on our CI build nodes (both x64 and aarch64) with 100 iterations. Once that completes, I'll close [JDK-8089417](https://bugs.openjdk.org/browse/JDK-8089417) and file the new bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327181206 From angorya at openjdk.org Tue Sep 3 18:43:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Sep 2024 18:43:26 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v6] In-Reply-To: <9hMg8GoVqUtMNXDWm4szvyd8VFVVNOEmGZYnmfvTJY8=.282e77f5-d631-46dc-b337-fec7bada3921@github.com> References: <9hMg8GoVqUtMNXDWm4szvyd8VFVVNOEmGZYnmfvTJY8=.282e77f5-d631-46dc-b337-fec7bada3921@github.com> Message-ID: <2366RATqyZIcMtSn3oF-LIS6iqXqeSO20xq8vqNNqpw=.d91c3031-e0ee-4b3b-8c8c-2b63a451f7cf@github.com> On Fri, 30 Aug 2024 20:20:22 GMT, Kevin Rushforth wrote: > "editable" does in `RichTextArea` I see your point. Let me see how we can make this clearer (I also welcome naming suggestions). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2327181690 From kcr at openjdk.org Tue Sep 3 19:19:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 19:19:25 GMT Subject: Integrated: 8339178: [macos] Swing InterOp Platform.exit() crash In-Reply-To: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com> References: <-G5I8W2R-cHWRlN8sjj2yC0GU5bkq1hTNqRR47lQdPE=.460efa27-f34f-4d7f-a1d9-b4c10e721164@github.com> Message-ID: On Mon, 26 Aug 2024 21:11:03 GMT, Kevin Rushforth wrote: > A Swing / FX interop app will crash if an application creates a new AWT / Swing window after calling Platform.exit. The root cause of the crash is that AWT caches the JNI env pointer for the AppKit thread, and assumes that it is valid for the life of the application. In the case where JavaFX is the owner of the NSApplication, we detach the AppKit thread from the JVM, after which AWT's env pointer is no longer valid. AWT will therefore crash the next time it does a JNI upcall. > > This PR fixes the crash by leaving the macOS AppKit thread attached to the JVM after the JavaFX main event loop terminates. This requires attaching the AppKit thread to the JVM as a daemon thread when JavaFX is the NSApplication owner, matching what AWT does when it is the owner. In order to prevent a JavaFX application from exiting prematurely, create a non-daemon "KeepAlive" thread that can be terminated when the FX toolkit exits. This also solves a somewhat-related problem where the JavaFX toolkit will exit prematurely if the AWT toolkit is started first, and all AWT windows are disposed. > > This fix is in addition to the AWT fix: [JDK-8190329](https://bugs.openjdk.org/browse/JDK-8190329) / openjdk/jdk#20688. Either the AWT fix or the JavaFX fix is sufficient to avoid this specific problem, but there is value in fixing it in both places, so I cloned the AWT bug to create a JavaFX bug that we can use for this PR. > > Summary of the changes: > > * Attach the AppKit thread to the JVM as a daemon > * Do not detach the thread when the FX main event loop terminates > * Create and start a KeepAlive thread in MacApplication, when the FX toolkit starts > * Terminate the KeepAlive thread when the FX toolkit finishes > > Testing: > > I created automated systems tests from the manual test programs in the bugs as well as a test to ensure that we don't regress and exit prematurely in the pure JavaFX case (which would happen without the KeepAlive thread). Two of the new tests fail on macOS without the fix and pass with the fix. All three pass on all platforms with the fix. This pull request has now been integrated. Changeset: 46522826 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/465228269ba1d9ad4e902e9f161b79b8a1ebcd81 Stats: 370 lines in 8 files changed: 335 ins; 29 del; 6 mod 8339178: [macos] Swing InterOp Platform.exit() crash 8339183: [macos] Premature exit in Swing interop when last JFrame is disposed Reviewed-by: psadhukhan, azvegint ------------- PR: https://git.openjdk.org/jfx/pull/1545 From andy.goryachev at oracle.com Tue Sep 3 19:33:21 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 3 Sep 2024 19:33:21 +0000 Subject: Proposal: Focus Traversal API Message-ID: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Sep 3 19:49:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 19:49:26 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. I'm done testing and have closed [JDK-8089417](https://bugs.openjdk.org/browse/JDK-8089417) as "Cannot reproduce". I filed a new bug: [JDK-8339505](https://bugs.openjdk.org/browse/JDK-8339505): Enable parallel compilation of native code on macOS Go ahead and remove the force-NUM_COMPILE_THREADS -to-1 workaround and add that new issue to this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327305447 From jvos at openjdk.org Tue Sep 3 19:56:48 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 3 Sep 2024 19:56:48 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit [v2] In-Reply-To: References: Message-ID: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Remove the special case where native compile jobs are hard set to 1 on Mac -- see JDK-8339505 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1554/files - new: https://git.openjdk.org/jfx/pull/1554/files/a6e6c1c9..1a1a360a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1554&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1554&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1554.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1554/head:pull/1554 PR: https://git.openjdk.org/jfx/pull/1554 From kcr at openjdk.org Tue Sep 3 20:10:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 20:10:25 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit [v2] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 19:56:48 GMT, Johan Vos wrote: >> When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. >> This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. >> When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Remove the special case where native compile jobs are hard set to 1 > on Mac -- see JDK-8339505 The latest build changes look good. I'll do a final CI build and report results...probably tomorrow. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327344883 From almatvee at openjdk.org Tue Sep 3 20:16:23 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 3 Sep 2024 20:16:23 GMT Subject: Integrated: 8338701: Provide media support for libavcodec version 61 In-Reply-To: References: Message-ID: On Thu, 29 Aug 2024 21:02:41 GMT, Alexander Matveev wrote: > - Added support for libavcodec 61. > - Updated AV plugins to use new APIs instead of APIs which were removed in 61. > - We still using some deprecated APIs. > - `reordered_opaque` replacement exist in 61 which is used to pass user data between compressed frame and uncompressed. In 61 this variable is pointer to `void` instead of `int64_t`. We can use new `opaque` to pass PTS, but it is not documented way to pass PTS between compressed and uncompressed frames. Updated code will be using `AVPacket.pts/AVFrame.pts` which is documented way to provide PTS. > - Tested on Ubuntu 24.10 with 61 and 24.04 with 60 with all supported formats. This pull request has now been integrated. Changeset: 6115b396 Author: Alexander Matveev URL: https://git.openjdk.org/jfx/commit/6115b396bacf62f39dcaa93c7c0adcd60b428b8c Stats: 56 lines in 6 files changed: 45 ins; 0 del; 11 mod 8338701: Provide media support for libavcodec version 61 Reviewed-by: sykora, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1552 From angorya at openjdk.org Tue Sep 3 20:32:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Sep 2024 20:32:35 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit [v2] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 19:56:48 GMT, Johan Vos wrote: >> When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. >> This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. >> When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Remove the special case where native compile jobs are hard set to 1 > on Mac -- see JDK-8339505 I am using this command to build: (rm -rf ./build ; gradle -PCOMPILE_MEDIA=true -PCOMPILE_WEBKIT=true all 2>&1) | tee ~/`date +"build-%Y-%m%d-%H%M%S"`.log on macOS 14.6.1 / M1 Pro looking at the Activity Monitor, I see 1 thread per clang compiler. Is this expected, or am I supposed to see more concurrent threads? ![Screenshot 2024-09-03 at 13 25 55](https://github.com/user-attachments/assets/96085195-d71d-4ff7-9d49-7090efc7a892) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327381083 From kevin.rushforth at oracle.com Tue Sep 3 20:34:45 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 3 Sep 2024 13:34:45 -0700 Subject: JavaFX 23.0.1 will be closed for fixes on September 9th Message-ID: <5381b885-a91e-4157-b895-f5cdad3f98b0@oracle.com> All, If you have backports that you want to get into jfx23u for JavaFX 23.0.1, please do so by Monday, September 9th. Note that approval from one of the project leads is needed as outlined in this message [1]. Starting Tuesday, September 10th, jfx23u will be open for JavaFX 23.0.2 fixes. Thanks. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-July/048051.html From kcr at openjdk.org Tue Sep 3 20:44:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Sep 2024 20:44:30 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit [v2] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 19:56:48 GMT, Johan Vos wrote: >> When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. >> This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. >> When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Remove the special case where native compile jobs are hard set to 1 > on Mac -- see JDK-8339505 This setting (nor likely any setting we can, or would want to, control) doesn't affect the parallelism of an individual clang process, but rather controls the maximum number of concurrent clang processes that will be launched. The net effect of this patch on macOS should be that we will now do parallel compilation for native code in the graphics module by default. There should be no change, by default, in the parallelism of WebKit compilation (there would have been before the most recent commit that Johan did). What this patch will do is to apply the same `NUM_COMPILE_THREADS` flag to native WebKit as well as native graphics compilation. Prior to this fix, setting `NUM_COMPILE_THREADS` to, say 2, would have been used for the graphics build and ignored for the WebKit build. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327399993 From angorya at openjdk.org Tue Sep 3 22:50:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Sep 2024 22:50:25 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit [v2] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 19:56:48 GMT, Johan Vos wrote: >> When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. >> This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. >> When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Remove the special case where native compile jobs are hard set to 1 > on Mac -- see JDK-8339505 Marked as reviewed by angorya (Reviewer). -PNUM_COMPILE_THREADS=1: BUILD SUCCESSFUL in 1h 9m 44s -PNUM_COMPILE_THREADS=10: BUILD SUCCESSFUL in 17m 4s -PNUM_COMPILE_THREADS=32: BUILD SUCCESSFUL in 19m 49s ------------- PR Review: https://git.openjdk.org/jfx/pull/1554#pullrequestreview-2278644614 PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2327568361 From almatvee at openjdk.org Wed Sep 4 00:46:47 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 4 Sep 2024 00:46:47 GMT Subject: [jfx23u] RFR: 8338701: Provide media support for libavcodec version 61 Message-ID: <2qW1ynFJpZMg4yHvRaZniN4JQ8RKZ8_zurRuPAcRjOQ=.d288f6db-3d1c-48e3-ac41-e3482dff917e@github.com> Clean backport of JDK-8338701. ------------- Commit messages: - Backport 6115b396bacf62f39dcaa93c7c0adcd60b428b8c Changes: https://git.openjdk.org/jfx23u/pull/18/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=18&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338701 Stats: 56 lines in 6 files changed: 45 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jfx23u/pull/18.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/18/head:pull/18 PR: https://git.openjdk.org/jfx23u/pull/18 From duke at openjdk.org Wed Sep 4 06:19:24 2024 From: duke at openjdk.org (Abhinay Agarwal) Date: Wed, 4 Sep 2024 06:19:24 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 12:47:38 GMT, Kevin Rushforth wrote: > This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo). > > The following filter was used to produce the list of issues fixed in JavaFX 23: > > https://bugs.openjdk.org/issues/?filter=45422 > > Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes. > > I will wait until closer to the September 17th release date to integrate this. > > > A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split: > > ## List of New Features > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls > [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls > [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics > [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics > [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media > > ## List of Other Enhancements > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build > [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls > [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics > [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics > [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics The current separation looks good to me too. I have a question related to issues to be included: we tend to normally not include backports in release notes. However, issues like [JDK-8299738](https://bugs.openjdk.org/browse/JDK-8299738) and [JDK-8335630](https://bugs.openjdk.org/browse/JDK-8335630) are included. Are these included because the backports were successfully made before the release of `jfx23`? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2328005358 From kneester77 at gmail.com Wed Sep 4 06:53:01 2024 From: kneester77 at gmail.com (Knee Snap) Date: Tue, 3 Sep 2024 23:53:01 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support Message-ID: Hello all, This is a continuation of a previous email thread: "[Feature Proposal] Vertex Colors on TriangleMesh". I'm creating a new email thread because after discussion I've put together a feature proposal, and it serves largely as a summary of the previous email thread. (Better organized as a feature proposal) *Feature Proposal:* https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md I had previously discussed a draft PR, but considering how simple the proposed public API additions are to discuss, I don't think it's actually that helpful. *What's next?* I'm currently happy with the design and seeing as it's been discussed already, I could probably ask Kevin for a review. But, I'd like to give another opportunity for design discussion before doing so, just in-case there are any further considerations brought up. So, I open up the floor again. Does anyone have any thoughts on this proposal? Concerns? Questions? Suggestions? Constructive criticism? I eagerly await the feedback. After API discussion concludes, I plan to pass it off to Kevin for review/approval, and if it is approved, the subsequent CSR creation. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ristovaher1213 at gmail.com Wed Sep 4 07:45:11 2024 From: ristovaher1213 at gmail.com (Risto Vaher) Date: Wed, 4 Sep 2024 08:45:11 +0100 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: I have been using JavaFX's 3D api for a while now and i think this is an important addition and it would benefit me quite a lot, but honestly i have come to accept that improving the 3D api is not a priority for JavaFX, neither important at all (probably because there are not that many people actually using it, which is a shame because i think it could be quite great) Very obvious features are still missing from it after many years, vertex colors being one of them but also texture filtering and wrapping mode which would be trivial to implement since every graphics API supports it and it is quite an important feature imo. As for your specific proposal, im all for it and i think it should be implemented because every engine/graphics API that is at least half decent supports vertex colors and i believe it is an important feature. On Wed, Sep 4, 2024 at 7:53?AM Knee Snap wrote: > Hello all, > > This is a continuation of a previous email thread: "[Feature Proposal] > Vertex Colors on TriangleMesh". > I'm creating a new email thread because after discussion I've put together > a feature proposal, and it serves largely as a summary of the previous > email thread. (Better organized as a feature proposal) > > *Feature Proposal:* > https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md > I had previously discussed a draft PR, but considering how simple the > proposed public API additions are to discuss, I don't think it's actually > that helpful. > > *What's next?* > I'm currently happy with the design and seeing as it's been discussed > already, I could probably ask Kevin for a review. But, I'd like to give > another opportunity for design discussion before doing so, just in-case > there are any further considerations brought up. > So, I open up the floor again. Does anyone have any thoughts on this > proposal? Concerns? Questions? Suggestions? Constructive criticism? I > eagerly await the feedback. > > After API discussion concludes, I plan to pass it off to Kevin for > review/approval, and if it is approved, the subsequent CSR creation. > > Thanks! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kneester77 at gmail.com Wed Sep 4 10:45:30 2024 From: kneester77 at gmail.com (Knee Snap) Date: Wed, 4 Sep 2024 03:45:30 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: Thanks for the feedback! I'm hopeful that texture wrapping/filtering can be added at some point too, I've definitely had times where it'd be helpful, though I do appreciate REPEAT textures being the default behavior at least (even if that's not actually a documented feature...) A small (but non-trivial) amount of work will go a long way into improving JavaFX 3D quite a bit, and I hope that I can contribute at least a bit towards that. On Wed, Sep 4, 2024, 12:45?AM Risto Vaher wrote: > I have been using JavaFX's 3D api for a while now and i think this is an > important addition and it would benefit me quite a lot, but honestly i have > come to accept that improving the 3D api is not a priority for JavaFX, > neither important at all (probably because there are not that many people > actually using it, which is a shame because i think it could be quite great) > Very obvious features are still missing from it after many years, vertex > colors being one of them but also texture filtering and wrapping mode which > would be trivial to implement since every graphics API supports it and it > is quite an important feature imo. > > As for your specific proposal, im all for it and i think it should be > implemented because every engine/graphics API that is at least half decent > supports vertex colors and i believe it is an important feature. > > On Wed, Sep 4, 2024 at 7:53?AM Knee Snap wrote: > >> Hello all, >> >> This is a continuation of a previous email thread: "[Feature Proposal] >> Vertex Colors on TriangleMesh". >> I'm creating a new email thread because after discussion I've put >> together a feature proposal, and it serves largely as a summary of the >> previous email thread. (Better organized as a feature proposal) >> >> *Feature Proposal:* >> https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md >> I had previously discussed a draft PR, but considering how simple the >> proposed public API additions are to discuss, I don't think it's actually >> that helpful. >> >> *What's next?* >> I'm currently happy with the design and seeing as it's been discussed >> already, I could probably ask Kevin for a review. But, I'd like to give >> another opportunity for design discussion before doing so, just in-case >> there are any further considerations brought up. >> So, I open up the floor again. Does anyone have any thoughts on this >> proposal? Concerns? Questions? Suggestions? Constructive criticism? I >> eagerly await the feedback. >> >> After API discussion concludes, I plan to pass it off to Kevin for >> review/approval, and if it is approved, the subsequent CSR creation. >> >> Thanks! >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Sep 4 11:23:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Sep 2024 11:23:26 GMT Subject: RFR: 8339335: set number of parallel jobs when building webkit [v2] In-Reply-To: References: Message-ID: <2wtFn2yjF5N7OV_r2juykCYHmpOVS7meycX8YU1eJkA=.0ac4d2b5-9668-4962-b9e5-3a682abf7f23@github.com> On Tue, 3 Sep 2024 19:56:48 GMT, Johan Vos wrote: >> When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. >> This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. >> When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Remove the special case where native compile jobs are hard set to 1 > on Mac -- see JDK-8339505 All good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1554#pullrequestreview-2279821394 From kcr at openjdk.org Wed Sep 4 11:45:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Sep 2024 11:45:26 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 06:16:24 GMT, Abhinay Agarwal wrote: > The current separation looks good to me too. A question then for both you and @nlisker : Should I split the "Enhancements" section into two groups as shown in the PR Description, or leave it as a single group? > I have a question related to issues to be included: we tend to normally not include backports in release notes. However, issues like [JDK-8299738](https://bugs.openjdk.org/browse/JDK-8299738) and [JDK-8335630](https://bugs.openjdk.org/browse/JDK-8335630) are included. Are these included because the backports were successfully made before the release of `jfx23`? We started including backports as of JavaFX 21 because of the change to integrate fixes first into mainline and use backport-style PRs into the stabilization branch. See [this PR comment](https://github.com/openjdk/jfx/pull/1239#discussion_r1323664831) in the JavaFX 21 release notes PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2328727260 From jvos at openjdk.org Wed Sep 4 12:10:28 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 4 Sep 2024 12:10:28 GMT Subject: Integrated: 8339335: set number of parallel jobs when building webkit In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos wrote: > When building webkit, the perl script in `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it will default to the number of CPU's as well, hence it will have the same behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be used by cmake as well now. This pull request has now been integrated. Changeset: 4647367c Author: Johan Vos URL: https://git.openjdk.org/jfx/commit/4647367ce4590440fbb85675055225c869502314 Stats: 9 lines in 1 file changed: 2 ins; 5 del; 2 mod 8339335: set number of parallel jobs when building webkit 8339505: Enable parallel compilation of native code on macOS Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1554 From oschmidtmer at openjdk.org Wed Sep 4 12:48:35 2024 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Wed, 4 Sep 2024 12:48:35 GMT Subject: [jfx23u] RFR: 8337481: File API: file.name contains path instead of name Message-ID: Clean backport of JDK-8337481 ------------- Commit messages: - Backport ca70a07b3ee712b1d06baf8a3901e6ae96070124 Changes: https://git.openjdk.org/jfx23u/pull/19/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=19&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337481 Stats: 91 lines in 4 files changed: 76 ins; 12 del; 3 mod Patch: https://git.openjdk.org/jfx23u/pull/19.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/19/head:pull/19 PR: https://git.openjdk.org/jfx23u/pull/19 From duke at openjdk.org Wed Sep 4 12:55:23 2024 From: duke at openjdk.org (duke) Date: Wed, 4 Sep 2024 12:55:23 GMT Subject: [jfx23u] RFR: 8337481: File API: file.name contains path instead of name In-Reply-To: References: Message-ID: <7Smgxm2c71pDYl8ZFWPpMtNMFfUJBKivaNWlzW1qsUs=.d3560166-f9b7-44ba-9ff4-8f20c55b4067@github.com> On Wed, 4 Sep 2024 12:30:43 GMT, Oliver Schmidtmer wrote: > Clean backport of JDK-8337481 @Schmidor Your change (at version a3db959ad2d9422b1e8da9b75c18a0586a35c0ba) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/19#issuecomment-2328938832 From oschmidtmer at openjdk.org Wed Sep 4 12:58:24 2024 From: oschmidtmer at openjdk.org (Oliver Schmidtmer) Date: Wed, 4 Sep 2024 12:58:24 GMT Subject: [jfx23u] Integrated: 8337481: File API: file.name contains path instead of name In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 12:30:43 GMT, Oliver Schmidtmer wrote: > Clean backport of JDK-8337481 This pull request has now been integrated. Changeset: 34835744 Author: Oliver Schmidtmer Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx23u/commit/3483574437a45c1860a366d53354d6af1f9cbed5 Stats: 91 lines in 4 files changed: 76 ins; 12 del; 3 mod 8337481: File API: file.name contains path instead of name Backport-of: ca70a07b3ee712b1d06baf8a3901e6ae96070124 ------------- PR: https://git.openjdk.org/jfx23u/pull/19 From nlisker at openjdk.org Wed Sep 4 13:21:25 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 4 Sep 2024 13:21:25 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 11:42:47 GMT, Kevin Rushforth wrote: > Should I split the "Enhancements" section into two groups as shown in the PR Description, or leave it as a single group? @abhinayagarwal Do you write the highlights page https://openjfx.io/highlights/22/? Will the same split be done there? I think the split should be kept. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2329023223 From duke at openjdk.org Wed Sep 4 13:32:25 2024 From: duke at openjdk.org (Abhinay Agarwal) Date: Wed, 4 Sep 2024 13:32:25 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 06:16:24 GMT, Abhinay Agarwal wrote: >> This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo). >> >> The following filter was used to produce the list of issues fixed in JavaFX 23: >> >> https://bugs.openjdk.org/issues/?filter=45422 >> >> Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes. >> >> I will wait until closer to the September 17th release date to integrate this. >> >> >> A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split: >> >> ## List of New Features >> >> Issue key|Summary|Subcomponent >> ---------|-------|------------ >> [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls >> [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls >> [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics >> [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics >> [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media >> >> ## List of Other Enhancements >> >> Issue key|Summary|Subcomponent >> ---------|-------|------------ >> [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build >> [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls >> [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics >> [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics >> [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics > > The current separation looks good to me too. > > I have a question related to issues to be included: we tend to normally not include backports in release notes. However, issues like [JDK-8299738](https://bugs.openjdk.org/browse/JDK-8299738) and [JDK-8335630](https://bugs.openjdk.org/browse/JDK-8335630) are included. Are these included because the backports were successfully made before the release of `jfx23`? > @abhinayagarwal Do you write the highlights page https://openjfx.io/highlights/22/? Yes, I do. We can keep the same split on highlights. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2329058231 From angorya at openjdk.org Wed Sep 4 14:23:23 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Sep 2024 14:23:23 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 12:47:38 GMT, Kevin Rushforth wrote: > This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo). > > The following filter was used to produce the list of issues fixed in JavaFX 23: > > https://bugs.openjdk.org/issues/?filter=45422 > > Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes. > > I will wait until closer to the September 17th release date to integrate this. > > > A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split: > > ## List of New Features > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls > [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls > [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics > [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics > [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media > > ## List of Other Enhancements > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build > [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls > [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics > [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics > [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics Just noticed: we might want to title case "Issue key" in both tables' headers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2329203439 From kcr at openjdk.org Wed Sep 4 14:38:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Sep 2024 14:38:00 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 [v2] In-Reply-To: References: Message-ID: > This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo). > > The following filter was used to produce the list of issues fixed in JavaFX 23: > > https://bugs.openjdk.org/issues/?filter=45422 > > Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes. > > I will wait until closer to the September 17th release date to integrate this. > > > A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split: > > ## List of New Features > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls > [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls > [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics > [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics > [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media > > ## List of Other Enhancements > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build > [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls > [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics > [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics > [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Split enhancements into two groups; use title case for "Issue Key" ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1553/files - new: https://git.openjdk.org/jfx/pull/1553/files/759c9df1..f4c55a61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1553&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1553&range=00-01 Stats: 15 lines in 1 file changed: 8 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1553.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1553/head:pull/1553 PR: https://git.openjdk.org/jfx/pull/1553 From kcr at openjdk.org Wed Sep 4 14:38:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Sep 2024 14:38:00 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 In-Reply-To: References: Message-ID: <_ZdpkkP1g20gD8VFmDDpbCj94EHDeyXUkq1o3MHZb2w=.a4432f22-1853-47c6-8163-dcfed08e54d5@github.com> On Wed, 4 Sep 2024 13:18:21 GMT, Nir Lisker wrote: > > Should I split the "Enhancements" section into two groups as shown in the PR Description, or leave it as a single group? ... > I think the split should be kept. Done. > Just noticed: we might want to title case "Issue key" in both tables' headers. Fixed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2329240195 From angorya at openjdk.org Wed Sep 4 14:43:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Sep 2024 14:43:25 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 [v2] In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 14:38:00 GMT, Kevin Rushforth wrote: >> This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo). >> >> The following filter was used to produce the list of issues fixed in JavaFX 23: >> >> https://bugs.openjdk.org/issues/?filter=45422 >> >> Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes. >> >> I will wait until closer to the September 17th release date to integrate this. >> >> >> A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split: >> >> ## List of New Features >> >> Issue key|Summary|Subcomponent >> ---------|-------|------------ >> [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls >> [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls >> [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics >> [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics >> [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media >> >> ## List of Other Enhancements >> >> Issue key|Summary|Subcomponent >> ---------|-------|------------ >> [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build >> [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls >> [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics >> [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics >> [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Split enhancements into two groups; use title case for "Issue Key" Marked as reviewed by angorya (Reviewer). Just a suggestion - sharing some tricks of writing the .md format: It might be easier to review if the pipe characters in the table were aligned, and have at least one space separation from the previous cell's text. This makes it easier to read in a code editor and does not produce spelling errors when the raw text is pasted in Word. It adds some work though. Example: Issue Key |Summary |Subcomponent -----------------------------------------------------------|--------------------------------|------------ [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102) |Labeled: textTruncated property |controls [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138) |Scrollbar Keyboard enhancement |controls ------------- PR Review: https://git.openjdk.org/jfx/pull/1553#pullrequestreview-2280441363 PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2329255711 From andy.goryachev at oracle.com Wed Sep 4 14:44:36 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 4 Sep 2024 14:44:36 +0000 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: I am not a 3D expert; one question: how is the gamma value set for color interpolation? Thanks! -andy From: openjfx-dev on behalf of Knee Snap Date: Tuesday, September 3, 2024 at 23:53 To: openjfx-dev at openjdk.org Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support Hello all, This is a continuation of a previous email thread: "[Feature Proposal] Vertex Colors on TriangleMesh". I'm creating a new email thread because after discussion I've put together a feature proposal, and it serves largely as a summary of the previous email thread. (Better organized as a feature proposal) Feature Proposal: https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md I had previously discussed a draft PR, but considering how simple the proposed public API additions are to discuss, I don't think it's actually that helpful. What's next? I'm currently happy with the design and seeing as it's been discussed already, I could probably ask Kevin for a review. But, I'd like to give another opportunity for design discussion before doing so, just in-case there are any further considerations brought up. So, I open up the floor again. Does anyone have any thoughts on this proposal? Concerns? Questions? Suggestions? Constructive criticism? I eagerly await the feedback. After API discussion concludes, I plan to pass it off to Kevin for review/approval, and if it is approved, the subsequent CSR creation. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Wed Sep 4 15:50:24 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Wed, 4 Sep 2024 15:50:24 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 [v2] In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 14:38:00 GMT, Kevin Rushforth wrote: >> This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo). >> >> The following filter was used to produce the list of issues fixed in JavaFX 23: >> >> https://bugs.openjdk.org/issues/?filter=45422 >> >> Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes. >> >> I will wait until closer to the September 17th release date to integrate this. >> >> >> A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split: >> >> ## List of New Features >> >> Issue key|Summary|Subcomponent >> ---------|-------|------------ >> [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls >> [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls >> [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics >> [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics >> [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media >> >> ## List of Other Enhancements >> >> Issue key|Summary|Subcomponent >> ---------|-------|------------ >> [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build >> [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls >> [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics >> [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics >> [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Split enhancements into two groups; use title case for "Issue Key" I forgot I noted for myself some docs typos for this version. Obviously not critical to get them into 23, but if there's time before this is merged (should be until September 9th), I can create a PR quickly along the usual lines that we did in previous versions. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2329422802 From kcr at openjdk.org Wed Sep 4 16:15:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Sep 2024 16:15:28 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 [v2] In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 15:47:39 GMT, Nir Lisker wrote: > I forgot I noted for myself some docs typos for this version. Obviously not critical to get them into 23, but if there's time before this is merged (should be until September 9th), I can create a PR quickly along the usual lines that we did in previous versions. We are already past the deadline for 23 (it was last Thursday), so they can go into 24. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2329478948 From almatvee at openjdk.org Wed Sep 4 16:18:25 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 4 Sep 2024 16:18:25 GMT Subject: [jfx23u] Integrated: 8338701: Provide media support for libavcodec version 61 In-Reply-To: <2qW1ynFJpZMg4yHvRaZniN4JQ8RKZ8_zurRuPAcRjOQ=.d288f6db-3d1c-48e3-ac41-e3482dff917e@github.com> References: <2qW1ynFJpZMg4yHvRaZniN4JQ8RKZ8_zurRuPAcRjOQ=.d288f6db-3d1c-48e3-ac41-e3482dff917e@github.com> Message-ID: On Wed, 4 Sep 2024 00:40:22 GMT, Alexander Matveev wrote: > Clean backport of JDK-8338701. This pull request has now been integrated. Changeset: aba60fda Author: Alexander Matveev URL: https://git.openjdk.org/jfx23u/commit/aba60fda1c82f00e8e685107592305c403a31287 Stats: 56 lines in 6 files changed: 45 ins; 0 del; 11 mod 8338701: Provide media support for libavcodec version 61 Backport-of: 6115b396bacf62f39dcaa93c7c0adcd60b428b8c ------------- PR: https://git.openjdk.org/jfx23u/pull/18 From kneester77 at gmail.com Wed Sep 4 19:24:25 2024 From: kneester77 at gmail.com (Knee Snap) Date: Wed, 4 Sep 2024 12:24:25 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: I don't know what gamma refers to in the context of vertex colors, sorry. It's not using the gamma color space if that's the question (but neither is the rest of JavaFX 3D). If gamma is meant as opacity, then setting the alpha color value will control opacity. On Wed, Sep 4, 2024, 7:44?AM Andy Goryachev wrote: > I am not a 3D expert; one question: how is the gamma value set for color > interpolation? > > > > Thanks! > > -andy > > > > *From: *openjfx-dev on behalf of Knee Snap > > *Date: *Tuesday, September 3, 2024 at 23:53 > *To: *openjfx-dev at openjdk.org > *Subject: *[Feature Proposal]: TriangleMesh - Vertex Color Support > > Hello all, > > > > This is a continuation of a previous email thread: "[Feature Proposal] > Vertex Colors on TriangleMesh". > > I'm creating a new email thread because after discussion I've put together > a feature proposal, and it serves largely as a summary of the previous > email thread. (Better organized as a feature proposal) > > > > *Feature Proposal:* > https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md > > I had previously discussed a draft PR, but considering how simple the > proposed public API additions are to discuss, I don't think it's actually > that helpful. > > > > *What's next?* > > I'm currently happy with the design and seeing as it's been discussed > already, I could probably ask Kevin for a review. But, I'd like to give > another opportunity for design discussion before doing so, just in-case > there are any further considerations brought up. > > So, I open up the floor again. Does anyone have any thoughts on this > proposal? Concerns? Questions? Suggestions? Constructive criticism? I > eagerly await the feedback. > > > > After API discussion concludes, I plan to pass it off to Kevin for > review/approval, and if it is approved, the subsequent CSR creation. > > > > Thanks! > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Sep 4 19:34:33 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 4 Sep 2024 19:34:33 +0000 Subject: [External] : Re: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: Here is a good example - https://www.panotools.org/dersch/gamma/gamma.html -andy From: Knee Snap Date: Wednesday, September 4, 2024 at 12:24 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: [External] : Re: [Feature Proposal]: TriangleMesh - Vertex Color Support I don't know what gamma refers to in the context of vertex colors, sorry. It's not using the gamma color space if that's the question (but neither is the rest of JavaFX 3D). If gamma is meant as opacity, then setting the alpha color value will control opacity. On Wed, Sep 4, 2024, 7:44?AM Andy Goryachev > wrote: I am not a 3D expert; one question: how is the gamma value set for color interpolation? Thanks! -andy From: openjfx-dev > on behalf of Knee Snap > Date: Tuesday, September 3, 2024 at 23:53 To: openjfx-dev at openjdk.org > Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support Hello all, This is a continuation of a previous email thread: "[Feature Proposal] Vertex Colors on TriangleMesh". I'm creating a new email thread because after discussion I've put together a feature proposal, and it serves largely as a summary of the previous email thread. (Better organized as a feature proposal) Feature Proposal: https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md I had previously discussed a draft PR, but considering how simple the proposed public API additions are to discuss, I don't think it's actually that helpful. What's next? I'm currently happy with the design and seeing as it's been discussed already, I could probably ask Kevin for a review. But, I'd like to give another opportunity for design discussion before doing so, just in-case there are any further considerations brought up. So, I open up the floor again. Does anyone have any thoughts on this proposal? Concerns? Questions? Suggestions? Constructive criticism? I eagerly await the feedback. After API discussion concludes, I plan to pass it off to Kevin for review/approval, and if it is approved, the subsequent CSR creation. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Sep 4 20:07:37 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 4 Sep 2024 13:07:37 -0700 Subject: [External] : Re: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: <6d49b8b1-ced5-4826-8776-767dd9040058@oracle.com> Color calculations are assumed to be done in sRGB space [1]. There is nothing specific to adding vertex colors to 3D meshes that would impact this. Short answer: no, there is nothing explicitly needed for gamma correction -- Kevin [1] https://en.wikipedia.org/wiki/SRGB On 9/4/2024 12:34 PM, Andy Goryachev wrote: > > Here is a good example - > > https://www.panotools.org/dersch/gamma/gamma.html > > -andy > > *From: *Knee Snap > *Date: *Wednesday, September 4, 2024 at 12:24 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *[External] : Re: [Feature Proposal]: TriangleMesh - Vertex > Color Support > > I don't know what gamma refers to in the context of vertex colors, sorry. > > It's not using the gamma color space if that's the question (but > neither is the rest of JavaFX 3D). > > If gamma is meant as opacity, then setting the alpha color value will > control opacity. > > On Wed, Sep 4, 2024, 7:44?AM Andy Goryachev > wrote: > > I am not a 3D expert; one question: how is the gamma value set for > color interpolation? > > Thanks! > > -andy > > *From: *openjfx-dev on behalf of > Knee Snap > *Date: *Tuesday, September 3, 2024 at 23:53 > *To: *openjfx-dev at openjdk.org > *Subject: *[Feature Proposal]: TriangleMesh - Vertex Color Support > > Hello all, > > This is a continuation of a previous email thread: "[Feature > Proposal] Vertex Colors on TriangleMesh". > > I'm creating a new email thread because after discussion I've put > together a feature proposal, and it serves largely as a summary of > the previous email thread. (Better organized as a feature proposal) > > *Feature > Proposal:*https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md > > > I had previously discussed a draft PR, but considering how simple > the proposed public API additions are to discuss, I don't think > it's actually that helpful. > > *What's next?* > > I'm currently happy with the?design and seeing as it's been > discussed already, I could probably ask Kevin for a review. But, > I'd like to give another opportunity for design discussion before > doing so, just in-case there are any further considerations > brought up. > > So, I open up the floor again. Does anyone have any thoughts on > this proposal? Concerns? Questions? Suggestions? Constructive > criticism? I eagerly await the feedback. > > After API discussion concludes, I plan to pass it off to Kevin for > review/approval,?and if it is approved, the subsequent CSR creation. > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Sep 4 20:13:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Sep 2024 20:13:28 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v6] In-Reply-To: References: Message-ID: <7aryXhaQsw8D5nEdmQ6FNsdUuOHDz5YATZInh9JOFec=.ae065523-99a7-4df0-a4d1-b781d8d0d0d4@github.com> On Thu, 29 Aug 2024 19:49:49 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - improved vertical scrolling > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - cleanup > - navigation > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - update + review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - 8301121: RichTextArea Control (Incubator) follow-up: 1. RTA::canEdit() will be removed to avoid confusion. 2. will change to StyledTextModel::writable ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2329883668 From angorya at openjdk.org Wed Sep 4 23:30:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Sep 2024 23:30:02 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v29] In-Reply-To: References: Message-ID: <8JgEU_da0Hz83QofTmb2Po4mbx2yZNOtZoIS9KF7Kxs=.4ac58eaf-49c9-4746-9094-31d66787dc26@github.com> On Tue, 3 Sep 2024 17:09:51 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > refactoring build.gradle line 4378: > 4376: options.tags("implSpec:a:Implementation Requirements:") > 4377: options.tags("implNote:a:Implementation Note:") > 4378: options.tags("interpolationType:a:Interpolation type:") should this use title case? modules/javafx.base/src/test/java/test/util/ReflectionUtils.java line 62: > 60: } > 61: > 62: throw new AssertionError("Field not found"); suggestion: `throw new AssertionError("Field not found:" + fieldName);` modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9041: > 9039: } > 9040: > 9041: private TransitionTimerCollection transitionTimers; Would it make more sense to move this to the `miscProperties`? I'd expect there will typically be a few nodes with transition times, but thousands of Nodes in total. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1744504554 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1744533751 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1744612187 From mstrauss at openjdk.org Thu Sep 5 00:42:30 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 00:42:30 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changes per review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/ba375b57..97ee29e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=29 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=28-29 Stats: 26 lines in 3 files changed: 12 ins; 4 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Thu Sep 5 00:42:30 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 00:42:30 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v29] In-Reply-To: <8JgEU_da0Hz83QofTmb2Po4mbx2yZNOtZoIS9KF7Kxs=.4ac58eaf-49c9-4746-9094-31d66787dc26@github.com> References: <8JgEU_da0Hz83QofTmb2Po4mbx2yZNOtZoIS9KF7Kxs=.4ac58eaf-49c9-4746-9094-31d66787dc26@github.com> Message-ID: <6xP3KYz7ssoAbcyw_XrSegiKGO6233Md07oxO91k-KE=.37c8014e-0ab9-4253-a582-bb1dd6c8299d@github.com> On Wed, 4 Sep 2024 21:12:00 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> refactoring > > build.gradle line 4378: > >> 4376: options.tags("implSpec:a:Implementation Requirements:") >> 4377: options.tags("implNote:a:Implementation Note:") >> 4378: options.tags("interpolationType:a:Interpolation type:") > > should this use title case? Changed as suggested. The style across the documentation is a bit inconsistent, but seems to prefer title case. > modules/javafx.base/src/test/java/test/util/ReflectionUtils.java line 62: > >> 60: } >> 61: >> 62: throw new AssertionError("Field not found"); > > suggestion: > `throw new AssertionError("Field not found:" + fieldName);` Changed as suggested. > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9041: > >> 9039: } >> 9040: >> 9041: private TransitionTimerCollection transitionTimers; > > Would it make more sense to move this to the `miscProperties`? > > I'd expect there will typically be a few nodes with transition times, but thousands of Nodes in total. Sure, we can do that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1744655402 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1744655501 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1744655604 From mstrauss at openjdk.org Thu Sep 5 12:06:30 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 12:06:30 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D Message-ID: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. ------------- Commit messages: - Seal Node, Camera, LightBase, Shape, Shape3D Changes: https://git.openjdk.org/jfx/pull/1556/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1556&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339603 Stats: 190 lines in 46 files changed: 89 ins; 18 del; 83 mod Patch: https://git.openjdk.org/jfx/pull/1556.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1556/head:pull/1556 PR: https://git.openjdk.org/jfx/pull/1556 From angorya at openjdk.org Thu Sep 5 17:00:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Sep 2024 17:00:11 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: References: Message-ID: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> On Thu, 5 Sep 2024 00:42:30 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > changes per review modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 639: > 637: var definitions = node.miscProperties != null ? node.miscProperties.transitionDefinitions : null; > 638: if (definitions == null) { > 639: definitions = node.new TransitionDefinitionCollection(); TransitionDefinitionCollection can be a static class, can it? modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9043: > 9041: } > 9042: > 9043: return result; minor suggestion: List> subMetadata = metadata.getSubProperties(); if (subMetadata != null) { for (int i = 0, max = subMetadata.size(); i < max; ++i) { result = collectTransitionTimers(property, result); } } return result; modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundConverter.java line 109: > 107: image = img; > 108: } else { > 109: throw new IllegalArgumentException("convertedValues"); would it make sense to make this exception message more meaningful to help diagnose the issue? for example, what is expected and what is encountered. (this comment applies to every other converter) modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 418: > 416: * {@inheritDoc} > 417: * > 418: * @throws NullPointerException {@inheritDoc} @kevinrushforth : is there a bug in javadoc that requires @throws repeated here? without it, the base class @throws is not shown. modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderStroke.java line 54: > 52: *
    > 53: *
  • {@link Color} ? {@link LinearGradient} > 54: *
  • {@link Color} ? {@link RadialGradient} nice use of unicode `?` modules/javafx.graphics/src/test/java/test/javafx/css/StyleableProperty_transition_Test.java line 198: > 196: void setup() { > 197: toolkit = (StubToolkit)Toolkit.getToolkit(); > 198: scene = new Scene(new Group()); should we `hide` stage in `@AfterEach` ? probably applies to other tests modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundConverterTest.java line 51: > 49: import static org.junit.jupiter.api.Assertions.*; > 50: > 51: public class BackgroundConverterTest { this is minor, but applicable to other tests: it would be nice to have a short basic description of the test, for human consumption. Example: Tests BackgroundConverter functions - from url - convert from image - equality of reconstructed objects (this is just an example) Also, should it also test `convertBack()` ? modules/javafx.graphics/src/test/java/test/javafx/scene/paint/ColorTest.java line 738: > 736: @Test > 737: public void testWebHsla3Param() { > 738: assertThrows(IllegalArgumentException.class, () -> Color.web("hsla(240, 50%, 50%)")); even though this change is unrelated to the feature, I agree with the decision to make it in this PR. and its trivial, so unlikely to give us trouble merging. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1745865564 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1745878383 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1745709416 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1745778766 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1745822017 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1745835405 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1745840583 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1745846997 From angorya at openjdk.org Thu Sep 5 17:27:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Sep 2024 17:27:56 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. What is the benefit of this change? Also, this change is breaking. One can currently create a Node: public class CanCreateNode extends Application { @Override public void init() { Node n1 = new Node() { }; class Yo extends Node { } Yo n2 = new Yo(); } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2332269300 From mstrauss at openjdk.org Thu Sep 5 17:48:08 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 17:48:08 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 17:24:50 GMT, Andy Goryachev wrote: > What is the benefit of this change? It enforces a system invariant at compile-time instead of run-time. > Also, this change is breaking. One can currently create a Node: > > ``` > public class CanCreateNode extends Application { > @Override > public void init() { > Node n1 = new Node() { > }; > class Yo extends Node { > } > Yo n2 = new Yo(); > } > ``` You can't do anything meaningful with this node. As soon as you add it to a scene graph, you'll get a runtime exception. The fact that you can't extend `Node` is a system invariant, finding pathological situations in which you won't get an exception is just a loophole. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2332310139 From mstrauss at openjdk.org Thu Sep 5 18:45:03 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 18:45:03 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> Message-ID: On Thu, 5 Sep 2024 15:38:20 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changes per review > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 418: > >> 416: * {@inheritDoc} >> 417: * >> 418: * @throws NullPointerException {@inheritDoc} > > @kevinrushforth : is there a bug in javadoc that requires @throws repeated here? without it, the base class @throws is not shown. This seems to be intentional: https://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javadoc.html#inheritingcomments _When a `@throws` tag for a particular exception is missing, the `@throws` tag is copied only if that exception is declared._ ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746004046 From mstrauss at openjdk.org Thu Sep 5 18:47:59 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 18:47:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> Message-ID: On Thu, 5 Sep 2024 16:42:38 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changes per review > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 639: > >> 637: var definitions = node.miscProperties != null ? node.miscProperties.transitionDefinitions : null; >> 638: if (definitions == null) { >> 639: definitions = node.new TransitionDefinitionCollection(); > > TransitionDefinitionCollection can be a static class, can it? Yes, good catch! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746006803 From angorya at openjdk.org Thu Sep 5 18:58:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Sep 2024 18:58:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> Message-ID: On Thu, 5 Sep 2024 18:42:48 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 418: >> >>> 416: * {@inheritDoc} >>> 417: * >>> 418: * @throws NullPointerException {@inheritDoc} >> >> @kevinrushforth : is there a bug in javadoc that requires @throws repeated here? without it, the base class @throws is not shown. > > This seems to be intentional: > https://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javadoc.html#inheritingcomments > > _When a `@throws` tag for a particular exception is missing, the `@throws` tag is copied only if that exception is declared._ +1 for rtfm, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746015709 From mstrauss at openjdk.org Thu Sep 5 18:58:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 18:58:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> Message-ID: <3GkWMFHDDo5_BssTSt5kZoT-kvdcfVQ03NXZzMD5nNc=.eddb2653-d9b8-4d95-a902-792c58bf0903@github.com> On Thu, 5 Sep 2024 16:18:34 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changes per review > > modules/javafx.graphics/src/test/java/test/javafx/css/StyleableProperty_transition_Test.java line 198: > >> 196: void setup() { >> 197: toolkit = (StubToolkit)Toolkit.getToolkit(); >> 198: scene = new Scene(new Group()); > > should we `hide` stage in `@AfterEach` ? > probably applies to other tests I'm already doing this in `@AfterEach` by calling `stage.close()`, which is equivalent to `hide()`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746017559 From mstrauss at openjdk.org Thu Sep 5 18:58:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 18:58:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v31] In-Reply-To: References: Message-ID: <-wzTqngm6Natc5YxSJ3uaUAuPnaaTGSq0goOQsiAzgU=.91109cc1-bb40-4638-b327-6ac4b3f4a869@github.com> > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... 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/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/97ee29e2..7328daa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=30 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=29-30 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Thu Sep 5 19:03:05 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 19:03:05 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> Message-ID: <7ORaR9Suv3TaFwUVw1i5AlTK9UYAicr8midlP--0E4M=.1fcbd55c-c54e-4f2f-9baa-2341232b338f@github.com> On Thu, 5 Sep 2024 16:53:23 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changes per review > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 9043: > >> 9041: } >> 9042: >> 9043: return result; > > minor suggestion: > > List> subMetadata = metadata.getSubProperties(); > if (subMetadata != null) { > for (int i = 0, max = subMetadata.size(); i < max; ++i) { > result = collectTransitionTimers(property, result); > } > } > return result; I usually like flatter code more than nested code, but I don't really mind one way or the other in this particular situation. > modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundConverter.java line 109: > >> 107: image = img; >> 108: } else { >> 109: throw new IllegalArgumentException("convertedValues"); > > would it make sense to make this exception message more meaningful to help diagnose the issue? for example, what is expected and what is encountered. > > (this comment applies to every other converter) I've reworded the message to include the unexpected type. Note that the existing code will just throw `ClassCastException` in similar circumstances, so we probably don't need to get super detailed for this particular situation. If we want to have really detailed exception messages, the entire method should be refactored. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746024861 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746022540 From angorya at openjdk.org Thu Sep 5 19:03:06 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Sep 2024 19:03:06 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: <3GkWMFHDDo5_BssTSt5kZoT-kvdcfVQ03NXZzMD5nNc=.eddb2653-d9b8-4d95-a902-792c58bf0903@github.com> References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> <3GkWMFHDDo5_BssTSt5kZoT-kvdcfVQ03NXZzMD5nNc=.eddb2653-d9b8-4d95-a902-792c58bf0903@github.com> Message-ID: On Thu, 5 Sep 2024 18:54:11 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/test/java/test/javafx/css/StyleableProperty_transition_Test.java line 198: >> >>> 196: void setup() { >>> 197: toolkit = (StubToolkit)Toolkit.getToolkit(); >>> 198: scene = new Scene(new Group()); >> >> should we `hide` stage in `@AfterEach` ? >> probably applies to other tests > > I'm already doing this in `@AfterEach` by calling `stage.close()`, which is equivalent to `hide()`. I should have looked in eclipse. You are right - it is there. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746022202 From mstrauss at openjdk.org Thu Sep 5 19:15:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 19:15:42 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v32] In-Reply-To: References: Message-ID: <_57qA4h4OAnsWzKWzpdXy6ZaGSd0yeXIbpPSchZ8BQ4=.964f5372-dd9d-429a-99f2-6e13b3a42d75@github.com> > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: javadoc changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/7328daa9..9b7f2a53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=31 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=30-31 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Thu Sep 5 19:20:59 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 19:20:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> Message-ID: On Thu, 5 Sep 2024 16:22:58 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> changes per review > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundConverterTest.java line 51: > >> 49: import static org.junit.jupiter.api.Assertions.*; >> 50: >> 51: public class BackgroundConverterTest { > > this is minor, but applicable to other tests: > > it would be nice to have a short basic description of the test, for human consumption. > > Example: > Tests BackgroundConverter functions > - from url > - convert from image > - equality of reconstructed objects > (this is just an example) > > Also, should it also test `convertBack()` ? I agree when there's added value, but in this particular case I don't know what to add... Note that `convertBack()` is exercised in `reconstructedObjectMustBeEqual()`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746050295 From angorya at openjdk.org Thu Sep 5 19:28:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Sep 2024 19:28:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> Message-ID: On Thu, 5 Sep 2024 19:18:09 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundConverterTest.java line 51: >> >>> 49: import static org.junit.jupiter.api.Assertions.*; >>> 50: >>> 51: public class BackgroundConverterTest { >> >> this is minor, but applicable to other tests: >> >> it would be nice to have a short basic description of the test, for human consumption. >> >> Example: >> Tests BackgroundConverter functions >> - from url >> - convert from image >> - equality of reconstructed objects >> (this is just an example) >> >> Also, should it also test `convertBack()` ? > > I agree when there's added value, but in this particular case I don't know what to add... > Note that `convertBack()` is exercised in `reconstructedObjectMustBeEqual()`. - does `convertBack` need a failing scenario? - does `convertBack` accept null argument? - since we are dealing with type erasure and possible quirks of `CssParser`, would it make sense to test the case when a wrong type is being passed to `convertBack`? Also, a more generic suggestion: in the absence of `@Nullable`, we probably should specify whether an argument or return value may be null. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746058328 From mstrauss at openjdk.org Thu Sep 5 19:55:36 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 19:55:36 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v33] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/9b7f2a53..d884a566 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=32 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=31-32 Stats: 34 lines in 2 files changed: 26 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Thu Sep 5 20:00:01 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 20:00:01 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> Message-ID: On Thu, 5 Sep 2024 19:26:01 GMT, Andy Goryachev wrote: >> I agree when there's added value, but in this particular case I don't know what to add... >> Note that `convertBack()` is exercised in `reconstructedObjectMustBeEqual()`. > > - does `convertBack` need a failing scenario? > - does `convertBack` accept null argument? > - since we are dealing with type erasure and possible quirks of `CssParser`, would it make sense to test the case when a wrong type is being passed to `convertBack`? > > Also, a more generic suggestion: in the absence of `@Nullable`, we probably should specify whether an argument or return value may be null. I've added tests for a `null` argument, as well as for an unsupported type for the `BORDER_IMAGE_SOURCE` and `BACKGROUND_IMAGE` mappings. As for your third bullet point, I think you mean `convert` and not `convertBack`. You can only pass "wrong" things into the former, not the latter method. While more tests for `convert` would be good, they shouldn't be done as part of this PR since it is unrelated code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746089993 From angorya at openjdk.org Thu Sep 5 20:32:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Sep 2024 20:32:00 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> Message-ID: <82BxYC_DqIy6GtdEv8KACZSOcw2WgD8qEdbLRdiFBAQ=.b205d1bb-def1-4afa-937b-5b4fe5f3ad4d@github.com> On Thu, 5 Sep 2024 19:57:35 GMT, Michael Strau? wrote: >> - does `convertBack` need a failing scenario? >> - does `convertBack` accept null argument? >> - since we are dealing with type erasure and possible quirks of `CssParser`, would it make sense to test the case when a wrong type is being passed to `convertBack`? >> >> Also, a more generic suggestion: in the absence of `@Nullable`, we probably should specify whether an argument or return value may be null. > > I've added tests for a `null` argument, as well as for an unsupported type for the `BORDER_IMAGE_SOURCE` and `BACKGROUND_IMAGE` mappings. > > As for your third bullet point, I think you mean `convert` and not `convertBack`. You can only pass "wrong" things into the former, not the latter method. While more tests for `convert` would be good, they shouldn't be done as part of this PR since it is unrelated code. you are probably right. I was thinking of a rather contrived case like void wrong() { SubPropertyConverter c = (SubPropertyConverter)converter; c.convertBack(new Object()); } my question about _documenting_ nullability still stands though. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746121944 From mstrauss at openjdk.org Thu Sep 5 20:55:37 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 20:55:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v34] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: javadoc changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/d884a566..75e7d98b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=33 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=32-33 Stats: 16 lines in 3 files changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Thu Sep 5 20:55:37 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 5 Sep 2024 20:55:37 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v30] In-Reply-To: <82BxYC_DqIy6GtdEv8KACZSOcw2WgD8qEdbLRdiFBAQ=.b205d1bb-def1-4afa-937b-5b4fe5f3ad4d@github.com> References: <6IZYwM89Xgag2dD91eGw3SynT0uJQp7zrP23ZHR5U4Y=.b7d06e27-0a6c-4ea8-bef1-51135836551f@github.com> <82BxYC_DqIy6GtdEv8KACZSOcw2WgD8qEdbLRdiFBAQ=.b205d1bb-def1-4afa-937b-5b4fe5f3ad4d@github.com> Message-ID: On Thu, 5 Sep 2024 20:29:17 GMT, Andy Goryachev wrote: >> I've added tests for a `null` argument, as well as for an unsupported type for the `BORDER_IMAGE_SOURCE` and `BACKGROUND_IMAGE` mappings. >> >> As for your third bullet point, I think you mean `convert` and not `convertBack`. You can only pass "wrong" things into the former, not the latter method. While more tests for `convert` would be good, they shouldn't be done as part of this PR since it is unrelated code. > > you are probably right. I was thinking of a rather contrived case like > > > void wrong() { > SubPropertyConverter c = (SubPropertyConverter)converter; > c.convertBack(new Object()); > } > > > my question about _documenting_ nullability still stands though. I've added the appropriate javadoc documentation for that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1746144798 From kcr at openjdk.org Thu Sep 5 21:18:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Sep 2024 21:18:03 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX Message-ID: Add the `jdk.jsobject` module to JavaFX. This module is currently delivered by the JDK, but will be terminally-deprecated in JDK 24 by [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530), which is out for review at openjdk/jdk#20555. We therefore plan to start delivering it with JavaFX in JavaFX 24. ### Testing scenarios Both JDK and JavaFX for some period of time, so we need to test various scenarios. I built and tested this PR branch with each of the following JDKs: 1. JDK 23 or earlier (I used the default boot JDK, which is currently JDK 22.0.2); this JDK includes `jdk.jsobject` as a normal, non-upgradable module 2. A locally-built JDK 24 from my [8311530-depr-jsobject](https://github.com/kevinrushforth/jdk/tree/8311530-depr-jsobject) branch, which has the fix for [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530); this JDK includes `jdk.jsobject` as a terminally-deprecated, upgradable module 3. A locally-built JDK 24 from my [WIP-rm-jsobject](https://github.com/kevinrushforth/jdk/tree/WIP-rm-jsobject) branch, which removes the `jdk.jsobject` module, and is therefore a prototype of what will happen in JDK 26 (or later) when it is removed from the JDK I ran a build and test of JavaFX from this PR branch using each of the above JDKs. All tests pass. I then took the JavaFX artifacts built by JDK 1 (matching how we will deliver this in JavaFX 24), and ran the following additional tests, all of which match my expectations: * java --module-path=.../jfx/build/sdk/lib without any additional flags (required for JDK 1; recommended for JDK 3)
    RESULT: JDKs 1 and 2 use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX * java --module-path=.../jfx/build/sdk/lib --upgrade-module-path=.../jfx/build/sdk/lib (recommended for JDK 2, OK for 3)
    RESULT: JDK 1 will fail to launch; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX * jlink with .../jfx/build/jmods ahead of $JAVA_HOME/jmods (recommended for JDKs 2 and 3)
    RESULT: JDK 1 will fail to link; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX * jlink with $JAVA_HOME/jmods ahead of .../jfx/build/jmods (required for JDK 1)
    RESULT: JDKs 1 and 2 will use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX I have not verified the maven artifacts, but they are being generated correctly. ------------- Commit messages: - Merge branch 'master' into 8337280-jsobject - Merge branch 'master' into 8337280-jsobject - Merge branch 'master' into 8337280-jsobject - Update copyright years - Merge branch 'master' into 8337280-jsobject - Update to pick up latest version from jdk master - 8337280: Include jdk.jsobject module with JavaFX Changes: https://git.openjdk.org/jfx/pull/1529/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1529&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337280 Stats: 304 lines in 6 files changed: 299 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1529.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1529/head:pull/1529 PR: https://git.openjdk.org/jfx/pull/1529 From kcr at openjdk.org Thu Sep 5 21:18:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Sep 2024 21:18:03 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 21:29:15 GMT, Kevin Rushforth wrote: > Add the `jdk.jsobject` module to JavaFX. This module is currently delivered by the JDK, but will be terminally-deprecated in JDK 24 by [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530), which is out for review at openjdk/jdk#20555. We therefore plan to start delivering it with JavaFX in JavaFX 24. > > ### Testing scenarios > > Both JDK and JavaFX for some period of time, so we need to test various scenarios. I built and tested this PR branch with each of the following JDKs: > > 1. JDK 23 or earlier (I used the default boot JDK, which is currently JDK 22.0.2); this JDK includes `jdk.jsobject` as a normal, non-upgradable module > 2. A locally-built JDK 24 from my [8311530-depr-jsobject](https://github.com/kevinrushforth/jdk/tree/8311530-depr-jsobject) branch, which has the fix for [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530); this JDK includes `jdk.jsobject` as a terminally-deprecated, upgradable module > 3. A locally-built JDK 24 from my [WIP-rm-jsobject](https://github.com/kevinrushforth/jdk/tree/WIP-rm-jsobject) branch, which removes the `jdk.jsobject` module, and is therefore a prototype of what will happen in JDK 26 (or later) when it is removed from the JDK > > I ran a build and test of JavaFX from this PR branch using each of the above JDKs. All tests pass. > > I then took the JavaFX artifacts built by JDK 1 (matching how we will deliver this in JavaFX 24), and ran the following additional tests, all of which match my expectations: > > * java --module-path=.../jfx/build/sdk/lib without any additional flags (required for JDK 1; recommended for JDK 3)
    RESULT: JDKs 1 and 2 use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > * java --module-path=.../jfx/build/sdk/lib --upgrade-module-path=.../jfx/build/sdk/lib (recommended for JDK 2, OK for 3)
    RESULT: JDK 1 will fail to launch; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with .../jfx/build/jmods ahead of $JAVA_HOME/jmods (recommended for JDKs 2 and 3)
    RESULT: JDK 1 will fail to link; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with $JAVA_HOME/jmods ahead of .../jfx/build/jmods (required for JDK 1)
    RESULT: JDKs 1 and 2 will use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > > I have not verified the maven artifacts, but they are being generated correctly. modules/jdk.jsobject/src/main/java/netscape/javascript/JSObject.java line 52: > 50: static { > 51: System.err.println("KCR: JavaFX version of jdk.jsobject loaded"); > 52: } This debug print statement is there to make it easy to see if the JavaFX version of this class is being loaded. I'll leave it during testing and review, but I'll remove it before the final review. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1529#discussion_r1702335388 From angorya at openjdk.org Thu Sep 5 22:25:19 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Sep 2024 22:25:19 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - fixes and review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - improved vertical scrolling - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - cleanup - navigation - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - whitespace - update + review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - ... and 2 more: https://git.openjdk.org/jfx/compare/0d331264...bc1615c0 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/e035c166..bc1615c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=05-06 Stats: 915 lines in 28 files changed: 649 ins; 140 del; 126 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From duke at openjdk.org Thu Sep 5 23:23:56 2024 From: duke at openjdk.org (duke) Date: Thu, 5 Sep 2024 23:23:56 GMT Subject: Withdrawn: 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... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1462 From asarkar at openjdk.org Fri Sep 6 01:34:01 2024 From: asarkar at openjdk.org (Anirvan Sarkar) Date: Fri, 6 Sep 2024 01:34:01 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX In-Reply-To: References: Message-ID: <5Us9KmaG0lgxWKKMDoWdkiH3uSBXeiJ4KojImx6PLho=.2bf4cd56-ac33-42ed-93a0-08e1aa4ce69b@github.com> On Fri, 2 Aug 2024 21:29:15 GMT, Kevin Rushforth wrote: > Add the `jdk.jsobject` module to JavaFX. This module is currently delivered by the JDK, but will be terminally-deprecated in JDK 24 by [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530), which is out for review at openjdk/jdk#20555. We therefore plan to start delivering it with JavaFX in JavaFX 24. > > ### Testing scenarios > > Both JDK and JavaFX for some period of time, so we need to test various scenarios. I built and tested this PR branch with each of the following JDKs: > > 1. JDK 23 or earlier (I used the default boot JDK, which is currently JDK 22.0.2); this JDK includes `jdk.jsobject` as a normal, non-upgradable module > 2. A locally-built JDK 24 from my [8311530-depr-jsobject](https://github.com/kevinrushforth/jdk/tree/8311530-depr-jsobject) branch, which has the fix for [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530); this JDK includes `jdk.jsobject` as a terminally-deprecated, upgradable module > 3. A locally-built JDK 24 from my [WIP-rm-jsobject](https://github.com/kevinrushforth/jdk/tree/WIP-rm-jsobject) branch, which removes the `jdk.jsobject` module, and is therefore a prototype of what will happen in JDK 26 (or later) when it is removed from the JDK > > I ran a build and test of JavaFX from this PR branch using each of the above JDKs. All tests pass. > > I then took the JavaFX artifacts built by JDK 1 (matching how we will deliver this in JavaFX 24), and ran the following additional tests, all of which match my expectations: > > * java --module-path=.../jfx/build/sdk/lib without any additional flags (required for JDK 1; recommended for JDK 3)
    RESULT: JDKs 1 and 2 use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > * java --module-path=.../jfx/build/sdk/lib --upgrade-module-path=.../jfx/build/sdk/lib (recommended for JDK 2, OK for 3)
    RESULT: JDK 1 will fail to launch; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with .../jfx/build/jmods ahead of $JAVA_HOME/jmods (recommended for JDKs 2 and 3)
    RESULT: JDK 1 will fail to link; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with $JAVA_HOME/jmods ahead of .../jfx/build/jmods (required for JDK 1)
    RESULT: JDKs 1 and 2 will use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > > I have not verified the maven artifacts, but they are being generated correctly. settings.gradle line 1: > 1: /* The update to copyright year has been reverted by commit [33355b4](https://github.com/openjdk/jfx/pull/1529/commits/33355b487e03f37ea369402c68e98554f81493cc). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1529#discussion_r1746371063 From angorya at openjdk.org Fri Sep 6 03:20:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 03:20:59 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 17:15:14 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 f... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Improve test > - 8218745: TableView: visual glitch at borders on horizontal scrolling I think this PR should be reopened. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2333158738 From kneester77 at gmail.com Fri Sep 6 04:08:16 2024 From: kneester77 at gmail.com (Knee Snap) Date: Thu, 5 Sep 2024 21:08:16 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: Thanks everyone who has commented and given feedback. With no further discussion points brought up, I'd like to move this proposal along for review, and hopefully CSR creation. Is there anything I need to do besides say I'm ready to move forward? @Kevin Rushforth On Wed, Sep 4, 2024, 12:24?PM Knee Snap wrote: > I don't know what gamma refers to in the context of vertex colors, sorry. > > It's not using the gamma color space if that's the question (but neither > is the rest of JavaFX 3D). > > If gamma is meant as opacity, then setting the alpha color value will > control opacity. > > > > > > On Wed, Sep 4, 2024, 7:44?AM Andy Goryachev > wrote: > >> I am not a 3D expert; one question: how is the gamma value set for color >> interpolation? >> >> >> >> Thanks! >> >> -andy >> >> >> >> *From: *openjfx-dev on behalf of Knee >> Snap >> *Date: *Tuesday, September 3, 2024 at 23:53 >> *To: *openjfx-dev at openjdk.org >> *Subject: *[Feature Proposal]: TriangleMesh - Vertex Color Support >> >> Hello all, >> >> >> >> This is a continuation of a previous email thread: "[Feature Proposal] >> Vertex Colors on TriangleMesh". >> >> I'm creating a new email thread because after discussion I've put >> together a feature proposal, and it serves largely as a summary of the >> previous email thread. (Better organized as a feature proposal) >> >> >> >> *Feature Proposal:* >> https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md >> >> I had previously discussed a draft PR, but considering how simple the >> proposed public API additions are to discuss, I don't think it's actually >> that helpful. >> >> >> >> *What's next?* >> >> I'm currently happy with the design and seeing as it's been discussed >> already, I could probably ask Kevin for a review. But, I'd like to give >> another opportunity for design discussion before doing so, just in-case >> there are any further considerations brought up. >> >> So, I open up the floor again. Does anyone have any thoughts on this >> proposal? Concerns? Questions? Suggestions? Constructive criticism? I >> eagerly await the feedback. >> >> >> >> After API discussion concludes, I plan to pass it off to Kevin for >> review/approval, and if it is approved, the subsequent CSR creation. >> >> >> >> Thanks! >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asarkar at openjdk.org Fri Sep 6 05:06:56 2024 From: asarkar at openjdk.org (Anirvan Sarkar) Date: Fri, 6 Sep 2024 05:06:56 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX In-Reply-To: References: Message-ID: On Fri, 2 Aug 2024 21:29:15 GMT, Kevin Rushforth wrote: > Add the `jdk.jsobject` module to JavaFX. This module is currently delivered by the JDK, but will be terminally-deprecated in JDK 24 by [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530), which is out for review at openjdk/jdk#20555. We therefore plan to start delivering it with JavaFX in JavaFX 24. > > ### Testing scenarios > > Both JDK and JavaFX for some period of time, so we need to test various scenarios. I built and tested this PR branch with each of the following JDKs: > > 1. JDK 23 or earlier (I used the default boot JDK, which is currently JDK 22.0.2); this JDK includes `jdk.jsobject` as a normal, non-upgradable module > 2. A locally-built JDK 24 from my [8311530-depr-jsobject](https://github.com/kevinrushforth/jdk/tree/8311530-depr-jsobject) branch, which has the fix for [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530); this JDK includes `jdk.jsobject` as a terminally-deprecated, upgradable module > 3. A locally-built JDK 24 from my [WIP-rm-jsobject](https://github.com/kevinrushforth/jdk/tree/WIP-rm-jsobject) branch, which removes the `jdk.jsobject` module, and is therefore a prototype of what will happen in JDK 26 (or later) when it is removed from the JDK > > I ran a build and test of JavaFX from this PR branch using each of the above JDKs. All tests pass. > > I then took the JavaFX artifacts built by JDK 1 (matching how we will deliver this in JavaFX 24), and ran the following additional tests, all of which match my expectations: > > * java --module-path=.../jfx/build/sdk/lib without any additional flags (required for JDK 1; recommended for JDK 3)
    RESULT: JDKs 1 and 2 use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > * java --module-path=.../jfx/build/sdk/lib --upgrade-module-path=.../jfx/build/sdk/lib (recommended for JDK 2, OK for 3)
    RESULT: JDK 1 will fail to launch; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with .../jfx/build/jmods ahead of $JAVA_HOME/jmods (recommended for JDKs 2 and 3)
    RESULT: JDK 1 will fail to link; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with $JAVA_HOME/jmods ahead of .../jfx/build/jmods (required for JDK 1)
    RESULT: JDKs 1 and 2 will use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > > I have not verified the maven artifacts, but they are being generated correctly. Old version of classes `netscape.javascript.JSObject` and `netscape.javascript.JSException` seems to be delivered with JavaFX for Android [1]. Should these classes be removed? [1] : https://github.com/openjdk/jfx/tree/jfx23/modules/javafx.web/src/android/java/netscape/javascript ------------- PR Comment: https://git.openjdk.org/jfx/pull/1529#issuecomment-2333239507 From duke at openjdk.org Fri Sep 6 06:39:16 2024 From: duke at openjdk.org (Loay Ghreeb) Date: Fri, 6 Sep 2024 06:39:16 GMT Subject: RFR: 8301761: The sorting of the SortedList can become invalid [v3] In-Reply-To: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> Message-ID: > Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order. Loay Ghreeb has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into SortedList - Merge branch 'master' into SortedList - Merge branch 'master' into SortedList - Merge branch 'master' into SortedList - Add test case - Fix SortedList to maintain insertion order for equal elements ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1519/files - new: https://git.openjdk.org/jfx/pull/1519/files/15f1a9ab..0ef88ea8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1519&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1519&range=01-02 Stats: 28690 lines in 634 files changed: 15146 ins; 7862 del; 5682 mod Patch: https://git.openjdk.org/jfx/pull/1519.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1519/head:pull/1519 PR: https://git.openjdk.org/jfx/pull/1519 From jhendrikx at openjdk.org Fri Sep 6 10:01:06 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 6 Sep 2024 10:01:06 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v34] In-Reply-To: References: Message-ID: On Thu, 5 Sep 2024 20:55:37 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > javadoc changes Thanks for the refactoring, I think it was a net positive. This looks good to go. ------------- Marked as reviewed by jhendrikx (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2285760929 From mstrauss at openjdk.org Fri Sep 6 11:17:59 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Sep 2024 11:17:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v34] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 09:57:58 GMT, John Hendrikx wrote: > Thanks for the refactoring, I think it was a net positive. This looks good to go. I agree, thanks for the in-depth review! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2333831116 From johan at lodgon.com Fri Sep 6 13:31:02 2024 From: johan at lodgon.com (Johan Vos) Date: Fri, 6 Sep 2024 15:31:02 +0200 Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX In-Reply-To: References: Message-ID: Hi Kevin, Thanks for the extensive checks on these scenario's. I believe the scenario where jlink is used with an "old" JDK (e.g. 21) in combination with the most recent JavaFX release is very common. In that case, it seems to be required to prepend the module path with $JAVA_HOME/jmods, correct? If that is the case, we need to announce and explain it very well, as developers will run into it and get confused. - Johan Op do 5 sep 2024 om 23:18 schreef Kevin Rushforth : > Add the `jdk.jsobject` module to JavaFX. This module is currently > delivered by the JDK, but will be terminally-deprecated in JDK 24 by > [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530), which is out > for review at openjdk/jdk#20555. We therefore plan to start delivering it > with JavaFX in JavaFX 24. > > ### Testing scenarios > > Both JDK and JavaFX for some period of time, so we need to test various > scenarios. I built and tested this PR branch with each of the following > JDKs: > > 1. JDK 23 or earlier (I used the default boot JDK, which is currently JDK > 22.0.2); this JDK includes `jdk.jsobject` as a normal, non-upgradable module > 2. A locally-built JDK 24 from my [8311530-depr-jsobject]( > https://github.com/kevinrushforth/jdk/tree/8311530-depr-jsobject) branch, > which has the fix for [JDK-8311530]( > https://bugs.openjdk.org/browse/JDK-8311530); this JDK includes > `jdk.jsobject` as a terminally-deprecated, upgradable module > 3. A locally-built JDK 24 from my [WIP-rm-jsobject]( > https://github.com/kevinrushforth/jdk/tree/WIP-rm-jsobject) branch, which > removes the `jdk.jsobject` module, and is therefore a prototype of what > will happen in JDK 26 (or later) when it is removed from the JDK > > I ran a build and test of JavaFX from this PR branch using each of the > above JDKs. All tests pass. > > I then took the JavaFX artifacts built by JDK 1 (matching how we will > deliver this in JavaFX 24), and ran the following additional tests, all of > which match my expectations: > > * java --module-path=.../jfx/build/sdk/lib without any additional flags > (required for JDK 1; recommended for JDK 3)
    RESULT: JDKs 1 and 2 use > the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` > module from JavaFX > * java --module-path=.../jfx/build/sdk/lib > --upgrade-module-path=.../jfx/build/sdk/lib (recommended for JDK 2, OK for > 3)
    RESULT: JDK 1 will fail to launch; JDKs 2 and 3 use the > `jdk.jsobject` module from JavaFX > * jlink with .../jfx/build/jmods ahead of $JAVA_HOME/jmods (recommended > for JDKs 2 and 3)
    RESULT: JDK 1 will fail to link; JDKs 2 and 3 use > the `jdk.jsobject` module from JavaFX > * jlink with $JAVA_HOME/jmods ahead of .../jfx/build/jmods (required for > JDK 1)
    RESULT: JDKs 1 and 2 will use the `jdk.jsobject` module from > the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > > I have not verified the maven artifacts, but they are being generated > correctly. > > ------------- > > Commit messages: > - Merge branch 'master' into 8337280-jsobject > - Merge branch 'master' into 8337280-jsobject > - Merge branch 'master' into 8337280-jsobject > - Update copyright years > - Merge branch 'master' into 8337280-jsobject > - Update to pick up latest version from jdk master > - 8337280: Include jdk.jsobject module with JavaFX > > Changes: https://git.openjdk.org/jfx/pull/1529/files > Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1529&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8337280 > Stats: 304 lines in 6 files changed: 299 ins; 0 del; 5 mod > Patch: https://git.openjdk.org/jfx/pull/1529.diff > Fetch: git fetch https://git.openjdk.org/jfx.git > pull/1529/head:pull/1529 > > PR: https://git.openjdk.org/jfx/pull/1529 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Sep 6 15:15:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Sep 2024 15:15:11 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. If this PR goes forward, it will need a CSR, since it does impact source code compatibility. As you point out, you can't usefully extend Node today, since you will get a runtime exception as soon as you try to create an instance of a subclassed Node, so what this does is move a runtime error to compile time. That's generally a good thing, but..is it worth doing? We can continue to discuss. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334276448 From mstrauss at openjdk.org Fri Sep 6 15:39:08 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Sep 2024 15:39:08 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. > If this PR goes forward, it will need a CSR, since it does impact source code compatibility. As you point out, you can't usefully extend Node today, since you will get a runtime exception as soon as you try to create an instance of a subclassed Node, so what this does is move a runtime error to compile time. That's generally a good thing, but..is it worth doing? We can continue to discuss. > > /csr In addition to moving a runtime error to compile time, it also documents intent for future JavaFX maintainers. Given that the change is not invasive and has pretty much no downsides, I think it is worth it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334328180 From angorya at openjdk.org Fri Sep 6 15:44:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 15:44:09 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: <1OBXAtJuGvuy2QNcRDlq2ughOTiZ5b8C6QpVOWyGQjc=.e859c69d-33ad-4f69-ab83-8c987e8c5618@github.com> On Thu, 5 Sep 2024 17:45:52 GMT, Michael Strau? wrote: > The fact that you can't extend `Node` is a system invariant But I **can**, and the code provided above runs with no exception - in either `init()` or `start()`, making this change a breaking one. Whether such code is meaningful is another story. I would vote against this change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334337692 From mstrauss at openjdk.org Fri Sep 6 15:50:11 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Sep 2024 15:50:11 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <1OBXAtJuGvuy2QNcRDlq2ughOTiZ5b8C6QpVOWyGQjc=.e859c69d-33ad-4f69-ab83-8c987e8c5618@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> <1OBXAtJuGvuy2QNcRDlq2ughOTiZ5b8C6QpVOWyGQjc=.e859c69d-33ad-4f69-ab83-8c987e8c5618@github.com> Message-ID: On Fri, 6 Sep 2024 15:41:45 GMT, Andy Goryachev wrote: > > The fact that you can't extend `Node` is a system invariant > > But I **can**, and the code provided above runs with no exception - in either `init()` or `start()`, making this change a breaking one. > > Whether such code is meaningful is another story. > > I would vote against this change. But you just proved that you can violate a system invariant. The existing code tries to detect some violations and alerts you that extending Node is not supported by JavaFX. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334345965 From angorya at openjdk.org Fri Sep 6 15:57:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 15:57:12 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. can you point me to where it says one can't extend Node or that it is verboten? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334355868 From nlisker at openjdk.org Fri Sep 6 15:57:12 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 6 Sep 2024 15:57:12 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. I thought about doing this some years ago for `Shape3D`, `Material` and `LightBase` when I was adding light types. `Shape3D` states: > An application should not extend the Shape3D class directly. Doing so may lead to an UnsupportedOperationException being thrown. However, I didn't see enough value in this. There is some small benefit for `LightBase` because it allows an exhaustive switch on its subtypes in `NGShape3D` (IIRC). Also, for `Material` and `LightBase`, even before compile time - at code writing time - the user will find it impossible to subtype these. `Shape3D` can be made to allow inheritance as its subtypes don't require native-level handling. I assume that this is why it has a comment about subtyping, and there is more benefit in sealing it. The downside is minor too: custom shaders will allow user implementations, but that's not coming any time soon. Since removing `sealed`/`final` from a class can be done in the future without much hassle, I'm not against sealing the above classes (and removing the comments about not extending them). It just doesn't overcome the initial inertia for me. I will review the changes for these classes if this goes forward. As for `Node` and `Shape`, I didn't look at subclassing them and never thought about it, so I have no opinion there. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334357687 From mstrauss at openjdk.org Fri Sep 6 15:57:13 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Sep 2024 15:57:13 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Fri, 6 Sep 2024 15:52:17 GMT, Andy Goryachev wrote: > can you point me to where it says one can't extend Node or that it is verboten? https://github.com/openjdk/jfx/blob/4647367ce4590440fbb85675055225c869502314/modules/javafx.graphics/src/main/java/com/sun/javafx/scene/NodeHelper.java#L81 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334358365 From nlisker at openjdk.org Fri Sep 6 16:05:08 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 6 Sep 2024 16:05:08 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. The documentation for `Node` has the line: > An application should not extend the Node class directly. Doing so may lead to an UnsupportedOperationException being thrown. Just above [StringID](https://openjfx.io/javadoc/22/javafx.graphics/javafx/scene/Node.html#StringID). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334367839 From angorya at openjdk.org Fri Sep 6 16:05:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 16:05:08 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: <70g7-BIO8GoIpWCIqOfWMH0V3V8u2xj1k35kAqHw3DA=.da84012c-4965-4a71-9271-5df0d7122005@github.com> On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. a comment in some internal helper class is not, in my opinion, a normative reference. I am not against this change in principle - it might be a welcome enhancement, if it were solving a real world problem. I am against this change because it has a risk of existing application failing (compatibility risk). App developers are a creative bunch, they often do things that the platform developers did not expect. "should" and "may" are not the same as "must" and "will". but anyway, my objection is due to possible compatibility risk. edit: +1 for rtfm :-) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334369533 PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334372515 From nlisker at openjdk.org Fri Sep 6 16:10:08 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 6 Sep 2024 16:10:08 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. I forgot to mention `Camera` in my reply. Same as the 3D classes: the user can't do it if they try, so it will fail before compilation. I don't mind sealing it and will review changes for this as well. I also wonder if there are even other camera types in the literature and if the class can be built for subtyping at all. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334382994 From angorya at openjdk.org Fri Sep 6 16:15:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 16:15:16 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v34] In-Reply-To: References: Message-ID: On Thu, 5 Sep 2024 20:55:37 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > javadoc changes Testing this with the monkey tester. Select Button page, open CSS Playground, pasted the following CSS, click update. .test-content .button { -fx-border-color: red; -fx-border-width: 5; transition: -fx-border-color 1s linear, -fx-border-width 4s ease; } .test-content .button:hover { -fx-border-color: green; -fx-border-width: 200; } Changed value for `-fx-border-width: 200;` in `.test-content .button:hover { ` and clicked update (may need to do it several times). (the exact sequence was 10, 100, 1000, 200) Got Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "javafx.scene.layout.Border.getStrokes()" because "border" is null at javafx.graphics/javafx.scene.layout.BorderConverter.convertBack(BorderConverter.java:212) at javafx.graphics/javafx.scene.layout.BorderConverter.convertBack(BorderConverter.java:1) at javafx.graphics/javafx.css.StyleableObjectProperty.applyComponents(StyleableObjectProperty.java:159) at javafx.graphics/javafx.css.StyleableObjectProperty.applyStyle(StyleableObjectProperty.java:87) at javafx.graphics/javafx.scene.CssStyleHelper.resetToInitialValues(CssStyleHelper.java:485) at javafx.graphics/javafx.scene.CssStyleHelper.createStyleHelper(CssStyleHelper.java:193) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9874) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCss(Node.java:9903) at javafx.graphics/javafx.scene.Node.reapplyCSS(Node.java:9837) at javafx.graphics/javafx.scene.Scene$3.onChanged(Scene.java:1632) at javafx.base/com.sun.javafx.collections.TrackableObservableList.lambda$0(TrackableObservableList.java:44) at javafx.base/com.sun.javafx.collections.ListListenerHelper$SingleChange.fireValueChangedEvent(ListListenerHelper.java:162) at javafx.base/com.sun.javafx.collections.ListListenerHelper.fireValueChangedEvent(ListListenerHelper.java:71) at javafx.base/javafx.collections.ObservableListBase.fireChange(ObservableListBase.java:246) at javafx.base/javafx.collections.ListChangeBuilder.commit(ListChangeBuilder.java:482) at javafx.base/javafx.collections.ListChangeBuilder.endChange(ListChangeBuilder.java:541) at javafx.base/javafx.collections.ObservableListBase.endChange(ObservableListBase.java:210) at javafx.base/javafx.collections.ModifiableObservableListBase.remove(ModifiableObservableListBase.java:228) at javafx.base/javafx.collections.ModifiableObservableListBase.remove(ModifiableObservableListBase.java:216) at monkey_tester/com.oracle.tools.fx.monkey.tools.CssPlaygroundPane.applyStyleSheet(CssPlaygroundPane.java:204) at monkey_tester/com.oracle.tools.fx.monkey.tools.CssPlaygroundPane.update(CssPlaygroundPane.java:147) at monkey_tester/com.oracle.tools.fx.monkey.util.FX.lambda$5(FX.java:331) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49) at javafx.base/javafx.event.Event.fireEvent(Event.java:199) at javafx.graphics/javafx.scene.Node.fireEvent(Node.java:8975) at javafx.controls/javafx.scene.control.Button.fire(Button.java:203) at javafx.controls/com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:207) at javafx.controls/com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274) at javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247) at javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232) at javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189) at javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56) at javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114) at javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74) at javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54) at javafx.base/javafx.event.Event.fireEvent(Event.java:199) at javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3987) at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1893) at javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2711) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:1) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(GlassViewEventHandler.java:450) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449) at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:560) at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:946) at javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(MacView.java:128) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2334392278 From angorya at openjdk.org Fri Sep 6 16:18:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 16:18:09 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: <0CRrkk_Z2uwquxqdOJ-i7ZBq0hxgWNuWZZUyAcbaAiw=.7103b696-fc9f-4727-a8d4-b52437d1cdb6@github.com> On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. I wonder if it is possible to have some kind of interim solution that will warn the app developers that they are doing something they are not supposed to? - Printing a warning won't work: it will be ignored. - Shutting down the app (and allowing it to run with a system property) is probably even worse What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334397161 From mstrauss at openjdk.org Fri Sep 6 16:26:12 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Sep 2024 16:26:12 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <70g7-BIO8GoIpWCIqOfWMH0V3V8u2xj1k35kAqHw3DA=.da84012c-4965-4a71-9271-5df0d7122005@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> <70g7-BIO8GoIpWCIqOfWMH0V3V8u2xj1k35kAqHw3DA=.da84012c-4965-4a71-9271-5df0d7122005@github.com> Message-ID: On Fri, 6 Sep 2024 16:01:55 GMT, Andy Goryachev wrote: > "should" and "may" are not the same as "must" and "will". I think this is just suboptimal language, and not a material distinction. You _will_ get a runtime error if you use it in any meaningful way. Anyway, if a developer _really_ wants to create an instance of `Node`, they can use the non-exported `AbstractNode` at their own peril. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334409097 From kcr at openjdk.org Fri Sep 6 16:30:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Sep 2024 16:30:09 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> <70g7-BIO8GoIpWCIqOfWMH0V3V8u2xj1k35kAqHw3DA=.da84012c-4965-4a71-9271-5df0d7122005@github.com> Message-ID: On Fri, 6 Sep 2024 16:23:22 GMT, Michael Strau? wrote: > > "should" and "may" are not the same as "must" and "will". > > I think this is just suboptimal language, and not a material distinction. You _will_ get a runtime error if you use it in any meaningful way. Anyway, if a developer _really_ wants to create an instance of `Node`, they can use the non-exported `AbstractNode` at their own peril. Indeed it is a case of suboptimal language. The intention was to make it clear that this is _not_ supported. Period. And it isn't in any meaningful way. If there are corner cases where we miss throwing an exception, that is a bug. There might be other reasons to not make this change -- I haven't formed an opinion yet -- but concern over compatibility isn't one of them. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1556#issuecomment-2334415657 From angorya at openjdk.org Fri Sep 6 16:41:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 16:41:18 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v34] In-Reply-To: References: Message-ID: On Thu, 5 Sep 2024 20:55:37 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > javadoc changes reproducible. you may need to restart the app. did not see the exception all the time, but got it again changing `-fx-border-width:` in the hover state from 20 to 200 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2334434952 From angorya at openjdk.org Fri Sep 6 16:52:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 16:52:10 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v3] In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 17:15:14 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 f... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Improve test > - 8218745: TableView: visual glitch at borders on horizontal scrolling Marked as reviewed by angorya (Reviewer). @arapte could you be a second reviewer? ------------- PR Review: https://git.openjdk.org/jfx/pull/1462#pullrequestreview-2286745959 PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2334452367 From angorya at openjdk.org Fri Sep 6 16:59:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 16:59:12 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 421: > 419: public abstract sealed class Node > 420: implements EventTarget, Styleable > 421: permits AbstractNode, Camera, LightBase, Parent, SubScene, Canvas, ImageView, Shape, Shape3D { We may need to use stronger wording in javadoc in regards to extending Nodes. should -> must, etc. (or, rather, 'cannot' and possibly explain why?) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1556#discussion_r1747442948 From mstrauss at openjdk.org Fri Sep 6 17:09:31 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Sep 2024 17:09:31 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v35] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fixed a bug when null values require discrete transitions ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/75e7d98b..acdec110 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=34 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=33-34 Stats: 36 lines in 2 files changed: 27 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Fri Sep 6 17:09:31 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Sep 2024 17:09:31 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v34] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 16:38:41 GMT, Andy Goryachev wrote: > reproducible. you may need to restart the app. did not see the exception all the time, but got it again changing `-fx-border-width:` in the hover state from 20 to 200 Good catch! The cause for this bug was that when the old value or the new value is `null`, we fall back to a discrete transition. This wasn't happening in one particular scenario. I also added a test for this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2334481402 From angorya at openjdk.org Fri Sep 6 18:46:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 18:46:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v35] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 17:09:31 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed a bug when null values require discrete transitions I can't think of any other weird scenario to test. Monumental job, thank you @mstr2 ! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2286949973 From mstrauss at openjdk.org Fri Sep 6 18:50:15 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Sep 2024 18:50:15 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v34] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 17:06:44 GMT, Michael Strau? wrote: >> reproducible. you may need to restart the app. did not see the exception all the time, but got it again changing `-fx-border-width:` in the hover state from 20 to 200 > >> reproducible. you may need to restart the app. did not see the exception all the time, but got it again changing `-fx-border-width:` in the hover state from 20 to 200 > > Good catch! The cause for this bug was that when the old value or the new value is `null`, we fall back to a discrete transition. This wasn't happening in one particular scenario. I also added a test for this. > I can't think of any other weird scenario to test. Monumental job, thank you @mstr2 ! Thanks for all the testing and feedback! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2334631715 From angorya at openjdk.org Fri Sep 6 18:58:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 18:58:10 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v2] In-Reply-To: References: Message-ID: On Tue, 4 Jun 2024 12:33:06 GMT, Marius Hanl wrote: >> you are right: I see the focus rectangle jitter at 175% scale on win 11 (w/o the fix), so it must be a different issue. At this scale, it merely shows a thinner line, perhaps that's why I did not notice it earlier. > >> you are right: I see the focus rectangle jitter at 175% scale on win 11 (w/o the fix), so it must be a different issue. At this scale, it merely shows a thinner line, perhaps that's why I did not notice it earlier. > > Yeah exactly, it looks like when the focus rect is on the border of the window, it will sometimes disappear (probably jitter 'out' of the window). > When there is some padding inbetween, the focus rect looks like it is jittering instead. Probably the same root cause. @Maran23 please resolve the merge conflict ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2334642254 From angorya at openjdk.org Fri Sep 6 22:05:28 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 22:05:28 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v35] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 17:09:31 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed a bug when null values require discrete transitions Not sure if this is related, but I got an exception flipping through the monkey tester pages using this PR's workspace: *** this=TitledPane at 2d49c3a1[styleClass=titled-pane]'Source' validatePG children[1].parent= null Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "javafx.scene.Node.getScene()" because "node" is null at javafx.graphics/javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2486) at javafx.graphics/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2633) at javafx.graphics/com.sun.javafx.tk.Toolkit.lambda$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at javafx.graphics/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:598) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:578) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:571) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$11(QuantumToolkit.java:352) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2334867100 From kcr at openjdk.org Fri Sep 6 22:11:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Sep 2024 22:11:17 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: Message-ID: On Thu, 5 Sep 2024 22:25:19 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - fixes and review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - improved vertical scrolling > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - cleanup > - navigation > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - update + review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - ... and 2 more: https://git.openjdk.org/jfx/compare/5e2143b1...bc1615c0 Tha change in StyledTextModel from userEditable --> writable looks good to me. I left a few related javadoc comments and one question. I wrote a very simple test, something you might see in a "HelloRichTextArea", and it seems quite easy to get started. It did prompt a couple quick suggestions: `RichTextArea`: * Do you think it is worth adding a convenience method `appendText(String)` that calls `appendText(String, StyleAttributeMap.EMPTY)`? `StyleAttributeMap`: * `fromInlineStyle(String style)` This method seems redundant: `fromInlineStyle(style)` and `fromStyles(style)` are equivalent. Do we need both? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1030: > 1028: * sequences result in a new paragraph being added. > 1029: *

    > 1030: * This method is no-op if either the control or the model is not editable. It is up to the model This method doesn't depend on the editable state of the control at all, and will now throw and exception if the module is null or not writable. This applies to the other programmatic editing methods, too: `appendText(StyledInput)`, `insertText()`, `replaceText()`, `applyStyle()`, `setStyle()`, and `clear()`. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1076: > 1074: * When selection exists, deletes selected text. Otherwise, deletes the character preceding the caret, > 1075: * possibly breaking up the grapheme clusters. > 1076: * This method does nothing if either control or the model is not editable, or the caret position is {@code null}. Suggestion for here and similar methods: "does nothing if the control is not editable or the model is not writable..." modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1088: > 1086: /** > 1087: * Clears the document, creating an undo entry. > 1088: * This method does nothing if either control or the model is not editable. Remove this sentence and add the needed `@throws` modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1143: > 1141: * removing the current selection. > 1142: *

    > 1143: * This method does nothing if either control or the model is not editable, or the caret position is {@code null}. As implemented, this method will do the copy, but not the associated delete. Is this intentional? If so, the spec should be changed to clarify that (else the spec is correct and the impl is wrong). modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 2096: > 2094: * might be wider than one specified. > 2095: *

    > 2096: * This method does nothing if either control or the model is not editable. Remove this sentence. ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2287196466 PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2334872667 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1747749446 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1747747945 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1747754883 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1747757825 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1747752042 From mstrauss at openjdk.org Fri Sep 6 22:16:23 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Sep 2024 22:16:23 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v35] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 22:02:04 GMT, Andy Goryachev wrote: > Not sure if this is related, but I got an exception flipping through the monkey tester pages using this PR's workspace: Usually, the go-to explanation for this has something to do with different threads accessing the scene graph. Since we're not dealing with other threads here, maybe it is related to [this](https://mail.openjdk.org/pipermail/openjfx-dev/2024-August/048738.html)? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2334877598 From angorya at openjdk.org Fri Sep 6 22:16:23 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 22:16:23 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v35] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 17:09:31 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed a bug when null values require discrete transitions ^^ this is unrelated, present in the master branch. something was added recently. investigating... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2334877821 From kcr at openjdk.org Fri Sep 6 22:42:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Sep 2024 22:42:16 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v9] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:45:02 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Reject CSS where compound selectors don't consist of simple selectors Looks good. And I think the CSR is ready to Finalize. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2287244251 From kcr at openjdk.org Fri Sep 6 22:46:33 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Sep 2024 22:46:33 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 05:04:11 GMT, Anirvan Sarkar wrote: > Old version of classes `netscape.javascript.JSObject` and `netscape.javascript.JSException` seems to be delivered with JavaFX for Android [1]. > > Should these classes be removed? > > [1] : https://github.com/openjdk/jfx/tree/jfx23/modules/javafx.web/src/android/java/netscape/javascript I'll let @johanvos speak to that. If this is desired, then it's probably best done as a follow-up, since I can't test the Android (or iOS) implementation. > settings.gradle line 1: > >> 1: /* > > The update to copyright year has been reverted by commit [33355b4](https://github.com/openjdk/jfx/pull/1529/commits/33355b487e03f37ea369402c68e98554f81493cc). I can't remember why I did that, but I'll redo the change to 2024. Thanks. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1529#issuecomment-2334907092 PR Review Comment: https://git.openjdk.org/jfx/pull/1529#discussion_r1747786919 From kcr at openjdk.org Fri Sep 6 22:56:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Sep 2024 22:56:37 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX In-Reply-To: References: Message-ID: <_8AWRqSByFwjLaX6NnVyAgP1IW2LZxb1coH35MOYhSQ=.7a144fa6-e60f-434e-ba79-3c20a54e8971@github.com> On Fri, 6 Sep 2024 13:32:49 GMT, Johan Vos wrote: > I believe the scenario where jlink is used with an "old" JDK (e.g. 21) in combination with the most recent JavaFX release is very common. In that case, it seems to be required to prepend the module path with $JAVA_HOME/jmods, correct? Yes. > If that is the case, we need to announce and explain it very well, as developers will run into it and get confused. Agreed. I've marked this RFE as needing a release note, and will be sure to clarify this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1529#issuecomment-2334913596 From kcr at openjdk.org Fri Sep 6 22:56:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Sep 2024 22:56:37 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX [v2] In-Reply-To: References: Message-ID: > Add the `jdk.jsobject` module to JavaFX. This module is currently delivered by the JDK, but will be terminally-deprecated in JDK 24 by [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530), which is out for review at openjdk/jdk#20555. We therefore plan to start delivering it with JavaFX in JavaFX 24. > > ### Testing scenarios > > Both JDK and JavaFX for some period of time, so we need to test various scenarios. I built and tested this PR branch with each of the following JDKs: > > 1. JDK 23 or earlier (I used the default boot JDK, which is currently JDK 22.0.2); this JDK includes `jdk.jsobject` as a normal, non-upgradable module > 2. A locally-built JDK 24 from my [8311530-depr-jsobject](https://github.com/kevinrushforth/jdk/tree/8311530-depr-jsobject) branch, which has the fix for [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530); this JDK includes `jdk.jsobject` as a terminally-deprecated, upgradable module > 3. A locally-built JDK 24 from my [WIP-rm-jsobject](https://github.com/kevinrushforth/jdk/tree/WIP-rm-jsobject) branch, which removes the `jdk.jsobject` module, and is therefore a prototype of what will happen in JDK 26 (or later) when it is removed from the JDK > > I ran a build and test of JavaFX from this PR branch using each of the above JDKs. All tests pass. > > I then took the JavaFX artifacts built by JDK 1 (matching how we will deliver this in JavaFX 24), and ran the following additional tests, all of which match my expectations: > > * java --module-path=.../jfx/build/sdk/lib without any additional flags (required for JDK 1; recommended for JDK 3)
    RESULT: JDKs 1 and 2 use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > * java --module-path=.../jfx/build/sdk/lib --upgrade-module-path=.../jfx/build/sdk/lib (recommended for JDK 2, OK for 3)
    RESULT: JDK 1 will fail to launch; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with .../jfx/build/jmods ahead of $JAVA_HOME/jmods (recommended for JDKs 2 and 3)
    RESULT: JDK 1 will fail to link; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with $JAVA_HOME/jmods ahead of .../jfx/build/jmods (required for JDK 1)
    RESULT: JDKs 1 and 2 will use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > > I have not verified the maven artifacts, but they are being generated correctly. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Update copyright year in settings.gradle ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1529/files - new: https://git.openjdk.org/jfx/pull/1529/files/182fb1f0..bb9a3b62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1529&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1529&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1529.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1529/head:pull/1529 PR: https://git.openjdk.org/jfx/pull/1529 From kcr at openjdk.org Fri Sep 6 23:09:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Sep 2024 23:09:23 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 [v2] In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 14:40:45 GMT, Andy Goryachev wrote: > Just a suggestion - sharing some tricks of writing the .md format: > > It might be easier to review if the pipe characters in the table were aligned, and have at least one space separation from the previous cell's text. This makes it easier to read in a code editor and does not produce spelling errors when the raw text is pasted in Word. I'll consider this for next time if not too much extra work. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2334922186 From angorya at openjdk.org Fri Sep 6 23:20:29 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Sep 2024 23:20:29 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v35] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 17:09:31 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed a bug when null values require discrete transitions ^^ please disregard - this might have been some stale object remaining in eclipse, despite relaunching it, cleaning, etc. etc. had to manually modify the DnDPage.java and then revert it for the thing to work. Sorry for the noise. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2334929217 From kneester77 at gmail.com Fri Sep 6 23:32:13 2024 From: kneester77 at gmail.com (Knee Snap) Date: Fri, 6 Sep 2024 16:32:13 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: Hi all, while waiting on Kevin to review the feature proposal (if I understand the process correctly), I have created a draft PR if anyone wants to have a look. It's not clear to me if we should be discussing implementation yet, the guide seems to contradict itself at points. But I think since we seem to have no further design discussion points we're okay to talk about implementation? Draft PR: https://github.com/openjdk/jfx/pull/1557 On Thu, Sep 5, 2024 at 9:08?PM Knee Snap wrote: > Thanks everyone who has commented and given feedback. > > With no further discussion points brought up, I'd like to move this > proposal along for review, and hopefully CSR creation. > > Is there anything I need to do besides say I'm ready to move forward? @Kevin > Rushforth > > > > On Wed, Sep 4, 2024, 12:24?PM Knee Snap wrote: > >> I don't know what gamma refers to in the context of vertex colors, sorry. >> >> It's not using the gamma color space if that's the question (but neither >> is the rest of JavaFX 3D). >> >> If gamma is meant as opacity, then setting the alpha color value will >> control opacity. >> >> >> >> >> >> On Wed, Sep 4, 2024, 7:44?AM Andy Goryachev >> wrote: >> >>> I am not a 3D expert; one question: how is the gamma value set for color >>> interpolation? >>> >>> >>> >>> Thanks! >>> >>> -andy >>> >>> >>> >>> *From: *openjfx-dev on behalf of Knee >>> Snap >>> *Date: *Tuesday, September 3, 2024 at 23:53 >>> *To: *openjfx-dev at openjdk.org >>> *Subject: *[Feature Proposal]: TriangleMesh - Vertex Color Support >>> >>> Hello all, >>> >>> >>> >>> This is a continuation of a previous email thread: "[Feature Proposal] >>> Vertex Colors on TriangleMesh". >>> >>> I'm creating a new email thread because after discussion I've put >>> together a feature proposal, and it serves largely as a summary of the >>> previous email thread. (Better organized as a feature proposal) >>> >>> >>> >>> *Feature Proposal:* >>> https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md >>> >>> I had previously discussed a draft PR, but considering how simple the >>> proposed public API additions are to discuss, I don't think it's actually >>> that helpful. >>> >>> >>> >>> *What's next?* >>> >>> I'm currently happy with the design and seeing as it's been discussed >>> already, I could probably ask Kevin for a review. But, I'd like to give >>> another opportunity for design discussion before doing so, just in-case >>> there are any further considerations brought up. >>> >>> So, I open up the floor again. Does anyone have any thoughts on this >>> proposal? Concerns? Questions? Suggestions? Constructive criticism? I >>> eagerly await the feedback. >>> >>> >>> >>> After API discussion concludes, I plan to pass it off to Kevin for >>> review/approval, and if it is approved, the subsequent CSR creation. >>> >>> >>> >>> Thanks! >>> >>> >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Sun Sep 8 08:41:10 2024 From: jvos at openjdk.org (Johan Vos) Date: Sun, 8 Sep 2024 08:41:10 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 22:43:11 GMT, Kevin Rushforth wrote: > > Old version of classes `netscape.javascript.JSObject` and `netscape.javascript.JSException` seems to be delivered with JavaFX for Android [1]. > > Should these classes be removed? > > [1] : https://github.com/openjdk/jfx/tree/jfx23/modules/javafx.web/src/android/java/netscape/javascript > > I'll let @johanvos speak to that. If this is desired, then it's probably best done as a follow-up, since I can't test the Android (or iOS) implementation. Yes, those can be removed. There is more (ios/android) code that can be removed, or that even *should* be removed. I'll file a follow-up for this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1529#issuecomment-2336599646 From jvos at openjdk.org Sun Sep 8 08:44:11 2024 From: jvos at openjdk.org (Johan Vos) Date: Sun, 8 Sep 2024 08:44:11 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX [v2] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 22:56:37 GMT, Kevin Rushforth wrote: >> Add the `jdk.jsobject` module to JavaFX. This module is currently delivered by the JDK, but will be terminally-deprecated in JDK 24 by [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530), which is out for review at openjdk/jdk#20555. We therefore plan to start delivering it with JavaFX in JavaFX 24. >> >> ### Testing scenarios >> >> Both JDK and JavaFX for some period of time, so we need to test various scenarios. I built and tested this PR branch with each of the following JDKs: >> >> 1. JDK 23 or earlier (I used the default boot JDK, which is currently JDK 22.0.2); this JDK includes `jdk.jsobject` as a normal, non-upgradable module >> 2. A locally-built JDK 24 from my [8311530-depr-jsobject](https://github.com/kevinrushforth/jdk/tree/8311530-depr-jsobject) branch, which has the fix for [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530); this JDK includes `jdk.jsobject` as a terminally-deprecated, upgradable module >> 3. A locally-built JDK 24 from my [WIP-rm-jsobject](https://github.com/kevinrushforth/jdk/tree/WIP-rm-jsobject) branch, which removes the `jdk.jsobject` module, and is therefore a prototype of what will happen in JDK 26 (or later) when it is removed from the JDK >> >> I ran a build and test of JavaFX from this PR branch using each of the above JDKs. All tests pass. >> >> I then took the JavaFX artifacts built by JDK 1 (matching how we will deliver this in JavaFX 24), and ran the following additional tests, all of which match my expectations: >> >> * java --module-path=.../jfx/build/sdk/lib without any additional flags (required for JDK 1; recommended for JDK 3)
    RESULT: JDKs 1 and 2 use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX >> * java --module-path=.../jfx/build/sdk/lib --upgrade-module-path=.../jfx/build/sdk/lib (recommended for JDK 2, OK for 3)
    RESULT: JDK 1 will fail to launch; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX >> * jlink with .../jfx/build/jmods ahead of $JAVA_HOME/jmods (recommended for JDKs 2 and 3)
    RESULT: JDK 1 will fail to link; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX >> * jlink with $JAVA_HOME/jmods ahead of .../jfx/build/jmods (required for JDK 1)
    RESULT: JDKs 1 and 2 will use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX >> >> I have not verified the maven artifacts, but they are being generated correctly. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year in settings.gradle > > > Old version of classes `netscape.javascript.JSObject` and `netscape.javascript.JSException` seems to be delivered with JavaFX for Android [1]. > > > Should these classes be removed? > > > [1] : https://github.com/openjdk/jfx/tree/jfx23/modules/javafx.web/src/android/java/netscape/javascript > > > > > > I'll let @johanvos speak to that. If this is desired, then it's probably best done as a follow-up, since I can't test the Android (or iOS) implementation. > > Yes, those can be removed. There is more (ios/android) code that can be removed, or that even _should_ be removed. I'll file a follow-up for this. Created https://bugs.openjdk.org/browse/JDK-8339705 for this ------------- PR Comment: https://git.openjdk.org/jfx/pull/1529#issuecomment-2336600640 From mstrauss at openjdk.org Sun Sep 8 19:45:26 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 8 Sep 2024 19:45:26 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D [v2] In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: remove documentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1556/files - new: https://git.openjdk.org/jfx/pull/1556/files/c24aed5c..38b7a22e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1556&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1556&range=00-01 Stats: 23 lines in 5 files changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1556.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1556/head:pull/1556 PR: https://git.openjdk.org/jfx/pull/1556 From mstrauss at openjdk.org Sun Sep 8 19:49:11 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 8 Sep 2024 19:49:11 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D [v2] In-Reply-To: References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: <7rytaGww78r1hqGo5lj_2b6XlAvVdL1TLMN7TeNT8UE=.d0f43f9b-c883-4410-b3ab-f07538a08e59@github.com> On Fri, 6 Sep 2024 16:56:43 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> remove documentation > > modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 421: > >> 419: public abstract sealed class Node >> 420: implements EventTarget, Styleable >> 421: permits AbstractNode, Camera, LightBase, Parent, SubScene, Canvas, ImageView, Shape, Shape3D { > > We may need to use stronger wording in javadoc in regards to extending Nodes. should -> must, etc. (or, rather, 'cannot' and possibly explain why?) I've removed the language that you can't extend those classes, as it is now redundant because it is enforced by the compiler. We shouldn't document obvious facts without providing any added value (for example, adding context and reasoning _why_ it's the way it is). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1556#discussion_r1749339201 From mstrauss at openjdk.org Sun Sep 8 20:55:53 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 8 Sep 2024 20:55:53 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: small doc changes, copyright header ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/acdec110..f9187a1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=35 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=34-35 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From angorya at openjdk.org Mon Sep 9 14:41:19 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 14:41:19 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Sun, 8 Sep 2024 20:55:53 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small doc changes, copyright header Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2290130650 From angorya at openjdk.org Mon Sep 9 14:46:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 14:46:14 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v9] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:45:02 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Reject CSS where compound selectors don't consist of simple selectors can't review if my questions are not answered. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2338321957 From angorya at openjdk.org Mon Sep 9 15:12:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 15:12:16 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 21:42:25 GMT, Kevin Rushforth 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 12 additional commits since the last revision: >> >> - fixes and review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - improved vertical scrolling >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - cleanup >> - navigation >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - update + review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - ... and 2 more: https://git.openjdk.org/jfx/compare/60aa6171...bc1615c0 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1076: > >> 1074: * When selection exists, deletes selected text. Otherwise, deletes the character preceding the caret, >> 1075: * possibly breaking up the grapheme clusters. >> 1076: * This method does nothing if either control or the model is not editable, or the caret position is {@code null}. > > Suggestion for here and similar methods: > > "does nothing if the control is not editable or the model is not writable..." changed this and similar methods to throw an exception ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1750448259 From angorya at openjdk.org Mon Sep 9 15:35:19 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 15:35:19 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 21:44:39 GMT, Kevin Rushforth 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 12 additional commits since the last revision: >> >> - fixes and review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - improved vertical scrolling >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - cleanup >> - navigation >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - update + review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - ... and 2 more: https://git.openjdk.org/jfx/compare/9ac571eb...bc1615c0 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1030: > >> 1028: * sequences result in a new paragraph being added. >> 1029: *

    >> 1030: * This method is no-op if either the control or the model is not editable. It is up to the model > > This method doesn't depend on the editable state of the control at all, and will now throw and exception if the module is null or not writable. > > This applies to the other programmatic editing methods, too: `appendText(StyledInput)`, `insertText()`, `replaceText()`, `applyStyle()`, `setStyle()`, and `clear()`. fixed > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1088: > >> 1086: /** >> 1087: * Clears the document, creating an undo entry. >> 1088: * This method does nothing if either control or the model is not editable. > > Remove this sentence and add the needed `@throws` done > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 2096: > >> 2094: * might be wider than one specified. >> 2095: *

    >> 2096: * This method does nothing if either control or the model is not editable. > > Remove this sentence. done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1750482524 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1750483779 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1750483101 From angorya at openjdk.org Mon Sep 9 16:07:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 16:07:14 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 21:57:16 GMT, Kevin Rushforth 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 12 additional commits since the last revision: >> >> - fixes and review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - improved vertical scrolling >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - cleanup >> - navigation >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - update + review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - ... and 2 more: https://git.openjdk.org/jfx/compare/5caa606d...bc1615c0 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1143: > >> 1141: * removing the current selection. >> 1142: *

    >> 1143: * This method does nothing if either control or the model is not editable, or the caret position is {@code null}. > > As implemented, this method will do the copy, but not the associated delete. Is this intentional? If so, the spec should be changed to clarify that (else the spec is correct and the impl is wrong). clarified. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1750536067 From angorya at openjdk.org Mon Sep 9 16:18:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 16:18:11 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: Message-ID: On Fri, 6 Sep 2024 22:08:05 GMT, Kevin Rushforth wrote: > This method seems redundant: `fromInlineStyle(style)` and `fromStyles(style)` are equivalent. Do we need both? These are not the same. `fromInlineStyle(String)` accepts as single string containing fx-style CSS with one more more styles. Example: `"-fx-fill:red; -fx-font-size:200%;"` `fromStyles(String style, String ... names)` is more generic, allows for setting the inline style as well as CSS stylesheet names. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2338535639 From angorya at openjdk.org Mon Sep 9 16:24:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 16:24:10 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v8] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision: - moved to apps, review comments - bsd license for sample code ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/bc1615c0..1d511bf3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=06-07 Stats: 12622 lines in 148 files changed: 11307 ins; 442 del; 873 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From jhendrikx at openjdk.org Mon Sep 9 16:32:14 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 9 Sep 2024 16:32:14 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v9] In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 16:47:12 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Reject CSS where compound selectors don't consist of simple selectors > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 109: > >> 107: >> 108: if (type != TYPE_SIMPLE) { >> 109: throw new IllegalStateException("Expected compound selector to consist of simple selectors only, but found type: " + type); > > minor: the output will be a signed decimal. would it be better if this can be formatted as hex? > > `String.format("Expected compound selector to consist of TYPE_SIMPLE only, but found type: 0x%02X", type)` I don't think that would matter much. This error will only ever be interpreted by programmers, I'm sure they'll be able to understand what's going on. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1750569742 From kcr at openjdk.org Mon Sep 9 16:36:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Sep 2024 16:36:13 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v9] In-Reply-To: References: Message-ID: <5omdccwxxQldlWFD4ynZXC1ufhdFwW5ieNF0gOaM1wk=.30d74dd2-3c6a-4b88-87be-9d3e69af2727@github.com> On Mon, 9 Sep 2024 16:29:25 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java line 109: >> >>> 107: >>> 108: if (type != TYPE_SIMPLE) { >>> 109: throw new IllegalStateException("Expected compound selector to consist of simple selectors only, but found type: " + type); >> >> minor: the output will be a signed decimal. would it be better if this can be formatted as hex? >> >> `String.format("Expected compound selector to consist of TYPE_SIMPLE only, but found type: 0x%02X", type)` > > I don't think that would matter much. This error will only ever be interpreted by programmers, I'm sure they'll be able to understand what's going on. Agreed. This should never happen, and if it does, the difference between a hex and decimal printout for the erroneous value wouldn't matter. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1750574734 From arapte at openjdk.org Mon Sep 9 16:52:42 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 9 Sep 2024 16:52:42 GMT Subject: RFR: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 Message-ID: Following 2 warnings are observed with the JavaFX build. These warnings need to be addressed for updating to Gradle 9.0 in future. 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation `=>>` This warning gets fixed by the change on line number 2111 in build.gradle 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. Verification: 1. Verify that build completes successfully 2. Above two warnings are not observed in build log. 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. ------------- Commit messages: - fix gradle 90 warnings Changes: https://git.openjdk.org/jfx/pull/1559/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1559&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337328 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1559.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1559/head:pull/1559 PR: https://git.openjdk.org/jfx/pull/1559 From angorya at openjdk.org Mon Sep 9 17:01:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 17:01:27 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v9] In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 12:45:02 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Reject CSS where compound selectors don't consist of simple selectors minor fix suggested (hex). ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2290461915 From angorya at openjdk.org Mon Sep 9 17:01:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 17:01:27 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v9] In-Reply-To: <5omdccwxxQldlWFD4ynZXC1ufhdFwW5ieNF0gOaM1wk=.30d74dd2-3c6a-4b88-87be-9d3e69af2727@github.com> References: <5omdccwxxQldlWFD4ynZXC1ufhdFwW5ieNF0gOaM1wk=.30d74dd2-3c6a-4b88-87be-9d3e69af2727@github.com> Message-ID: On Mon, 9 Sep 2024 16:33:31 GMT, Kevin Rushforth wrote: >> I don't think that would matter much. This error will only ever be interpreted by programmers, I'm sure they'll be able to understand what's going on. > > Agreed. This should never happen, and if it does, the difference between a hex and decimal printout for the erroneous value wouldn't matter. I disagree, especially since the target audience is developers. When this happens and the dev needs to diagnose, hex is better: some things become immediately obvious, and some can be found in the binary viewer which is always in hex. I don't understand why you resist. Will re-approve if you decide to fix it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1750606583 From angorya at openjdk.org Mon Sep 9 17:19:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 17:19:42 GMT Subject: RFR: 8090456: Focus Management Message-ID: Public APIs for focus traversal and the focus traversal policy: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md This work is loosely based on the patch https://cr.openjdk.org/~jgiles/8061673/ ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into 8090456.focus.traversal - whitespace - 8090456: focus traversal Changes: https://git.openjdk.org/jfx/pull/1555/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8090456 Stats: 3618 lines in 57 files changed: 1581 ins; 1543 del; 494 mod Patch: https://git.openjdk.org/jfx/pull/1555.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1555/head:pull/1555 PR: https://git.openjdk.org/jfx/pull/1555 From jhendrikx at openjdk.org Mon Sep 9 19:03:22 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 9 Sep 2024 19:03:22 GMT Subject: RFR: 8339726: Remove pausing code (used for testing) from AbstractPrimaryTimer Message-ID: This PR removes the pausing logic from AbstractPrimaryTimer. The test that is using it wasn't actually testing anything in AbstractPrimaryTimer itself, and no other code needs this pausing code. ------------- Commit messages: - Remove unused code Changes: https://git.openjdk.org/jfx/pull/1558/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1558&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339726 Stats: 135 lines in 4 files changed: 0 ins; 134 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1558.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1558/head:pull/1558 PR: https://git.openjdk.org/jfx/pull/1558 From duke at openjdk.org Mon Sep 9 19:27:19 2024 From: duke at openjdk.org (duke) Date: Mon, 9 Sep 2024 19:27:19 GMT Subject: Withdrawn: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Tue, 4 Apr 2023 15:22:48 GMT, John Hendrikx wrote: > 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... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1081 From angorya at openjdk.org Mon Sep 9 20:06:06 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 20:06:06 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 Message-ID: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Further additions to the MonkeyTester application: - tree/table view column property sheets ? - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? - properties... context menu ? - context menu: table columns, toolbar items ? - control.context menu option - property monitor tool ? - accessibility logging ? - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) - Page -> Snapped Split Panes menu option for the control container This PR simply syncs up with the dev repository https://github.com/andy-goryachev-oracle/MonkeyTest ------------- Commit messages: - whitespace - 8328828: Monkey Tester Application Part 4 Changes: https://git.openjdk.org/jfx/pull/1560/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1560&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328828 Stats: 4341 lines in 85 files changed: 3599 ins; 430 del; 312 mod Patch: https://git.openjdk.org/jfx/pull/1560.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1560/head:pull/1560 PR: https://git.openjdk.org/jfx/pull/1560 From angorya at openjdk.org Mon Sep 9 20:09:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 20:09:09 GMT Subject: RFR: 8339726: Remove pausing code (used for testing) from AbstractPrimaryTimer In-Reply-To: References: Message-ID: <6uFY4HlBBD7k5DW-vGXkjA11Bz8LL-kl3zeCGEkBfiY=.0b35afa2-0e46-41ae-9080-7c1df2b51255@github.com> On Mon, 9 Sep 2024 06:23:02 GMT, John Hendrikx wrote: > This PR removes the pausing logic from AbstractPrimaryTimer. The test that is using it wasn't actually testing anything in AbstractPrimaryTimer itself, and no other code needs this pausing code. nice cleanup! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1558#pullrequestreview-2290851550 From kcr at openjdk.org Mon Sep 9 20:21:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Sep 2024 20:21:14 GMT Subject: RFR: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 16:47:21 GMT, Ambarish Rapte wrote: > Following 2 warnings are observed with the JavaFX build. > These warnings need to be addressed for updating to Gradle 9.0 in future. > > 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation > `=>>` This warning gets fixed by the change on line number 2111 in build.gradle > > 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies > `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. > > Verification: > 1. Verify that build completes successfully > 2. Above two warnings are not observed in build log. > 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. Looking at the GHA logs, the warnings are gone on macOS and Linux, but there is still at least one warning on Windows: 2024-09-09T16:44:02.4582769Z Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. 2024-09-09T16:44:02.4583540Z 2024-09-09T16:44:02.4584686Z You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins. 2024-09-09T16:44:02.4585790Z 2024-09-09T16:44:02.4586846Z For more on this, please refer to https://docs.gradle.org/8.9/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation. 2024-09-09T16:44:02.4588091Z 2024-09-09T16:44:02.4588292Z BUILD SUCCESSFUL in 6m 51s ------------- PR Comment: https://git.openjdk.org/jfx/pull/1559#issuecomment-2339009120 From mstrauss at openjdk.org Mon Sep 9 20:33:09 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 9 Sep 2024 20:33:09 GMT Subject: RFR: 8339726: Remove pausing code (used for testing) from AbstractPrimaryTimer In-Reply-To: References: Message-ID: <_04WQc7VHhSmvhzmYKyhpTBQkXrENuRMa87EPqMfNxM=.5416e597-b160-4e95-abb8-7fe519fda8d4@github.com> On Mon, 9 Sep 2024 06:23:02 GMT, John Hendrikx wrote: > This PR removes the pausing logic from AbstractPrimaryTimer. The test that is using it wasn't actually testing anything in AbstractPrimaryTimer itself, and no other code needs this pausing code. Looks good. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1558#pullrequestreview-2290891832 From kcr at openjdk.org Mon Sep 9 20:50:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Sep 2024 20:50:10 GMT Subject: RFR: 8339726: Remove pausing code (used for testing) from AbstractPrimaryTimer In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 06:23:02 GMT, John Hendrikx wrote: > This PR removes the pausing logic from AbstractPrimaryTimer. The test that is using it wasn't actually testing anything in AbstractPrimaryTimer itself, and no other code needs this pausing code. Good cleanup. Without digging a bit more, I'm not sure why these were originally added, but they are clearly useless now. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1558#pullrequestreview-2290920063 From angorya at openjdk.org Mon Sep 9 20:50:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 20:50:10 GMT Subject: RFR: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 16:47:21 GMT, Ambarish Rapte wrote: > Following 2 warnings are observed with the JavaFX build. > These warnings need to be addressed for updating to Gradle 9.0 in future. > > 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation > `=>>` This warning gets fixed by the change on line number 2111 in build.gradle > > 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies > `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. > > Verification: > 1. Verify that build completes successfully > 2. Above two warnings are not observed in build log. > 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. gradle 8.5 on macOS: no warning (this of a historical interest) gradle 8.10 on macOS: no warning ------------- PR Comment: https://git.openjdk.org/jfx/pull/1559#issuecomment-2339059495 From kcr at openjdk.org Mon Sep 9 21:27:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Sep 2024 21:27:09 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 In-Reply-To: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: On Mon, 9 Sep 2024 19:36:29 GMT, Andy Goryachev wrote: > Further additions to the MonkeyTester application: > > - tree/table view column property sheets ? > - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? > - properties... context menu ? > - context menu: table columns, toolbar items ? > - control.context menu option > - property monitor tool ? > - accessibility logging ? > > - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) > - Page -> Snapped Split Panes menu option for the control container > > This PR simply syncs up with the dev repository > https://github.com/andy-goryachev-oracle/MonkeyTest I did an initial test run, and will do more later. One quick thing I noticed is that it looks like the prefs file consumed by the version of `MonkeyTester` in this PR is not compatible with prefs file produced by the version in `jfx:master`. Since saving and loading prefs is enabled by default, this causes some interesting behavior when switching between an older and newer `MonkeyTester`. Try the following: 1. Remove `$HOME/.MonkeyTester` 2. Launch the current `MonkeyTester` from `jfx:master` 3. Navigate to a few demos, such as `AreaChart`, `BarChart`, `ChoiceBox`, etc. 4. Quit 5. Launch the `MonkeyTester` from this PR BUG: the background of the demos previously navigated to is now a linear gradient. If you remove `$HOME/.MonkeyTester` between steps 4 and 5, the bug doesn't appear. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1560#issuecomment-2339117261 From angorya at openjdk.org Mon Sep 9 21:36:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Sep 2024 21:36:09 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 In-Reply-To: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: <9Gbw3H8VBtOXhEiVvM1g1kPs9WZstwyKNAlBsEufvRk=.33828a69-5c07-46cd-8a43-030a2f3a2dbb@github.com> On Mon, 9 Sep 2024 19:36:29 GMT, Andy Goryachev wrote: > Further additions to the MonkeyTester application: > > - tree/table view column property sheets ? > - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? > - properties... context menu ? > - context menu: table columns, toolbar items ? > - control.context menu option > - property monitor tool ? > - accessibility logging ? > > - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) > - Page -> Snapped Split Panes menu option for the control container > > This PR simply syncs up with the dev repository > https://github.com/andy-goryachev-oracle/MonkeyTest yes, this is expected. the preferences simply remembers the index rather than anything else. a more intelligent option would be to remember a toString or a hash(toString) of a choice. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1560#issuecomment-2339193545 From kneester77 at gmail.com Tue Sep 10 01:22:32 2024 From: kneester77 at gmail.com (Knee Snap) Date: Mon, 9 Sep 2024 18:22:32 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: @Nir Lisker Do you mind taking a look, and maybe helping answer some of my questions? I'm just not getting any replies, so I'm somewhat confused. ALSO, unrelated, I'm hoping to pick up the PR you dropped before: https://github.com/openjdk/jfx/pull/1281 What would be the process for me taking over your PR? I don't have access to the original RFR email thread or feature proposal as I only recently joined the mailing list. Thanks! On Fri, Sep 6, 2024 at 4:32?PM Knee Snap wrote: > Hi all, while waiting on Kevin to review the feature proposal (if I > understand the process correctly), I have created a draft PR if anyone > wants to have a look. It's not clear to me if we should be discussing > implementation yet, the guide seems to contradict itself at points. But I > think since we seem to have no further design discussion points we're okay > to talk about implementation? > > Draft PR: https://github.com/openjdk/jfx/pull/1557 > > > On Thu, Sep 5, 2024 at 9:08?PM Knee Snap wrote: > >> Thanks everyone who has commented and given feedback. >> >> With no further discussion points brought up, I'd like to move this >> proposal along for review, and hopefully CSR creation. >> >> Is there anything I need to do besides say I'm ready to move forward? @Kevin >> Rushforth >> >> >> >> On Wed, Sep 4, 2024, 12:24?PM Knee Snap wrote: >> >>> I don't know what gamma refers to in the context of vertex colors, sorry. >>> >>> It's not using the gamma color space if that's the question (but neither >>> is the rest of JavaFX 3D). >>> >>> If gamma is meant as opacity, then setting the alpha color value will >>> control opacity. >>> >>> >>> >>> >>> >>> On Wed, Sep 4, 2024, 7:44?AM Andy Goryachev >>> wrote: >>> >>>> I am not a 3D expert; one question: how is the gamma value set for >>>> color interpolation? >>>> >>>> >>>> >>>> Thanks! >>>> >>>> -andy >>>> >>>> >>>> >>>> *From: *openjfx-dev on behalf of Knee >>>> Snap >>>> *Date: *Tuesday, September 3, 2024 at 23:53 >>>> *To: *openjfx-dev at openjdk.org >>>> *Subject: *[Feature Proposal]: TriangleMesh - Vertex Color Support >>>> >>>> Hello all, >>>> >>>> >>>> >>>> This is a continuation of a previous email thread: "[Feature Proposal] >>>> Vertex Colors on TriangleMesh". >>>> >>>> I'm creating a new email thread because after discussion I've put >>>> together a feature proposal, and it serves largely as a summary of the >>>> previous email thread. (Better organized as a feature proposal) >>>> >>>> >>>> >>>> *Feature Proposal:* >>>> https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md >>>> >>>> I had previously discussed a draft PR, but considering how simple the >>>> proposed public API additions are to discuss, I don't think it's actually >>>> that helpful. >>>> >>>> >>>> >>>> *What's next?* >>>> >>>> I'm currently happy with the design and seeing as it's been discussed >>>> already, I could probably ask Kevin for a review. But, I'd like to give >>>> another opportunity for design discussion before doing so, just in-case >>>> there are any further considerations brought up. >>>> >>>> So, I open up the floor again. Does anyone have any thoughts on this >>>> proposal? Concerns? Questions? Suggestions? Constructive criticism? I >>>> eagerly await the feedback. >>>> >>>> >>>> >>>> After API discussion concludes, I plan to pass it off to Kevin for >>>> review/approval, and if it is approved, the subsequent CSR creation. >>>> >>>> >>>> >>>> Thanks! >>>> >>>> >>>> >>>> >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Sep 10 08:13:44 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 10 Sep 2024 08:13:44 GMT Subject: RFR: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 [v2] In-Reply-To: References: Message-ID: > Following 2 warnings are observed with the JavaFX build. > These warnings need to be addressed for updating to Gradle 9.0 in future. > > 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation > `=>>` This warning gets fixed by the change on line number 2111 in build.gradle > > 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies > `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. > > Verification: > 1. Verify that build completes successfully > 2. Above two warnings are not observed in build log. > 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: fix for windows warning ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1559/files - new: https://git.openjdk.org/jfx/pull/1559/files/a8ab0809..3c8cbc85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1559&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1559&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1559.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1559/head:pull/1559 PR: https://git.openjdk.org/jfx/pull/1559 From arapte at openjdk.org Tue Sep 10 08:52:15 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 10 Sep 2024 08:52:15 GMT Subject: RFR: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 08:13:44 GMT, Ambarish Rapte wrote: >> Following 2 warnings are observed with the JavaFX build. >> These warnings need to be addressed for updating to Gradle 9.0 in future. >> >> 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation >> `=>>` This warning gets fixed by the change on line number 2111 in build.gradle >> >> 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies >> `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. >> >> Verification: >> 1. Verify that build completes successfully >> 2. Above two warnings are not observed in build log. >> 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > fix for windows warning Updated the PR with fix for windows warning: [commit](https://github.com/openjdk/jfx/pull/1559/commits/3c8cbc85ea8666574c43e3d6cb932b5ef32ffc1a) Warnings are : - Build file 'C:\ade\jfx\rt\build.gradle': line 4729 The CopyProcessingSpec.setDirMode(Integer) method has been deprecated. This is scheduled to be removed in Gradle 9.0. Please use the dirPermissions(Action) method instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#unix_file_permissions_deprecated - Build file 'C:\ade\jfx\rt\build.gradle': line 4730 The CopyProcessingSpec.setFileMode(Integer) method has been deprecated. This is scheduled to be removed in Gradle 9.0. Please use the filePermissions(Action) method instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#unix_file_permissions_deprecated [CopyProcessingSpec.setDirMode(Integer)](https://docs.gradle.org/8.9/javadoc/org/gradle/api/file/CopyProcessingSpec.html#setDirMode(java.lang.Integer)) and [CopyProcessingSpec.setFileMode(Integer)](https://docs.gradle.org/8.9/javadoc/org/gradle/api/file/CopyProcessingSpec.html#setFileMode(java.lang.Integer)) are both deprecated and should be replaced with [dirPermissions(Action)](https://docs.gradle.org/8.9/javadoc/org/gradle/api/file/CopyProcessingSpec.html#dirPermissions(org.gradle.api.Action)) & [filePermissions(Action)](https://docs.gradle.org/8.9/javadoc/org/gradle/api/file/CopyProcessingSpec.html#filePermissions(org.gradle.api.Action)) respectively. Using [unix](https://docs.gradle.org/8.9/javadoc/org/gradle/api/file/ConfigurableFilePermissions.html#unix(int)) method to achieve this seems like a good way. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1559#issuecomment-2340053410 From craigraw at gmail.com Tue Sep 10 09:21:43 2024 From: craigraw at gmail.com (Craig Raw) Date: Tue, 10 Sep 2024 11:21:43 +0200 Subject: [XWayland] Windows show in rendering order Message-ID: I have noticed a regression in JavaFX 22 (that was not present in JavaFX 18) on XWayland. For JavaFX apps running on XWayland, Window.show() returns almost immediately, before the window has been rendered onscreen. This has the effect that if multiple windows are shown consecutively, the z order of these windows is determined by the complexity of rendering, not by the order in which show() was called on each. A practical example of this is showing the primary stage, followed by a dialog during application startup. The dialog, being simpler, will appear under the primary stage (despite it being modal, and owned by the primary stage) as it renders quicker. The application in this case appears unresponsive, requiring input on the hidden modal dialog. There appears to be no way to programmatically determine whether a window has been rendered or not, so I'm not aware of any workarounds to this issue, apart from introducing a long fixed delay between calling show() methods and hoping it is long enough :( Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Tue Sep 10 10:37:53 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 10 Sep 2024 07:37:53 -0300 Subject: [XWayland] Windows show in rendering order In-Reply-To: References: Message-ID: Hi Craig, Could you provide a reproducible example? You are describing default wayland behaviour, which is to only show the surface on screen when it has a buffer. One solution might be to show an initial background on the window. I don't discard the possibility of a bug, so the reproducible example would help. -- Thiago. Em ter., 10 de set. de 2024 ?s 06:22, Craig Raw escreveu: > I have noticed a regression in JavaFX 22 (that was not present in JavaFX > 18) on XWayland. > > For JavaFX apps running on XWayland, Window.show() returns almost > immediately, before the window has been rendered onscreen. This has the > effect that if multiple windows are shown consecutively, the z order of > these windows is determined by the complexity of rendering, not by the > order in which show() was called on each. A practical example of this is > showing the primary stage, followed by a dialog during application startup. > The dialog, being simpler, will appear under the primary stage (despite it > being modal, and owned by the primary stage) as it renders quicker. The > application in this case appears unresponsive, requiring input on the > hidden modal dialog. > > There appears to be no way to programmatically determine whether a window > has been rendered or not, so I'm not aware of any workarounds to this > issue, apart from introducing a long fixed delay between calling show() > methods and hoping it is long enough :( > > Craig > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schernyshev at openjdk.org Tue Sep 10 12:38:48 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 10 Sep 2024 12:38:48 GMT Subject: [jfx21u] RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined Message-ID: Hi all, Please review the clean backport of the commit [ca04c87d](https://github.com/openjdk/jfx/commit/ca04c87d307c36591162af8cd6298ede17812834) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 21. Thanks! ------------- Commit messages: - Backport ca04c87d307c36591162af8cd6298ede17812834 Changes: https://git.openjdk.org/jfx21u/pull/69/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=69&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334713 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/69.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/69/head:pull/69 PR: https://git.openjdk.org/jfx21u/pull/69 From schernyshev at openjdk.org Tue Sep 10 12:41:54 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 10 Sep 2024 12:41:54 GMT Subject: [jfx17u] RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined Message-ID: <3LbnBVgzQvNMA1ACcwjal8HrhcbcHpeWkm-80PZqOp0=.a86131a1-f5c5-4cf9-af9c-c7a15d66e695@github.com> Hi all, Please review the clean backport of the commit [ca04c87d](https://github.com/openjdk/jfx/commit/ca04c87d307c36591162af8cd6298ede17812834) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. Thanks! ------------- Commit messages: - Backport ca04c87d307c36591162af8cd6298ede17812834 Changes: https://git.openjdk.org/jfx17u/pull/199/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=199&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334713 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/199.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/199/head:pull/199 PR: https://git.openjdk.org/jfx17u/pull/199 From schernyshev at openjdk.org Tue Sep 10 12:43:58 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 10 Sep 2024 12:43:58 GMT Subject: [jfx21u] RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update Message-ID: Hi all, Please review a clean backport of [6a586b66](https://github.com/openjdk/jfx/commit/6a586b662592be3eb81670f0c5ce48061c2fc07c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 21. Thanks! ------------- Commit messages: - Backport 6a586b662592be3eb81670f0c5ce48061c2fc07c Changes: https://git.openjdk.org/jfx21u/pull/70/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=70&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331765 Stats: 526 lines in 16 files changed: 474 ins; 31 del; 21 mod Patch: https://git.openjdk.org/jfx21u/pull/70.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/70/head:pull/70 PR: https://git.openjdk.org/jfx21u/pull/70 From schernyshev at openjdk.org Tue Sep 10 12:46:51 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 10 Sep 2024 12:46:51 GMT Subject: [jfx17u] RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update Message-ID: <8aX8XQg3HYNv92H2dJ8lgXAo1OLGPKwUzG4tLD3WjUg=.3f7dc9d0-55b4-4f3d-93fa-9d84de593d0a@github.com> Hi all, Please review a clean backport of [6a586b66](https://github.com/openjdk/jfx/commit/6a586b662592be3eb81670f0c5ce48061c2fc07c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. Thanks! ------------- Commit messages: - Backport 6a586b662592be3eb81670f0c5ce48061c2fc07c Changes: https://git.openjdk.org/jfx17u/pull/200/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=200&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331765 Stats: 526 lines in 16 files changed: 474 ins; 31 del; 21 mod Patch: https://git.openjdk.org/jfx17u/pull/200.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/200/head:pull/200 PR: https://git.openjdk.org/jfx17u/pull/200 From schernyshev at openjdk.org Tue Sep 10 12:59:28 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 10 Sep 2024 12:59:28 GMT Subject: [jfx17u] RFR: 8282359: Intermittent WebKit build failure on Windows: C1090: PDB API call failed, error code 23 Message-ID: Hi all, Please review a clean backport of [a264435d](https://github.com/openjdk/jfx/commit/a264435dccba6ec386548f76f1ace095d943f4ca) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by @HimaBinduMeda on 4 Apr 2023 and was reviewed by @kevinrushforth and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. Thanks! ------------- Commit messages: - Backport a264435dccba6ec386548f76f1ace095d943f4ca Changes: https://git.openjdk.org/jfx17u/pull/201/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=201&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282359 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx17u/pull/201.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/201/head:pull/201 PR: https://git.openjdk.org/jfx17u/pull/201 From schernyshev at openjdk.org Tue Sep 10 13:43:22 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 10 Sep 2024 13:43:22 GMT Subject: [jfx17u] RFR: 8318984: Update to Xcode 14.3.1 on macOS Message-ID: Hi all, Please review a clean backport of [d24e96a6](https://github.com/openjdk/jfx/commit/d24e96a66f1908b5a1a1a7d48ee938ba1c782e6c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The fix being backported was authored by @kevinrushforth on 14 Nov 2023 and was reviewed by @arapte and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. Thanks! ------------- Commit messages: - Backport d24e96a66f1908b5a1a1a7d48ee938ba1c782e6c Changes: https://git.openjdk.org/jfx17u/pull/202/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318984 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx17u/pull/202.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/202/head:pull/202 PR: https://git.openjdk.org/jfx17u/pull/202 From craigraw at gmail.com Tue Sep 10 14:22:38 2024 From: craigraw at gmail.com (Craig Raw) Date: Tue, 10 Sep 2024 16:22:38 +0200 Subject: [XWayland] Windows show in rendering order In-Reply-To: References: Message-ID: Hi Thiago, Here is a reproducible example: https://github.com/craigraw/waylandtester After further investigation, I have found that the following two conditions need to be true for the issue to occur: 1. The dialog is owned by the primary stage (with initOwner) 2. The dialog is sufficiently simple in layout to render quickly I've added a README on configuring the example accordingly. Craig On Tue, Sep 10, 2024 at 12:38?PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Hi Craig, > > Could you provide a reproducible example? > > You are describing default wayland behaviour, which is to only show the > surface on screen when it has a buffer. > > One solution might be to show an initial background on the window. > > I don't discard the possibility of a bug, so the reproducible example > would help. > > -- Thiago. > > > > Em ter., 10 de set. de 2024 ?s 06:22, Craig Raw > escreveu: > >> I have noticed a regression in JavaFX 22 (that was not present in JavaFX >> 18) on XWayland. >> >> For JavaFX apps running on XWayland, Window.show() returns almost >> immediately, before the window has been rendered onscreen. This has the >> effect that if multiple windows are shown consecutively, the z order of >> these windows is determined by the complexity of rendering, not by the >> order in which show() was called on each. A practical example of this is >> showing the primary stage, followed by a dialog during application startup. >> The dialog, being simpler, will appear under the primary stage (despite it >> being modal, and owned by the primary stage) as it renders quicker. The >> application in this case appears unresponsive, requiring input on the >> hidden modal dialog. >> >> There appears to be no way to programmatically determine whether a window >> has been rendered or not, so I'm not aware of any workarounds to this >> issue, apart from introducing a long fixed delay between calling show() >> methods and hoping it is long enough :( >> >> Craig >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Sep 10 15:09:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Sep 2024 15:09:22 GMT Subject: [jfx23u] RFR: 8339848: Change JavaFX release version to 23.0.2 in jfx23u Message-ID: Bump version number to 23.0.2 ------------- Commit messages: - 8339848: Change JavaFX release version to 23.0.2 in jfx23u Changes: https://git.openjdk.org/jfx23u/pull/20/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=20&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339848 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx23u/pull/20.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/20/head:pull/20 PR: https://git.openjdk.org/jfx23u/pull/20 From kcr at openjdk.org Tue Sep 10 15:09:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Sep 2024 15:09:23 GMT Subject: [jfx23u] RFR: 8339848: Change JavaFX release version to 23.0.2 in jfx23u In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 15:01:03 GMT, Kevin Rushforth wrote: > Bump version number to 23.0.2 Reviewer: @johanvos ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/20#issuecomment-2341182782 From kcr at openjdk.org Tue Sep 10 16:11:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Sep 2024 16:11:14 GMT Subject: RFR: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 08:13:44 GMT, Ambarish Rapte wrote: >> Following 2 warnings are observed with the JavaFX build. >> These warnings need to be addressed for updating to Gradle 9.0 in future. >> >> 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation >> `=>>` This warning gets fixed by the change on line number 2111 in build.gradle >> >> 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies >> `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. >> >> Verification: >> 1. Verify that build completes successfully >> 2. Above two warnings are not observed in build log. >> 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > fix for windows warning Looks good now. I get no warnings on Windows now. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1559#pullrequestreview-2292974257 From angorya at openjdk.org Tue Sep 10 16:11:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Sep 2024 16:11:14 GMT Subject: RFR: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 08:13:44 GMT, Ambarish Rapte wrote: >> Following 2 warnings are observed with the JavaFX build. >> These warnings need to be addressed for updating to Gradle 9.0 in future. >> >> 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation >> `=>>` This warning gets fixed by the change on line number 2111 in build.gradle >> >> 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies >> `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. >> >> Verification: >> 1. Verify that build completes successfully >> 2. Above two warnings are not observed in build log. >> 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > fix for windows warning was this PR tested on linux? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1559#issuecomment-2341375833 From kcr at openjdk.org Tue Sep 10 16:16:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Sep 2024 16:16:17 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 In-Reply-To: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: On Mon, 9 Sep 2024 19:36:29 GMT, Andy Goryachev wrote: > Further additions to the MonkeyTester application: > > - tree/table view column property sheets ? > - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? > - properties... context menu ? > - context menu: table columns, toolbar items ? > - control.context menu option > - property monitor tool ? > - accessibility logging ? > > - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) > - Page -> Snapped Split Panes menu option for the control container > > This PR simply syncs up with the dev repository > https://github.com/andy-goryachev-oracle/MonkeyTest Another possibility would be to have a version number associated with the prefs file, bump it when you make an incompatible change, and ignore the prefs on load if incompatible. Just a suggestion. Reviewers: @lukostyra @arapte Btw, I'll still play around with it and add comments with any questions or observations, but I'll ask Ambarish and Lukasz to be the reviewers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1560#issuecomment-2341390288 PR Comment: https://git.openjdk.org/jfx/pull/1560#issuecomment-2341393482 From jvos at openjdk.org Tue Sep 10 17:03:11 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 10 Sep 2024 17:03:11 GMT Subject: [jfx23u] RFR: 8339848: Change JavaFX release version to 23.0.2 in jfx23u In-Reply-To: References: Message-ID: <6-Beg98EmF1WKSBFCZiBWUuZaBzjSr50J1XbaVG7-YQ=.c346af1a-83bf-4684-8c13-83583171c5b8@github.com> On Tue, 10 Sep 2024 15:01:03 GMT, Kevin Rushforth wrote: > Bump version number to 23.0.2 Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx23u/pull/20#pullrequestreview-2293139860 From kcr at openjdk.org Tue Sep 10 17:09:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Sep 2024 17:09:15 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 19:09:15 GMT, Andy Goryachev wrote: > Public APIs for focus traversal and the focus traversal policy: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > This work is loosely based on the patch > https://cr.openjdk.org/~jgiles/8061673/ I did a first pass of the public API and left a few comments. I'll need a second pass and a more careful look at the docs. modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 850: > 848: /** > 849: * The {@link TraversalPolicy} to be used by this Parent to provide assistance to the > 850: * JavaFX focus traversal subsystem. What assistance does this policy provide? When is it used? modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 853: > 851: * > 852: * @defaultValue null > 853: * @since 999 TODO Don't forget to update this (probably to jfx24, since there is plenty of time to get this in). modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 31: > 29: import java.io.File; > 30: import java.lang.ref.WeakReference; > 31: import java.security.AccessControlContext; Meta-comment: This is the sort of bulk reordering that _really_ makes me want a prescribed ordering that we all use. modules/javafx.graphics/src/main/java/javafx/scene/traversal/FocusTraversal.java line 34: > 32: > 33: /** > 34: * Provides the mechanism for focus traversal in the JavaFX application. I'd like to see additional documentation here describing focus traversal. modules/javafx.graphics/src/main/java/javafx/scene/traversal/FocusTraversal.java line 40: > 38: public final class FocusTraversal { > 39: /** > 40: * Traverses focus to the adjacent node as specified by the direction. What does it do if the `node` to traverse from is not the currently focused node? How does traversal differ if the method is `KEY` vs `DEFAULT`? modules/javafx.graphics/src/main/java/javafx/scene/traversal/FocusTraversal.java line 63: > 61: > 62: /** > 63: * Traverse focus downward as a response to pressing a key. Is this a convenience method like the ones that follow? If so, add docs (and if not, why not?). modules/javafx.graphics/src/main/java/javafx/scene/traversal/FocusTraversal.java line 65: > 63: * Traverse focus downward as a response to pressing a key. > 64: * > 65: * @param node the origin node What is the "origin" node? Is it is the same as the "node to traverse focus from" in the `traverse` method? If so, use the same language. If not, clearly define the difference. modules/javafx.graphics/src/main/java/javafx/scene/traversal/TraversalDirection.java line 35: > 33: */ > 34: public enum TraversalDirection { > 35: /** Moving focus downward. */ Suggestion: `Moving` --> `Moves` modules/javafx.graphics/src/main/java/javafx/scene/traversal/TraversalMethod.java line 26: > 24: */ > 25: > 26: package javafx.scene.traversal; You need an `@since` javadoc tag on this class. modules/javafx.graphics/src/main/java/javafx/scene/traversal/TraversalPolicy.java line 51: > 49: * @since 999 TODO > 50: */ > 51: public abstract class TraversalPolicy { Who subclasses this? And for what purpose? This should be documented in the class docs. modules/javafx.graphics/src/main/java/javafx/scene/traversal/TraversalPolicy.java line 53: > 51: public abstract class TraversalPolicy { > 52: /** > 53: * Traverse from owner, in direction dir. Is the "owner" the "focus owner"? What is its relationship to the "node" parameter? modules/javafx.graphics/src/main/java/javafx/scene/traversal/TraversalPolicy.java line 63: > 61: *

      > 62: *
    1. Find the nearest parent of the "owner" that is handled by this TraversalPolicy (i.e. it's a direct child of the root). > 63: *
    2. select the next node within this direct child using the context.selectInSubtree() and return it I'm going to need a second pass to understand what this does, but one thing that jumps out at me: what is "context" ? and what is the "selectInSubtree" method? I see no such method in the public API, so this description is not comprehensible (nor suitable for public documentation). modules/javafx.graphics/src/main/java/javafx/scene/traversal/TraversalPolicy.java line 96: > 94: * The constructor. > 95: */ > 96: public TraversalPolicy() { Abstract classes should have a `protected` not public constructor. And the docs should say "Constructor for subclasses to call." modules/javafx.graphics/src/main/java/javafx/scene/traversal/package-info.java line 28: > 26: /** > 27: *

      Provides the set of classes for focus traversal.

      > 28: */ This should have an `@since ` tag. Minor: I don't think the `

      ` HTML tag is needed. ------------- PR Review: https://git.openjdk.org/jfx/pull/1555#pullrequestreview-2293014279 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752279424 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752281034 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752283448 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752285689 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752288335 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752292570 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752292924 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752297334 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752302045 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752306901 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752308905 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752320230 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752305206 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1752337828 From kcr at openjdk.org Tue Sep 10 17:30:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Sep 2024 17:30:15 GMT Subject: RFR: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 08:13:44 GMT, Ambarish Rapte wrote: >> Following 2 warnings are observed with the JavaFX build. >> These warnings need to be addressed for updating to Gradle 9.0 in future. >> >> 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation >> `=>>` This warning gets fixed by the change on line number 2111 in build.gradle >> >> 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies >> `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. >> >> Verification: >> 1. Verify that build completes successfully >> 2. Above two warnings are not observed in build log. >> 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > fix for windows warning Yes. Both via GHA and via our CI system. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1559#issuecomment-2341552739 From angorya at openjdk.org Tue Sep 10 17:50:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Sep 2024 17:50:10 GMT Subject: RFR: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 08:13:44 GMT, Ambarish Rapte wrote: >> Following 2 warnings are observed with the JavaFX build. >> These warnings need to be addressed for updating to Gradle 9.0 in future. >> >> 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation >> `=>>` This warning gets fixed by the change on line number 2111 in build.gradle >> >> 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies >> `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. >> >> Verification: >> 1. Verify that build completes successfully >> 2. Above two warnings are not observed in build log. >> 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > fix for windows warning Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1559#pullrequestreview-2293257764 From kcr at openjdk.org Tue Sep 10 18:07:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Sep 2024 18:07:12 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v8] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 16:24:10 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision: > > - moved to apps, review comments > - bsd license for sample code It looks like you copied, rather than moved, `RichTextAreaDemo` from `tests/manual` to `apps/samples`. The former should be deleted. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2341643238 From kcr at openjdk.org Tue Sep 10 20:08:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Sep 2024 20:08:25 GMT Subject: [jfx23u] Integrated: 8339848: Change JavaFX release version to 23.0.2 in jfx23u In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 15:01:03 GMT, Kevin Rushforth wrote: > Bump version number to 23.0.2 This pull request has now been integrated. Changeset: 31e7709c Author: Kevin Rushforth URL: https://git.openjdk.org/jfx23u/commit/31e7709c39546cc928d899b07c65878b37e28e76 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8339848: Change JavaFX release version to 23.0.2 in jfx23u Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx23u/pull/20 From mhanl at openjdk.org Tue Sep 10 20:09:11 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 10 Sep 2024 20:09:11 GMT Subject: RFR: 8339726: Remove pausing code (used for testing) from AbstractPrimaryTimer In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 06:23:02 GMT, John Hendrikx wrote: > This PR removes the pausing logic from AbstractPrimaryTimer. The test that is using it wasn't actually testing anything in AbstractPrimaryTimer itself, and no other code needs this pausing code. Looks good to me too and always good to clean up things that are especially only used for testing. The git history does not reveal why this was added, but it probably doesn't matter. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1558#pullrequestreview-2293670863 From angorya at openjdk.org Tue Sep 10 20:17:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Sep 2024 20:17:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v9] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: removed duplicate files ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/1d511bf3..9a984533 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=07-08 Stats: 12835 lines in 76 files changed: 0 ins; 12835 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Tue Sep 10 20:20:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Sep 2024 20:20:13 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v8] In-Reply-To: References: Message-ID: <1-9XLe4lrgOpJuVoOAyWczi8vZHfIgX_ASCXJM0g7zk=.bd0ed6c0-487b-4363-b241-a8af99e9ec3d@github.com> On Tue, 10 Sep 2024 18:04:27 GMT, Kevin Rushforth wrote: > It looks like you copied, rather than moved yep, thanks for noticing! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2341934644 From mhanl at openjdk.org Tue Sep 10 20:22:43 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 10 Sep 2024 20:22:43 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v4] In-Reply-To: References: Message-ID: <-MDyv6QoViXBw0Qi6XjKyaa9eNoxLP5-ZyvRcQ8NEiU=.0b7b1231-0a68-456f-b190-b8b70601d247@github.com> > Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. > > This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. > Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. > > So the following code is effectively doing the same: > > Old: > > BaseBounds newClip = clipNode.getShape().getBounds(); > if (!clipNode.getTransform().isIdentity()) { > newClip = clipNode.getTransform().transform(newClip, newClip); > } > final BaseTransform curXform = g.getTransformNoClone(); > final Rectangle curClip = g.getClipRectNoClone(); > newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning > newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > Rectangle clipRect = new Rectangle(newClip) > > > New: > > BaseTransform curXform = g.getTransformNoClone(); > BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); > Rectangle clipRect = new Rectangle(clipBounds); > clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > > > As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. > I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. > > I checked several scenarios and code and could not find any regressions. > Still, since this is change affects all nodes with rectangular clips, we should be careful. > Performance wise I could not spot any difference, I do not expect any difference. > **So I would like to have at least 2 reviewers.** > Note that I will do more testing as well soon on all JavaFX applications I have access to. > > --- > > 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 with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java - Improve test - 8218745: TableView: visual glitch at borders on horizontal scrolling ------------- Changes: https://git.openjdk.org/jfx/pull/1462/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1462&range=03 Stats: 243 lines in 11 files changed: 166 ins; 56 del; 21 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 angorya at openjdk.org Tue Sep 10 20:28:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Sep 2024 20:28:08 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 In-Reply-To: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: <_NQDO284yUqYJ3ccMyAdpMu8knyKUhM_KUohRRVw6Qo=.77992500-c963-4236-a52c-bb3d74aea6dd@github.com> On Mon, 9 Sep 2024 19:36:29 GMT, Andy Goryachev wrote: > Further additions to the MonkeyTester application: > > - tree/table view column property sheets ? > - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? > - properties... context menu ? > - context menu: table columns, toolbar items ? > - control.context menu option > - property monitor tool ? > - accessibility logging ? > > - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) > - Page -> Snapped Split Panes menu option for the control container > > This PR simply syncs up with the dev repository > https://github.com/andy-goryachev-oracle/MonkeyTest thank you for the suggestions! The workaround for now is to nuke the preferences file (I know, bad), or simply selecting the right choice in the UI. The issue _could_ be solved by remembering `toString` (or `hash(toString)` value for privacy-conscious implementation) but there is no guarantee that we'll get an Object.toString() value instead (i.e. SomeClass at 1234). It's even worse when the application is obfuscated - there will be no guarantee that the class names remain the same from build to build. This is surprisingly complicated issue, I have no solution yet (see https://github.com/andy-goryachev/AppFramework from which I lifted the code with the permission of, erm, author). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1560#issuecomment-2341948449 From jhendrikx at openjdk.org Tue Sep 10 23:30:10 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 10 Sep 2024 23:30:10 GMT Subject: Integrated: 8339726: Remove pausing code (used for testing) from AbstractPrimaryTimer In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 06:23:02 GMT, John Hendrikx wrote: > This PR removes the pausing logic from AbstractPrimaryTimer. The test that is using it wasn't actually testing anything in AbstractPrimaryTimer itself, and no other code needs this pausing code. This pull request has now been integrated. Changeset: 66401aed Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/66401aed01206258431ad923d28b1593bf27acb8 Stats: 135 lines in 4 files changed: 0 ins; 134 del; 1 mod 8339726: Remove pausing code (used for testing) from AbstractPrimaryTimer Reviewed-by: angorya, mstrauss, kcr, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1558 From jhendrikx at openjdk.org Tue Sep 10 23:32:13 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 10 Sep 2024 23:32:13 GMT Subject: Integrated: 8323706: Remove SimpleSelector and CompoundSelector classes In-Reply-To: References: Message-ID: On Sun, 14 Jan 2024 14:54:36 GMT, John Hendrikx wrote: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` This pull request has now been integrated. Changeset: dad80e92 Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/dad80e9284fcde36aa0cac4e6459b6dbfd43ee13 Stats: 1836 lines in 14 files changed: 912 ins; 888 del; 36 mod 8323706: Remove SimpleSelector and CompoundSelector classes Move SimpleSelector and CompoundSelector to internal packages Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1333 From mstrauss at openjdk.org Wed Sep 11 01:08:13 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Sep 2024 01:08:13 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: On Tue, 3 Sep 2024 19:09:15 GMT, Andy Goryachev wrote: > Public APIs for focus traversal and the focus traversal policy: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > This work is loosely based on the patch > https://cr.openjdk.org/~jgiles/8061673/ By its own admission, this proposal basically promotes an internal implementation to public API (albeit with some refactoring). This may or may not be a good idea, so I'd like to take a step back and look at the problem we're trying to solve. Looking at several of the linked JBS issues, a missing feature of JavaFX is the ability to customize the focus traversal logic of a custom control (or a container of nodes in the widest sense of the word). Any proposed solution should support complex scenarios like toolbars with overflow, or [radio groups](https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#radiobutton). I think there are two distinct modes of focus traversal: logical ("tabbing") and directional (arrow keys). Both modes are independent axes of the problem at hand, and should be customizable independently from each other. The current implementation provides a single `Algorithm` (or `TraversalPolicy` after the refactoring) for both traversal modes. I've played around with the code for a while, and while in theory I can provide my own `TraversalPolicy`, it can be quite a lot of code and it's not as easy as it could be. Additionally, it is hard to customize the traversal policies of the substructure of skinnable controls. I question whether we need custom traversal policies at all, as the ways in which focus can move from one node to the next are quite limited: 1. **Permeable edges**: The next node in a container is selected until an edge is reached, then the input focus leaves the container. 2. **Confined to container**: The next node in a container is selected until the end of the container is reached; then the input focus doesn't move on. 3. **Cyclic in container**: Like confined, but at the end of the container, the input focus wraps around to the first element. 4. **Single focused node in container**: When the input focus enters a container, it moves to the node that was most recently selected (or to the first node in the container if none of the nodes was selected before); after that the input focus leaves the container. Having two traversal toggles (logical and directional), each with four possible modes, already solves most of the problem. The advantage of this over a custom policy implementation is that these properties can be modelled with an enumeration and easily be set by control and application developers, and they can also be set via CSS. This allows developers to customize the focus traversal behavior of existing skinnable controls, as the substructure of a skin is accessible via CSS. The "single focused node in container" mode is required for scenarios like radio groups, when the developers wants to return to the point of previous focus when tabbing into the group a second time. This requires another API that allows a focus container to indicate its entry point, which is the initial element that is selected when the input focus moves into the container. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2342418714 From arapte at openjdk.org Wed Sep 11 03:57:12 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 11 Sep 2024 03:57:12 GMT Subject: Integrated: 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 16:47:21 GMT, Ambarish Rapte wrote: > Following 2 warnings are observed with the JavaFX build. > These warnings need to be addressed for updating to Gradle 9.0 in future. > > 1. The org.gradle.api.plugins.JavaPluginConvention type has been deprecated. This is scheduled to be removed in Gradle 9.0. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#java_convention_deprecation > `=>>` This warning gets fixed by the change on line number 2111 in build.gradle > > 2. The automatic loading of test framework implementation dependencies has been deprecated. This is scheduled to be removed in Gradle 9.0. Declare the desired test framework directly on the test suite or explicitly declare the test framework implementation dependencies on the test's runtime classpath. Consult the upgrading guide for further information: https://docs.gradle.org/8.9/userguide/upgrading_version_8.html#test_framework_implementation_dependencies > `=>>` This warning gets fixed by the change on line number 2128 in build.gradle. It also requires the verification metadata to be updated. > > Verification: > 1. Verify that build completes successfully > 2. Above two warnings are not observed in build log. > 3. This warning message is NOT observed in build log: Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0. This pull request has now been integrated. Changeset: 463fdab5 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/463fdab5cffe88c6f8ce5465795d579d45342fac Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod 8337328: JavaFX build uses deprecated features that will be removed in gradle 9 Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1559 From jvos at openjdk.org Wed Sep 11 06:54:12 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 06:54:12 GMT Subject: [jfx17u] RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: <3LbnBVgzQvNMA1ACcwjal8HrhcbcHpeWkm-80PZqOp0=.a86131a1-f5c5-4cf9-af9c-c7a15d66e695@github.com> References: <3LbnBVgzQvNMA1ACcwjal8HrhcbcHpeWkm-80PZqOp0=.a86131a1-f5c5-4cf9-af9c-c7a15d66e695@github.com> Message-ID: On Tue, 10 Sep 2024 12:36:42 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review the clean backport of the commit [ca04c87d](https://github.com/openjdk/jfx/commit/ca04c87d307c36591162af8cd6298ede17812834) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! Thanks for this PR, much appreciated! I'm in the process of updating the webkit, sqlite and libxml. I believe this (and others) are valid PR's and will approve once I'm confident that they fit in the general update. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/199#issuecomment-2342804139 From jvos at openjdk.org Wed Sep 11 08:31:10 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 08:31:10 GMT Subject: [jfx17u] RFR: 8318984: Update to Xcode 14.3.1 on macOS In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 13:39:11 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [d24e96a6](https://github.com/openjdk/jfx/commit/d24e96a66f1908b5a1a1a7d48ee938ba1c782e6c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The fix being backported was authored by @kevinrushforth on 14 Nov 2023 and was reviewed by @arapte and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! @sercher Can you integrate this (and the other approved PR's)? I have a bunch of backports in the pipeline, but these ones should go first. Thanks! ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/202#issuecomment-2342991891 From duke at openjdk.org Wed Sep 11 09:30:17 2024 From: duke at openjdk.org (duke) Date: Wed, 11 Sep 2024 09:30:17 GMT Subject: [jfx21u] RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 12:39:09 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [6a586b66](https://github.com/openjdk/jfx/commit/6a586b662592be3eb81670f0c5ce48061c2fc07c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 21. > > Thanks! @sercher Your change (at version 07b6ddbce8a154137bbb537b90cf9d8c1a1dc0d0) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/70#issuecomment-2343124887 From duke at openjdk.org Wed Sep 11 09:31:13 2024 From: duke at openjdk.org (duke) Date: Wed, 11 Sep 2024 09:31:13 GMT Subject: [jfx17u] RFR: 8331765: Websocket callbacks are not executed after WebKit 617.1 update In-Reply-To: <8aX8XQg3HYNv92H2dJ8lgXAo1OLGPKwUzG4tLD3WjUg=.3f7dc9d0-55b4-4f3d-93fa-9d84de593d0a@github.com> References: <8aX8XQg3HYNv92H2dJ8lgXAo1OLGPKwUzG4tLD3WjUg=.3f7dc9d0-55b4-4f3d-93fa-9d84de593d0a@github.com> Message-ID: <0QNr3Ot6ScIMAQ5fUCghCeMby_Djmi-rOAd2RD0GGDE=.321ccd06-af43-48fb-be2b-c6943b931567@github.com> On Tue, 10 Sep 2024 12:40:02 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [6a586b66](https://github.com/openjdk/jfx/commit/6a586b662592be3eb81670f0c5ce48061c2fc07c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! @sercher Your change (at version 2ee7f3f91a48b4c8479e30bb24a51d77b87fcc30) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/200#issuecomment-2343126641 From duke at openjdk.org Wed Sep 11 09:31:15 2024 From: duke at openjdk.org (duke) Date: Wed, 11 Sep 2024 09:31:15 GMT Subject: [jfx17u] RFR: 8318984: Update to Xcode 14.3.1 on macOS In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 13:39:11 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [d24e96a6](https://github.com/openjdk/jfx/commit/d24e96a66f1908b5a1a1a7d48ee938ba1c782e6c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The fix being backported was authored by @kevinrushforth on 14 Nov 2023 and was reviewed by @arapte and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! @sercher Your change (at version 3f53b8189f822a804ef0583745c994db6ff833c2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/202#issuecomment-2343126013 From duke at openjdk.org Wed Sep 11 09:31:16 2024 From: duke at openjdk.org (duke) Date: Wed, 11 Sep 2024 09:31:16 GMT Subject: [jfx17u] RFR: 8282359: Intermittent WebKit build failure on Windows: C1090: PDB API call failed, error code 23 In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 12:53:42 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [a264435d](https://github.com/openjdk/jfx/commit/a264435dccba6ec386548f76f1ace095d943f4ca) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @HimaBinduMeda on 4 Apr 2023 and was reviewed by @kevinrushforth and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! @sercher Your change (at version 4e3899a3c4549c59bffbccca7c7a2af5fc1b7b12) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/201#issuecomment-2343126361 From duke at openjdk.org Wed Sep 11 09:31:18 2024 From: duke at openjdk.org (duke) Date: Wed, 11 Sep 2024 09:31:18 GMT Subject: [jfx21u] RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 12:33:35 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review the clean backport of the commit [ca04c87d](https://github.com/openjdk/jfx/commit/ca04c87d307c36591162af8cd6298ede17812834) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 21. > > Thanks! @sercher Your change (at version 8ad27a87a26356968963b4ef4b146c827d395770) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/69#issuecomment-2343125588 From duke at openjdk.org Wed Sep 11 09:31:18 2024 From: duke at openjdk.org (duke) Date: Wed, 11 Sep 2024 09:31:18 GMT Subject: [jfx17u] RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: <3LbnBVgzQvNMA1ACcwjal8HrhcbcHpeWkm-80PZqOp0=.a86131a1-f5c5-4cf9-af9c-c7a15d66e695@github.com> References: <3LbnBVgzQvNMA1ACcwjal8HrhcbcHpeWkm-80PZqOp0=.a86131a1-f5c5-4cf9-af9c-c7a15d66e695@github.com> Message-ID: On Tue, 10 Sep 2024 12:36:42 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review the clean backport of the commit [ca04c87d](https://github.com/openjdk/jfx/commit/ca04c87d307c36591162af8cd6298ede17812834) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! @sercher Your change (at version 2651a0ced7f50104db035cde95ad6a32652cfa70) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/199#issuecomment-2343126868 From schernyshev at openjdk.org Wed Sep 11 09:44:10 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 09:44:10 GMT Subject: [jfx17u] Integrated: 8318984: Update to Xcode 14.3.1 on macOS In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 13:39:11 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [d24e96a6](https://github.com/openjdk/jfx/commit/d24e96a66f1908b5a1a1a7d48ee938ba1c782e6c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The fix being backported was authored by @kevinrushforth on 14 Nov 2023 and was reviewed by @arapte and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! This pull request has now been integrated. Changeset: a429abe5 Author: Sergey Chernyshev Committer: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/a429abe5417aaea149dfad543440866b02bde3d1 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8318984: Update to Xcode 14.3.1 on macOS Backport-of: d24e96a66f1908b5a1a1a7d48ee938ba1c782e6c ------------- PR: https://git.openjdk.org/jfx17u/pull/202 From schernyshev at openjdk.org Wed Sep 11 09:55:17 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 09:55:17 GMT Subject: [jfx17u] Integrated: 8282359: Intermittent WebKit build failure on Windows: C1090: PDB API call failed, error code 23 In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 12:53:42 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [a264435d](https://github.com/openjdk/jfx/commit/a264435dccba6ec386548f76f1ace095d943f4ca) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @HimaBinduMeda on 4 Apr 2023 and was reviewed by @kevinrushforth and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! This pull request has now been integrated. Changeset: 2a168b15 Author: Sergey Chernyshev Committer: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/2a168b15d4436be321de46374818418b555e92d1 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod 8282359: Intermittent WebKit build failure on Windows: C1090: PDB API call failed, error code 23 Backport-of: a264435dccba6ec386548f76f1ace095d943f4ca ------------- PR: https://git.openjdk.org/jfx17u/pull/201 From schernyshev at openjdk.org Wed Sep 11 09:55:18 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 09:55:18 GMT Subject: [jfx17u] Integrated: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: <3LbnBVgzQvNMA1ACcwjal8HrhcbcHpeWkm-80PZqOp0=.a86131a1-f5c5-4cf9-af9c-c7a15d66e695@github.com> References: <3LbnBVgzQvNMA1ACcwjal8HrhcbcHpeWkm-80PZqOp0=.a86131a1-f5c5-4cf9-af9c-c7a15d66e695@github.com> Message-ID: On Tue, 10 Sep 2024 12:36:42 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review the clean backport of the commit [ca04c87d](https://github.com/openjdk/jfx/commit/ca04c87d307c36591162af8cd6298ede17812834) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! This pull request has now been integrated. Changeset: 6753caee Author: Sergey Chernyshev Committer: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/6753caee723073d4c4376054cac56c66ec60cfad Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined Backport-of: ca04c87d307c36591162af8cd6298ede17812834 ------------- PR: https://git.openjdk.org/jfx17u/pull/199 From schernyshev at openjdk.org Wed Sep 11 09:55:18 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 09:55:18 GMT Subject: [jfx21u] Integrated: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 12:33:35 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review the clean backport of the commit [ca04c87d](https://github.com/openjdk/jfx/commit/ca04c87d307c36591162af8cd6298ede17812834) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 21. > > Thanks! This pull request has now been integrated. Changeset: 75e0b69d Author: Sergey Chernyshev Committer: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/75e0b69d7674e5b75704757a66f5cc08806feb2a Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined Backport-of: ca04c87d307c36591162af8cd6298ede17812834 ------------- PR: https://git.openjdk.org/jfx21u/pull/69 From schernyshev at openjdk.org Wed Sep 11 09:55:19 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 09:55:19 GMT Subject: [jfx17u] Integrated: 8331765: Websocket callbacks are not executed after WebKit 617.1 update In-Reply-To: <8aX8XQg3HYNv92H2dJ8lgXAo1OLGPKwUzG4tLD3WjUg=.3f7dc9d0-55b4-4f3d-93fa-9d84de593d0a@github.com> References: <8aX8XQg3HYNv92H2dJ8lgXAo1OLGPKwUzG4tLD3WjUg=.3f7dc9d0-55b4-4f3d-93fa-9d84de593d0a@github.com> Message-ID: On Tue, 10 Sep 2024 12:40:02 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [6a586b66](https://github.com/openjdk/jfx/commit/6a586b662592be3eb81670f0c5ce48061c2fc07c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! This pull request has now been integrated. Changeset: 64fafbf9 Author: Sergey Chernyshev Committer: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/64fafbf9bf560a147abb8a5ef50c42b1f72b6cad Stats: 526 lines in 16 files changed: 474 ins; 31 del; 21 mod 8331765: Websocket callbacks are not executed after WebKit 617.1 update Backport-of: 6a586b662592be3eb81670f0c5ce48061c2fc07c ------------- PR: https://git.openjdk.org/jfx17u/pull/200 From schernyshev at openjdk.org Wed Sep 11 09:55:19 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 09:55:19 GMT Subject: [jfx21u] Integrated: 8331765: Websocket callbacks are not executed after WebKit 617.1 update In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 12:39:09 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [6a586b66](https://github.com/openjdk/jfx/commit/6a586b662592be3eb81670f0c5ce48061c2fc07c) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by @theaoqi on 27 Jun 2024 and was reviewed by @kevinrushforth and @HimaBinduMeda. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 21. > > Thanks! This pull request has now been integrated. Changeset: b39d2764 Author: Sergey Chernyshev Committer: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/b39d276449dbca3ac05f07972a039fb8b96c83a2 Stats: 526 lines in 16 files changed: 474 ins; 31 del; 21 mod 8331765: Websocket callbacks are not executed after WebKit 617.1 update Backport-of: 6a586b662592be3eb81670f0c5ce48061c2fc07c ------------- PR: https://git.openjdk.org/jfx21u/pull/70 From jvos at openjdk.org Wed Sep 11 10:04:20 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 10:04:20 GMT Subject: [jfx21u] RFR: 8328994: Update WebKit to 619.1 Message-ID: Hi all, This pull request contains a backport of commit [34bbf853](https://github.com/openjdk/jfx/commit/34bbf85362fae946c6306eb52a8478aa2ca3ef5f) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Hima Bindu Meda on 16 Jul 2024 and was reviewed by Kevin Rushforth and Joeri Sykora. Thanks! ------------- Commit messages: - Backport 34bbf85362fae946c6306eb52a8478aa2ca3ef5f Changes: https://git.openjdk.org/jfx21u/pull/71/files Webrev: Webrev is not available because diff is too large Issue: https://bugs.openjdk.org/browse/JDK-8328994 Stats: 349763 lines in 7157 files changed: 184133 ins; 107646 del; 57984 mod Patch: https://git.openjdk.org/jfx21u/pull/71.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/71/head:pull/71 PR: https://git.openjdk.org/jfx21u/pull/71 From jvos at openjdk.org Wed Sep 11 10:12:39 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 10:12:39 GMT Subject: [jfx17u] RFR: 8328994: Update WebKit to 619.1 Message-ID: Hi all, This pull request contains a backport of commit 34bbf853 from the openjdk/jfx repository. The commit being backported was authored by Hima Bindu Meda on 16 Jul 2024 and was reviewed by Kevin Rushforth and Joeri Sykora. Thanks! ------------- Commit messages: - Backport 34bbf85362fae946c6306eb52a8478aa2ca3ef5f Changes: https://git.openjdk.org/jfx17u/pull/203/files Webrev: Webrev is not available because diff is too large Issue: https://bugs.openjdk.org/browse/JDK-8328994 Stats: 349763 lines in 7157 files changed: 184133 ins; 107646 del; 57984 mod Patch: https://git.openjdk.org/jfx17u/pull/203.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/203/head:pull/203 PR: https://git.openjdk.org/jfx17u/pull/203 From schernyshev at openjdk.org Wed Sep 11 11:01:33 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 11:01:33 GMT Subject: [jfx17u] RFR: 8319762: Update to Visual Studio 2022 version 17.6.5 on Windows Message-ID: Hi all, Please review a clean backport of [2d4b494e](https://github.com/openjdk/jfx/commit/2d4b494ea9cee1acd0407b9de61f0af9163f5d62) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The fix being backported was authored by @kevinrushforth on 15 Nov 2023 and was reviewed by @tiainen and @arapte. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. Thanks! ------------- Commit messages: - Backport 2d4b494ea9cee1acd0407b9de61f0af9163f5d62 Changes: https://git.openjdk.org/jfx17u/pull/204/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=204&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319762 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx17u/pull/204.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/204/head:pull/204 PR: https://git.openjdk.org/jfx17u/pull/204 From schernyshev at openjdk.org Wed Sep 11 11:30:11 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 11:30:11 GMT Subject: [jfx17u] RFR: 8319762: Update to Visual Studio 2022 version 17.6.5 on Windows In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 10:57:02 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [2d4b494e](https://github.com/openjdk/jfx/commit/2d4b494ea9cee1acd0407b9de61f0af9163f5d62) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The fix being backported was authored by @kevinrushforth on 15 Nov 2023 and was reviewed by @tiainen and @arapte. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! @johanvos can you please approve this, as it's needed for [pr/203](https://github.com/openjdk/jfx17u/pull/203) (as well as JDK-8319996 that depends on this)? ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/204#issuecomment-2343371027 From kcr at openjdk.org Wed Sep 11 12:00:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Sep 2024 12:00:14 GMT Subject: RFR: 8339247: Create release notes for JavaFX 23 [v2] In-Reply-To: References: Message-ID: On Wed, 4 Sep 2024 14:38:00 GMT, Kevin Rushforth wrote: >> This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo). >> >> The following filter was used to produce the list of issues fixed in JavaFX 23: >> >> https://bugs.openjdk.org/issues/?filter=45422 >> >> Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes. >> >> I will wait until closer to the September 17th release date to integrate this. >> >> >> A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split: >> >> ## List of New Features >> >> Issue key|Summary|Subcomponent >> ---------|-------|------------ >> [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls >> [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls >> [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics >> [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics >> [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media >> >> ## List of Other Enhancements >> >> Issue key|Summary|Subcomponent >> ---------|-------|------------ >> [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build >> [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls >> [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics >> [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics >> [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Split enhancements into two groups; use title case for "Issue Key" I plan to integrate this early tomorrow morning (Sep 12th). I will then backport it to the `jfx23` branch (I will _not_ trigger a new build of `jfx23` as a result). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1553#issuecomment-2343467007 From jvos at openjdk.org Wed Sep 11 12:13:17 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 12:13:17 GMT Subject: [jfx21u] Integrated: 8328994: Update WebKit to 619.1 In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 09:57:50 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit [34bbf853](https://github.com/openjdk/jfx/commit/34bbf85362fae946c6306eb52a8478aa2ca3ef5f) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Hima Bindu Meda on 16 Jul 2024 and was reviewed by Kevin Rushforth and Joeri Sykora. > > Thanks! This pull request has now been integrated. Changeset: 96df549f Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/96df549f0738a20af9cf43505d1407307b126faa Stats: 349763 lines in 7157 files changed: 184133 ins; 107646 del; 57984 mod 8328994: Update WebKit to 619.1 Backport-of: 34bbf85362fae946c6306eb52a8478aa2ca3ef5f ------------- PR: https://git.openjdk.org/jfx21u/pull/71 From jvos at openjdk.org Wed Sep 11 12:18:13 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 12:18:13 GMT Subject: [jfx17u] Integrated: 8328994: Update WebKit to 619.1 In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 10:06:27 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 34bbf853 from the openjdk/jfx repository. > > The commit being backported was authored by Hima Bindu Meda on 16 Jul 2024 and was reviewed by Kevin Rushforth and Joeri Sykora. > > Thanks! This pull request has now been integrated. Changeset: e9896f6a Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/e9896f6a7eef22738053dabd9431fa062a0560fc Stats: 349763 lines in 7157 files changed: 184133 ins; 107646 del; 57984 mod 8328994: Update WebKit to 619.1 Backport-of: 34bbf85362fae946c6306eb52a8478aa2ca3ef5f ------------- PR: https://git.openjdk.org/jfx17u/pull/203 From schernyshev at openjdk.org Wed Sep 11 12:20:14 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 12:20:14 GMT Subject: [jfx17u] RFR: 8334713: WebKit build failed on LoongArch64 because currentStackPointer is undefined In-Reply-To: References: <3LbnBVgzQvNMA1ACcwjal8HrhcbcHpeWkm-80PZqOp0=.a86131a1-f5c5-4cf9-af9c-c7a15d66e695@github.com> Message-ID: On Wed, 11 Sep 2024 06:51:22 GMT, Johan Vos wrote: > Thanks for this PR, much appreciated! I'm in the process of updating the webkit, sqlite and libxml. I believe this (and others) are valid PR's and will approve once I'm confident that they fit in the general update. Hi Johan! Thanks for your help. There are also JDK-8319762 and JDK-8319996 (the latter is dependent), that need to be ported prior to integrating the WebKit update. I created [PR/204](https://github.com/openjdk/jfx17u/pull/204) with the first one. Please have a look at it. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/199#issuecomment-2343510348 From jvos at openjdk.org Wed Sep 11 12:24:41 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 12:24:41 GMT Subject: [jfx17u] RFR: 8335548: testCookieEnabled fails with WebKit 619.1 Message-ID: <95rhvQPCoam2ThuJkk578Fik_B7CnPNs8tNmD83Ps4w=.7cb60e2a-da80-4bec-9ab4-b15fd2b992d6@github.com> Hi all, This pull request contains a backport of commit 33d82c04 from the openjdk/jfx repository. The commit being backported was authored by Jay Bhaskar on 21 Jul 2024 and was reviewed by Kevin Rushforth. Thanks! ------------- Commit messages: - Backport 33d82c04dd8c4c3fa9188da5c263e0f406a2c920 Changes: https://git.openjdk.org/jfx17u/pull/205/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=205&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335548 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/205.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/205/head:pull/205 PR: https://git.openjdk.org/jfx17u/pull/205 From jvos at openjdk.org Wed Sep 11 12:28:27 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 12:28:27 GMT Subject: [jfx21u] RFR: 8335548: testCookieEnabled fails with WebKit 619.1 Message-ID: Hi all, This pull request contains a backport of commit 33d82c04 from the openjdk/jfx repository. The commit being backported was authored by Jay Bhaskar on 21 Jul 2024 and was reviewed by Kevin Rushforth. Thanks! ------------- Commit messages: - Backport 33d82c04dd8c4c3fa9188da5c263e0f406a2c920 Changes: https://git.openjdk.org/jfx21u/pull/72/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=72&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335548 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/72.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/72/head:pull/72 PR: https://git.openjdk.org/jfx21u/pull/72 From jvos at openjdk.org Wed Sep 11 13:20:16 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 13:20:16 GMT Subject: [jfx21u] Integrated: 8335548: testCookieEnabled fails with WebKit 619.1 In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 12:23:42 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 33d82c04 from the openjdk/jfx repository. > > The commit being backported was authored by Jay Bhaskar on 21 Jul 2024 and was reviewed by Kevin Rushforth. > > Thanks! This pull request has now been integrated. Changeset: c15d5c3c Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/c15d5c3cc6d9cae8eba182bf062300493106a229 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod 8335548: testCookieEnabled fails with WebKit 619.1 Backport-of: 33d82c04dd8c4c3fa9188da5c263e0f406a2c920 ------------- PR: https://git.openjdk.org/jfx21u/pull/72 From jvos at openjdk.org Wed Sep 11 13:20:16 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 11 Sep 2024 13:20:16 GMT Subject: [jfx17u] Integrated: 8335548: testCookieEnabled fails with WebKit 619.1 In-Reply-To: <95rhvQPCoam2ThuJkk578Fik_B7CnPNs8tNmD83Ps4w=.7cb60e2a-da80-4bec-9ab4-b15fd2b992d6@github.com> References: <95rhvQPCoam2ThuJkk578Fik_B7CnPNs8tNmD83Ps4w=.7cb60e2a-da80-4bec-9ab4-b15fd2b992d6@github.com> Message-ID: On Wed, 11 Sep 2024 12:19:40 GMT, Johan Vos wrote: > Hi all, > > This pull request contains a backport of commit 33d82c04 from the openjdk/jfx repository. > > The commit being backported was authored by Jay Bhaskar on 21 Jul 2024 and was reviewed by Kevin Rushforth. > > Thanks! This pull request has now been integrated. Changeset: 5b397353 Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/5b3973537d79881a490c977869ee09bb4ea5792e Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod 8335548: testCookieEnabled fails with WebKit 619.1 Backport-of: 33d82c04dd8c4c3fa9188da5c263e0f406a2c920 ------------- PR: https://git.openjdk.org/jfx17u/pull/205 From duke at openjdk.org Wed Sep 11 13:46:11 2024 From: duke at openjdk.org (duke) Date: Wed, 11 Sep 2024 13:46:11 GMT Subject: [jfx17u] RFR: 8319762: Update to Visual Studio 2022 version 17.6.5 on Windows In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 10:57:02 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [2d4b494e](https://github.com/openjdk/jfx/commit/2d4b494ea9cee1acd0407b9de61f0af9163f5d62) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The fix being backported was authored by @kevinrushforth on 15 Nov 2023 and was reviewed by @tiainen and @arapte. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! @sercher Your change (at version e973e01a989457a3767f4c8e4abafab250e08748) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/204#issuecomment-2343716655 From schernyshev at openjdk.org Wed Sep 11 13:52:13 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 13:52:13 GMT Subject: [jfx17u] Integrated: 8319762: Update to Visual Studio 2022 version 17.6.5 on Windows In-Reply-To: References: Message-ID: <7k_GRMtGWSB5ynBSVyRrOk-depslRibQoQcIXOTNfwQ=.9e5e865e-10e0-4c38-b438-8ef06e836480@github.com> On Wed, 11 Sep 2024 10:57:02 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review a clean backport of [2d4b494e](https://github.com/openjdk/jfx/commit/2d4b494ea9cee1acd0407b9de61f0af9163f5d62) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The fix being backported was authored by @kevinrushforth on 15 Nov 2023 and was reviewed by @tiainen and @arapte. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! This pull request has now been integrated. Changeset: 3291fbd6 Author: Sergey Chernyshev Committer: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/3291fbd6f926c3b303670a51761a5b8805dca46c Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8319762: Update to Visual Studio 2022 version 17.6.5 on Windows Backport-of: 2d4b494ea9cee1acd0407b9de61f0af9163f5d62 ------------- PR: https://git.openjdk.org/jfx17u/pull/204 From schernyshev at openjdk.org Wed Sep 11 14:15:51 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 11 Sep 2024 14:15:51 GMT Subject: [jfx17u] RFR: 8319996: Update to GCC 13.2.0 on Linux Message-ID: Hi all, Please review this clean backport of [2e733041](https://github.com/openjdk/jfx/commit/2e7330417c2f39fee15676966d5b7455bb3fcbff) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The fix being backported was authored by @kevinrushforth on 16 Nov 2023 and was reviewed by @arapte and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. Thanks! ------------- Commit messages: - Backport 2e7330417c2f39fee15676966d5b7455bb3fcbff Changes: https://git.openjdk.org/jfx17u/pull/206/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=206&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319996 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx17u/pull/206.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/206/head:pull/206 PR: https://git.openjdk.org/jfx17u/pull/206 From kcr at openjdk.org Wed Sep 11 14:47:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Sep 2024 14:47:42 GMT Subject: RFR: 8339517: Add --enable-native-access flag when running tests Message-ID: When running JavaFX tests and apps with JDK 24, we now get illegal access warnings of the following form: WARNING: A restricted method in java.lang.System has been called WARNING: java.lang.System::load has been called by com.sun.glass.utils.NativeLibLoader in module javafx.graphics (file:build/shims/javafx.graphics/) WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module WARNING: Restricted methods will be blocked in a future release unless native access is enabled With the current jfx master, I get 301 such warnings on my macOS system (see the `test.log` file attached to the JBS bug report). In order to avoid those warnings, and to avoid the eventual errors in the future, we need to pass one of the following two options when running test programs: * "java --enable-native-access=javafx.graphics,javafx.media,javafx.web" -- for unit tests in the web and systemTests subprojects, as well as in the generated `build/run.args` file * "java --enable-native-access=javafx.graphics" -- for all other unit tests With this patch, we are down to 5 such warnings on macOS (on Linux there are few more, but the reasons are the same). The remaining warnings are due to the following two issues: 1. We are making a native JNI call from javafx.swing, which we should not be doing. This is a JavaFX bug. The native library in question is loaded by the javafx.graphics modules, so the solution will likely be to move the native method call to somewhere in javafx.graphics and call that new method from javafx.swing. 2. We have two unit tests that use a custom `ModuleLayer` to load the JavaFX modules at runtime, after the test application is launched. In this case the "--enable-native-access" is ineffective. I suspect this is a JDK bug. I will file a pair of follow-on bugs for these. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into 8339517-enable-jni - Add --enable-native-access in two tests that don't use run.args - 8339517: Add --enable-native-access flag when running tests Changes: https://git.openjdk.org/jfx/pull/1562/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1562&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339517 Stats: 37 lines in 3 files changed: 32 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1562.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1562/head:pull/1562 PR: https://git.openjdk.org/jfx/pull/1562 From kcr at openjdk.org Wed Sep 11 14:47:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Sep 2024 14:47:42 GMT Subject: RFR: 8339517: Add --enable-native-access flag when running tests In-Reply-To: References: Message-ID: <23D2J_Zcwx2cBMgqQO5GQh1XqZvgOCh4mo_hN1UzIFs=.877369f9-e0aa-44a1-b137-4ca8fd140717@github.com> On Wed, 11 Sep 2024 14:42:19 GMT, Kevin Rushforth wrote: > When running JavaFX tests and apps with JDK 24, we now get illegal access warnings of the following form: > > > WARNING: A restricted method in java.lang.System has been called > WARNING: java.lang.System::load has been called by com.sun.glass.utils.NativeLibLoader in module javafx.graphics (file:build/shims/javafx.graphics/) > WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module > WARNING: Restricted methods will be blocked in a future release unless native access is enabled > > > With the current jfx master, I get 301 such warnings on my macOS system (see the `test.log` file attached to the JBS bug report). > > In order to avoid those warnings, and to avoid the eventual errors in the future, we need to pass one of the following two options when running test programs: > > * "java --enable-native-access=javafx.graphics,javafx.media,javafx.web" -- for unit tests in the web and systemTests subprojects, as well as in the generated `build/run.args` file > * "java --enable-native-access=javafx.graphics" -- for all other unit tests > > With this patch, we are down to 5 such warnings on macOS (on Linux there are few more, but the reasons are the same). The remaining warnings are due to the following two issues: > > 1. We are making a native JNI call from javafx.swing, which we should not be doing. This is a JavaFX bug. The native library in question is loaded by the javafx.graphics modules, so the solution will likely be to move the native method call to somewhere in javafx.graphics and call that new method from javafx.swing. > 2. We have two unit tests that use a custom `ModuleLayer` to load the JavaFX modules at runtime, after the test application is launched. In this case the "--enable-native-access" is ineffective. I suspect this is a JDK bug. > > I will file a pair of follow-on bugs for these. Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1562#issuecomment-2343880481 From angorya at openjdk.org Wed Sep 11 15:09:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Sep 2024 15:09:12 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 01:05:33 GMT, Michael Strau? wrote: >> Public APIs for focus traversal and the focus traversal policy: >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md >> >> This work is loosely based on the patch >> https://cr.openjdk.org/~jgiles/8061673/ > > By its own admission, this proposal basically promotes an internal implementation to public API (albeit with some refactoring). This may or may not be a good idea, so I'd like to take a step back and look at the problem we're trying to solve. > > Looking at several of the linked JBS issues, a missing feature of JavaFX is the ability to customize the focus traversal logic of a custom control (or a container of nodes in the widest sense of the word). Any proposed solution should support complex scenarios like toolbars with overflow, or [radio groups](https://www.w3.org/TR/2009/WD-wai-aria-practices-20090224/#radiobutton). > > I think there are two distinct modes of focus traversal: logical ("tabbing") and directional (arrow keys). Both modes are independent axes of the problem at hand, and should be customizable independently from each other. > > The current implementation provides a single `Algorithm` (or `TraversalPolicy` after the refactoring) for both traversal modes. I've played around with the code for a while, and while in theory I can provide my own `TraversalPolicy`, it can be quite a lot of code and it's not as easy as it could be. Additionally, it is hard to customize the traversal policies of the substructure of skinnable controls. > > I question whether we need custom traversal policies at all, as the ways in which focus can move from one node to the next are quite limited: > 1. **Permeable edges**: The next node in a container is selected until an edge is reached, then the input focus leaves the container. > 2. **Confined to container**: The next node in a container is selected until the end of the container is reached; then the input focus doesn't move on. > 3. **Cyclic in container**: Like confined, but at the end of the container, the input focus wraps around to the first element. > 4. **Single focused node in container**: When the input focus enters a container, it moves to the node that was most recently selected (or to the first node in the container if none of the nodes was selected before); after that the input focus leaves the container. > > Having two traversal toggles (logical and directional), each with four possible modes, already solves most of the problem. The advantage of this over a custom policy implementation is that these properties can be modelled with an enumeration and easily be set by control and application developers, and they can also be set via CSS. This allows developers to customize the focus traversal behavior of existing skinnable cont... Thank you @mstr2 for a detailed writeup! I fully agree with you that the majority of use cases can be handled with the existing policies. The default one seems to be geometry-based ("directional") _where supported_, and the other being a "logical" one which is not explicitly accessible. The question, therefore, is do we need a static getter for that kind of a policy? (I'd say no since the logical order depends on a particular control). A couple of points: 1. setting via CSS is not a goal (I probably should mention this in the JEP) 2. the 4-item enumeration is not complete. For example, application may specify some other, or even dynamic, order of traversal, which would require a custom policy. Another question is whether there exists a policy that cannot be implemented by the new APIs provided by this PR. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2343940594 From angorya at openjdk.org Wed Sep 11 15:33:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Sep 2024 15:33:11 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 16:30:51 GMT, Kevin Rushforth wrote: >> Public APIs for focus traversal and the focus traversal policy: >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md >> >> This work is loosely based on the patch >> https://cr.openjdk.org/~jgiles/8061673/ > > modules/javafx.graphics/src/main/java/javafx/scene/traversal/FocusTraversal.java line 63: > >> 61: >> 62: /** >> 63: * Traverse focus downward as a response to pressing a key. > > Is this a convenience method like the ones that follow? If so, add docs (and if not, why not?). missed this one! thanks. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1754970299 From mstrauss at openjdk.org Wed Sep 11 17:21:12 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Sep 2024 17:21:12 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 15:06:07 GMT, Andy Goryachev wrote: > The default one seems to be geometry-based ("directional") _where supported_, and the other being a "logical" one which is not explicitly accessible. The question, therefore, is do we need a static getter for that kind of a policy? (I'd say no since the logical order depends on a particular control). I don't quite understand what you mean by "not explicitly accessible". Both categories are exposed with the `TraversalDirection` enum: `UP`, `DOWN`, `LEFT`, and `RIGHT` are the directional modes, whereas `NEXT`, `NEXT_IN_LINE`, and `PREVIOUS` are the logical modes. I think that disentangling those two categories, and having a set of predefined traversal policies that can be set independently for both of those, will be good enough for 99% of cases. The reason I'm bringing this up is that `Algorithm` (now `TraversalPolicy`) is too low-level to be useful for most application developers. _We_ should be implementing those algorithms, and then allow developers to compose them as they see fit. When I look at the existing code, I see quite a lot of bespoke `Algorithm` implementations. For example, `ToolBarSkin` has almost 100 lines of code dedicated to a custom implementation. However, when I just remove this implementation entirely, I get _almost_ the exact same focus traversal behavior, even in complicated scenarios like when a toolbar item is itself a focus-traversable container. This suggests to me that we shouldn't encourage the proliferation of even more bespoke implementations, but make it easier to compose well-tested existing algorithms. > > A couple of points: > > 1. setting via CSS is not a goal (I probably should mention this in the JEP) > 2. the 4-item enumeration is not complete. For example, application may specify some other, or even dynamic, order of traversal, which would require a custom policy. We can add scenarios to this list if it is not complete, and then see if we still need the option to create a custom traversal algorithm. My point is that the API should be tailored to be simple and useful in 99% of cases, and then maybe have an additional extension point for the rest. Right now, you're proposing to expose the lowest-level API which requires developers to reason about the scene graph and find individual nodes, which I think should be reconsidered. When I look at various JBS issues and browse StackOverflow, I notice that most developers are only looking for pretty simple things like cyclic traversal in a container. It's probably prudent to tailor the API for those use cases. > > Another question is whether there exists a policy that cannot be implemented by the new APIs provided by this PR. > > What do you think? Since the API works directly on the scene graph, you can probably create all kinds of algorithms with it. The downside of that is, however, that all implementations are ad-hoc solutions that don't generalize. For example, the radio group I mentioned earlier suggests that we should have an API to define an "entry point" into a container of nodes. You can do that with a custom implementation, but I think having this be elevated to a proper API would be better. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2344259476 From angorya at openjdk.org Wed Sep 11 17:24:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Sep 2024 17:24:13 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 16:38:26 GMT, Kevin Rushforth wrote: >> Public APIs for focus traversal and the focus traversal policy: >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md >> >> This work is loosely based on the patch >> https://cr.openjdk.org/~jgiles/8061673/ > > modules/javafx.graphics/src/main/java/javafx/scene/traversal/TraversalMethod.java line 26: > >> 24: */ >> 25: >> 26: package javafx.scene.traversal; > > You need an `@since` javadoc tag on this class. should we add `@since` on all the new classes and `package-info.java`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1755204088 From duke at openjdk.org Wed Sep 11 17:59:10 2024 From: duke at openjdk.org (duke) Date: Wed, 11 Sep 2024 17:59:10 GMT Subject: [jfx17u] RFR: 8319996: Update to GCC 13.2.0 on Linux In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 14:10:15 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review this clean backport of [2e733041](https://github.com/openjdk/jfx/commit/2e7330417c2f39fee15676966d5b7455bb3fcbff) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The fix being backported was authored by @kevinrushforth on 16 Nov 2023 and was reviewed by @arapte and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! @sercher Your change (at version 93c9f7e77d51b630f91fb21615e1514a486d0a89) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/206#issuecomment-2344331104 From kcr at openjdk.org Wed Sep 11 22:16:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Sep 2024 22:16:23 GMT Subject: RFR: 8339517: Add --enable-native-access flag when running tests [v2] In-Reply-To: References: Message-ID: > When running JavaFX tests and apps with JDK 24, we now get illegal access warnings of the following form: > > > WARNING: A restricted method in java.lang.System has been called > WARNING: java.lang.System::load has been called by com.sun.glass.utils.NativeLibLoader in module javafx.graphics (file:build/shims/javafx.graphics/) > WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module > WARNING: Restricted methods will be blocked in a future release unless native access is enabled > > > With the current jfx master, I get 301 such warnings on my macOS system (see the `test.log` file attached to the JBS bug report). > > In order to avoid those warnings, and to avoid the eventual errors in the future, we need to pass one of the following two options when running test programs: > > * "java --enable-native-access=javafx.graphics,javafx.media,javafx.web" -- for unit tests in the web and systemTests subprojects, as well as in the generated `build/run.args` file > * "java --enable-native-access=javafx.graphics" -- for all other unit tests > > With this patch, we are down to 5 such warnings on macOS (on Linux there are few more, but the reasons are the same). The remaining warnings are due to the following two issues: > > 1. We are making a native JNI call from javafx.swing, which we should not be doing. This is a JavaFX bug. The native library in question is loaded by the javafx.graphics modules, so the solution will likely be to move the native method call to somewhere in javafx.graphics and call that new method from javafx.swing. > 2. We have two unit tests that use a custom `ModuleLayer` to load the JavaFX modules at runtime, after the test application is launched. In this case the "--enable-native-access" is ineffective. I suspect this is a JDK bug. > > I will file a pair of follow-on bugs for these. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: ModuleLayer tests need to enable native access for unnamed module ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1562/files - new: https://git.openjdk.org/jfx/pull/1562/files/0d41aacd..bc93221e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1562&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1562&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1562.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1562/head:pull/1562 PR: https://git.openjdk.org/jfx/pull/1562 From kcr at openjdk.org Wed Sep 11 22:29:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Sep 2024 22:29:09 GMT Subject: RFR: 8339517: Add --enable-native-access flag when running tests [v2] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 22:16:23 GMT, Kevin Rushforth wrote: >> When running JavaFX tests and apps with JDK 24, we now get illegal access warnings of the following form: >> >> >> WARNING: A restricted method in java.lang.System has been called >> WARNING: java.lang.System::load has been called by com.sun.glass.utils.NativeLibLoader in module javafx.graphics (file:build/shims/javafx.graphics/) >> WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module >> WARNING: Restricted methods will be blocked in a future release unless native access is enabled >> >> >> With the current jfx master, I get 301 such warnings on my macOS system (see the `test.log` file attached to the JBS bug report). >> >> In order to avoid those warnings, and to avoid the eventual errors in the future, we need to pass one of the following two options when running test programs: >> >> * "java --enable-native-access=javafx.graphics,javafx.media,javafx.web" -- for unit tests in the web and systemTests subprojects, as well as in the generated `build/run.args` file >> * "java --enable-native-access=javafx.graphics" -- for all other unit tests >> >> With this patch, we are down to 5 such warnings on macOS (on Linux there are few more, but the reasons are the same). The remaining warnings are due to the following two issues: >> >> 1. We are making a native JNI call from javafx.swing, which we should not be doing. This is a JavaFX bug. The native library in question is loaded by the javafx.graphics modules, so the solution will likely be to move the native method call to somewhere in javafx.graphics and call that new method from javafx.swing. >> 2. We have two unit tests that use a custom `ModuleLayer` to load the JavaFX modules at runtime, after the test application is launched. In this case the "--enable-native-access" is ineffective. I suspect this is a JDK bug. >> >> I will file a pair of follow-on bugs for these. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > ModuleLayer tests need to enable native access for unnamed module Update on problem 2: > We have two unit tests that use a custom `ModuleLayer` to load the JavaFX modules at runtime, after the test application is launched. In this case the "--enable-native-access" is ineffective. I suspect this is a JDK bug. This turned out to be a test bug. When using a custom `ModuleLayer` to load classes, a test (or application) needs to call `ModuleLayer.Controller::enableNativeAccess`. So the follow-up bug will be to do this in those tests. (the reason it will be a follow-up bug is that `ModuleLayer.Controller::enableNativeAccess` was preview in JDK 21 and final in JDK 22 along with Panama, so unless we want to do this via reflection, we need to wait until we bump the minimum JDK for JavaFX). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1562#issuecomment-2344812737 From john.hendrikx at gmail.com Thu Sep 12 02:05:26 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 12 Sep 2024 04:05:26 +0200 Subject: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: Hi Andy / List, I've given this some thought first,?without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ##?KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS.? Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...).? The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying.? Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc.? The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable.? If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved.? If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed.? With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns.? The goal here is to have policies in place that cover all use cases in current FX provided controls.? This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation.? These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent.? Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents).? This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum.? I would suggest the following options: - OPEN This policy should be the default policy for all Parents.? It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy.? If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not.? This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation.? In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control.? This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start.? For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up.? This policy allows you to completely disable directional and/or logical navigation for a control.? Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment.? There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available.? A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs).? A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to?IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler).? Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options.? After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already.? For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller.? Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation.? If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: ??? Node from = ... ??? switch (((KeyEvent)event).getCode()) { ??? case UP: ??????? FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); ??????? event.consume(); ??????? break; ??? case DOWN: ??????? // or use the convenience method ??????? FocusTraversal.traverseDown(from); ??????? event.consume(); ??????? break; ??? } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change?? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example?code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases).? So this code will almost never be needed.? However, in the event that you need something even more specific, you may consider handling Traversal events directly.? In which case the code should IMHO look something like this: ??? Node from = ... ??? Node result = switch(traversalEvent.getEventType()) { ?? ?? case TraversalEvent.UP -> FocusTraversals.findUp(from); ?? ?? case TraversalEvent.DOWN -> FocusTraversals.findDown(from); ? ? ? // etc ?? } ??? if (result != null) { ???????? result.requestFocus(); ???????? traversalEvent.consume(); ??? } Note that the above code leaves the final decision to call requestFocus up to the caller.? It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to?NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation).? It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants.? It also allows (in the case of no Node being found) to pick its own preferred Node in those cases.? In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static.? Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result? = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event?? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty.? What does it mean if I filter this event?? What if I consume it?? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: > > Dear fellow developers: > > I'd like to propose the public focus traversal API: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > > Draft PR: > > https://github.com/openjdk/jfx/pull/1555 > > Your comments and suggestions will be warmly accepted and appreciated. > > Thank you > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schernyshev at openjdk.org Thu Sep 12 07:34:10 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Thu, 12 Sep 2024 07:34:10 GMT Subject: [jfx17u] Integrated: 8319996: Update to GCC 13.2.0 on Linux In-Reply-To: References: Message-ID: <30HfK2dFxB0zuj-aWAbbz9bSgBlYNXFrDj44KAtZ1zY=.d721818e-b5ef-4956-b659-3c99845ba650@github.com> On Wed, 11 Sep 2024 14:10:15 GMT, Sergey Chernyshev wrote: > Hi all, > > Please review this clean backport of [2e733041](https://github.com/openjdk/jfx/commit/2e7330417c2f39fee15676966d5b7455bb3fcbff) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The fix being backported was authored by @kevinrushforth on 16 Nov 2023 and was reviewed by @arapte and @tiainen. This is part of the prerequisites for backporting WebKit 619.1 to OpenJFX 17. > > Thanks! This pull request has now been integrated. Changeset: 11c9c81f Author: Sergey Chernyshev Committer: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/11c9c81fc66ea8ccea2fad3dc4d0a9ae13f8e4ca Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod 8319996: Update to GCC 13.2.0 on Linux Backport-of: 2e7330417c2f39fee15676966d5b7455bb3fcbff ------------- PR: https://git.openjdk.org/jfx17u/pull/206 From jhendrikx at openjdk.org Thu Sep 12 07:57:20 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 12 Sep 2024 07:57:20 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Sun, 8 Sep 2024 20:55:53 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small doc changes, copyright header Marked as reviewed by jhendrikx (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2299499543 From arapte at openjdk.org Thu Sep 12 11:14:16 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 12 Sep 2024 11:14:16 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 In-Reply-To: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: <-Hga2Og1agRuHsoe1NsmVR1aBVORi4lrWf1IKnImTdo=.0c23f583-5f0f-4e31-8067-82dcd7a46e28@github.com> On Mon, 9 Sep 2024 19:36:29 GMT, Andy Goryachev wrote: > Further additions to the MonkeyTester application: > > - tree/table view column property sheets ? > - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? > - properties... context menu ? > - context menu: table columns, toolbar items ? > - control.context menu option > - property monitor tool ? > - accessibility logging ? > > - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) > - Page -> Snapped Split Panes menu option for the control container > > This PR simply syncs up with the dev repository > https://github.com/andy-goryachev-oracle/MonkeyTest Providing a few comments observed when running MonkeyTester app. 1. Z transformations Scale Z / Translate Z can be avoided for 2D controls / shapes 2. TreeTableView height is fixed. It always shows 1 row. Changes in TreeTableView->Root does not have any effect. Height of TTV could vary with the number of rows. 3. Button: Button does not receive ENTER key press event when set as default button. 3.1 Check default button. 3.2 Move focus on button by clicking on it 3.3 Press ENTER key => button does not show pressed effect. Press space button, button shows pressed effect. 4. ChoiceBox/ColorPicker/MenuBar background cannot be set back to the default. Changing back the background to has no effect 5. No pages were getting rendered after following NPE was observed with RadioButton sample: Attaching the user preferences file with which issue can be reproduced [ui-settings.properties.zip](https://github.com/user-attachments/files/16978042/ui-settings.properties.zip) Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "javafx.geometry.Pos.getHpos()" because the return value of "javafx.scene.control.RadioButton.getAlignment()" is null at javafx.controls at 24-internal/javafx.scene.control.skin.RadioButtonSkin.layoutChildren(RadioButtonSkin.java:136) at javafx.controls at 24-internal/javafx.scene.control.Control.layoutChildren(Control.java:612) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1208) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) at javafx.graphics at 24-internal/javafx.scene.Scene.doLayoutPass(Scene.java:596) at javafx.graphics at 24-internal/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2603) at javafx.graphics at 24-internal/com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) at java.base/java.security.AccessController.doPrivileged(AccessController.java:400) at javafx.graphics at 24-internal/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) at javafx.graphics at 24-internal/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) at javafx.graphics at 24-internal/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:598) at javafx.graphics at 24-internal/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:578) at javafx.graphics at 24-internal/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:571) at javafx.graphics at 24-internal/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) at javafx.graphics at 24-internal/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) tests/manual/monkey/src/com/oracle/tools/fx/monkey/util/WritingSystemsDemo.java line 2: > 1: /* > 2: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. Looks like unintended change. could be reverted. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1560#issuecomment-2345999475 PR Review Comment: https://git.openjdk.org/jfx/pull/1560#discussion_r1756649126 From kcr at openjdk.org Thu Sep 12 11:20:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Sep 2024 11:20:12 GMT Subject: Integrated: 8339247: Create release notes for JavaFX 23 In-Reply-To: References: Message-ID: On Fri, 30 Aug 2024 12:47:38 GMT, Kevin Rushforth wrote: > This PR adds the release notes for the JavaFX 23 release. This will first go into `master`, and then be backported to the `jfx23` branch so it will be available in that branch when JavaFX 23 is published (and from there also synced into the `jfx23u` repo). > > The following filter was used to produce the list of issues fixed in JavaFX 23: > > https://bugs.openjdk.org/issues/?filter=45422 > > Additionally, we had three issues with a `release-note=yes` label, which are included in the list of important changes. > > I will wait until closer to the September 17th release date to integrate this. > > > A [suggestion was made last time](https://github.com/openjdk/jfx/pull/1402#issuecomment-1998821014) to split out the new features (something that adds new functionality to the platform) from enhancements. If we decide to do that, here is my proposed split: > > ## List of New Features > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8092102](https://bugs.openjdk.org/browse/JDK-8092102)|Labeled: textTruncated property|controls > [JDK-8313138](https://bugs.openjdk.org/browse/JDK-8313138)|Scrollbar Keyboard enhancement|controls > [JDK-8267565](https://bugs.openjdk.org/browse/JDK-8267565)|Support "@3x" and greater high-density image naming convention|graphics > [JDK-8311895](https://bugs.openjdk.org/browse/JDK-8311895)|CSS Transitions|graphics > [JDK-8282999](https://bugs.openjdk.org/browse/JDK-8282999)|Add support for EXT-X-MEDIA tag in HTTP Live Streaming|media > > ## List of Other Enhancements > > Issue key|Summary|Subcomponent > ---------|-------|------------ > [JDK-8321603](https://bugs.openjdk.org/browse/JDK-8321603)|Bump minimum JDK version for JavaFX to JDK 21|build > [JDK-8322748](https://bugs.openjdk.org/browse/JDK-8322748)|Caret blinking in JavaFX should only stop when caret moves|controls > [JDK-8322964](https://bugs.openjdk.org/browse/JDK-8322964)|Optimize performance of CSS selector matching|graphics > [JDK-8324182](https://bugs.openjdk.org/browse/JDK-8324182)|Deprecate for removal SimpleSelector and CompoundSelector classes|graphics > [JDK-8325900](https://bugs.openjdk.org/browse/JDK-8325900)|Emit a warning on macOS if AWT has set the NSAppearance|graphics This pull request has now been integrated. Changeset: 639f1383 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/639f138380a4091befa3046f7211aab77f8d77dd Stats: 145 lines in 1 file changed: 145 ins; 0 del; 0 mod 8339247: Create release notes for JavaFX 23 Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1553 From kcr at openjdk.org Thu Sep 12 11:48:20 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Sep 2024 11:48:20 GMT Subject: [jfx23] RFR: 8339247: Create release notes for JavaFX 23 Message-ID: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com> Backport the JavaFX 23 release notes to the `jfx23` branch. Note that we will _not_ trigger a respin of JavaFX 23 as a result of this. ------------- Commit messages: - Backport 639f138380a4091befa3046f7211aab77f8d77dd Changes: https://git.openjdk.org/jfx/pull/1563/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1563&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339247 Stats: 145 lines in 1 file changed: 145 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1563.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1563/head:pull/1563 PR: https://git.openjdk.org/jfx/pull/1563 From nlisker at openjdk.org Thu Sep 12 12:48:18 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 12 Sep 2024 12:48:18 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Sat, 3 Aug 2024 00:14:04 GMT, Michael Strau? wrote: >> modules/javafx.base/src/main/java/com/sun/javafx/UnmodifiableArrayList.java line 81: >> >>> 79: >>> 80: @SuppressWarnings("unchecked") >>> 81: T[] newValues = (T[])new Object[list.size()]; >> >> With many `null`s this array may be too big. If that's intended, then ignore this comment. > > That may be the case, but I think that's preferrable to requiring two iterations of the list (one to figure out how many non-null values it contains, the second to copy over the values). In practice, there shouldn't be any nulls in most cases, as I don't know why someone would construct a `Background` or `Border` with many nulls in there. Is this code required to be so highly performant that you need to check for `RandomAccess`? Under normal circumstances, I would just stream the list and filter for `null`s. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1756788623 From kcr at openjdk.org Thu Sep 12 12:51:27 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Sep 2024 12:51:27 GMT Subject: RFR: 8339517: Add --enable-native-access flag when running tests [v3] In-Reply-To: References: Message-ID: > When running JavaFX tests and apps with JDK 24, we now get illegal access warnings of the following form: > > > WARNING: A restricted method in java.lang.System has been called > WARNING: java.lang.System::load has been called by com.sun.glass.utils.NativeLibLoader in module javafx.graphics (file:build/shims/javafx.graphics/) > WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module > WARNING: Restricted methods will be blocked in a future release unless native access is enabled > > > With the current jfx master, I get 301 such warnings on my macOS system (see the `test.log` file attached to the JBS bug report). > > In order to avoid those warnings, and to avoid the eventual errors in the future, we need to pass one of the following two options when running test programs: > > * "java --enable-native-access=javafx.graphics,javafx.media,javafx.web" -- for unit tests in the web and systemTests subprojects, as well as in the generated `build/run.args` file > * "java --enable-native-access=javafx.graphics" -- for all other unit tests > > With this patch, we are down to 5 such warnings on macOS (on Linux there are few more, but the reasons are the same). The remaining warnings are due to the following two issues: > > 1. We are making a native JNI call from javafx.swing, which we should not be doing. This is a JavaFX bug. The native library in question is loaded by the javafx.graphics modules, so the solution will likely be to move the native method call to somewhere in javafx.graphics and call that new method from javafx.swing. > 2. We have two unit tests that use a custom `ModuleLayer` to load the JavaFX modules at runtime, after the test application is launched. In this case the "--enable-native-access" is ineffective. I suspect this is a JDK bug. > > I will file a pair of follow-on bugs for these. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Enable native access in ModuleLayer tests (using reflection until JDK 22 is the minimum) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1562/files - new: https://git.openjdk.org/jfx/pull/1562/files/bc93221e..039e4b74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1562&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1562&range=01-02 Stats: 22 lines in 2 files changed: 20 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1562.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1562/head:pull/1562 PR: https://git.openjdk.org/jfx/pull/1562 From kcr at openjdk.org Thu Sep 12 12:55:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Sep 2024 12:55:11 GMT Subject: RFR: 8339517: Add --enable-native-access flag when running tests [v2] In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 22:26:06 GMT, Kevin Rushforth wrote: > This turned out to be a test bug. When using a custom `ModuleLayer` to load classes, a test (or application) needs to call `ModuleLayer.Controller::enableNativeAccess`. So the follow-up bug will be to do this in those tests. > > (the reason it will be a follow-up bug is that `ModuleLayer.Controller::enableNativeAccess` was preview in JDK 21 and final in JDK 22 along with Panama, so unless we want to do this via reflection, we need to wait until we bump the minimum JDK for JavaFX). Since I need a follow-up bug for this either way, I decided to fix this using reflection for now, and file a follow-up bug to replace the reflection calls with direct calls to `ModuleLayer.Controller::enableNativeAccess` once we bump the minimum to JDK 22. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1562#issuecomment-2346201798 From kcr at openjdk.org Thu Sep 12 12:55:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Sep 2024 12:55:13 GMT Subject: RFR: 8339517: Add --enable-native-access flag when running tests [v3] In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 12:51:27 GMT, Kevin Rushforth wrote: >> When running JavaFX tests and apps with JDK 24, we now get illegal access warnings of the following form: >> >> >> WARNING: A restricted method in java.lang.System has been called >> WARNING: java.lang.System::load has been called by com.sun.glass.utils.NativeLibLoader in module javafx.graphics (file:build/shims/javafx.graphics/) >> WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module >> WARNING: Restricted methods will be blocked in a future release unless native access is enabled >> >> >> With the current jfx master, I get 301 such warnings on my macOS system (see the `test.log` file attached to the JBS bug report). >> >> In order to avoid those warnings, and to avoid the eventual errors in the future, we need to pass one of the following two options when running test programs: >> >> * "java --enable-native-access=javafx.graphics,javafx.media,javafx.web" -- for unit tests in the web and systemTests subprojects, as well as in the generated `build/run.args` file >> * "java --enable-native-access=javafx.graphics" -- for all other unit tests >> >> With this patch, we are down to 5 such warnings on macOS (on Linux there are few more, but the reasons are the same). The remaining warnings are due to the following two issues: >> >> 1. We are making a native JNI call from javafx.swing, which we should not be doing. This is a JavaFX bug. The native library in question is loaded by the javafx.graphics modules, so the solution will likely be to move the native method call to somewhere in javafx.graphics and call that new method from javafx.swing. >> 2. We have two unit tests that use a custom `ModuleLayer` to load the JavaFX modules at runtime, after the test application is launched. In this case the "--enable-native-access" is ineffective. I suspect this is a JDK bug. >> >> I will file a pair of follow-on bugs for these. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Enable native access in ModuleLayer tests (using reflection until JDK 22 is the minimum) I filed the following two follow-up bugs: [JDK-8340005](https://bugs.openjdk.org/browse/JDK-8340005): Eliminate native access calls from javafx.swing [JDK-8340004](https://bugs.openjdk.org/browse/JDK-8340004): [TestBug] Call ModuleLayer.Controller::enableNativeAccess directly rather than via reflection ------------- PR Comment: https://git.openjdk.org/jfx/pull/1562#issuecomment-2346203738 From nlisker at gmail.com Thu Sep 12 12:59:29 2024 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 12 Sep 2024 15:59:29 +0300 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: > > Do you mind taking a look, and maybe helping answer some of my questions? > I'm just not getting any replies, so I'm somewhat confused. > I'll try to take a closer look during the weekend. There are a lot of issues in my queue that I can't find the time to get to. Also be patient with the replies, it takes time to get to an issue because there are many ideas/drafts and not a lot of people. The #1281 PR was closed due to inactivity. The next step there is to do a review of potential settings to add and check if it makes sense to add both sampler states and render states to the same class. See https://github.com/openjdk/jfx/pull/1281#discussion_r1412368579. You can see all the threads in the mailing list archive: http://mail.openjdk.java.net/pipermail/openjfx-dev/. On Tue, Sep 10, 2024 at 4:22?AM Knee Snap wrote: > @Nir Lisker Do you mind taking a look, and maybe > helping answer some of my questions? I'm just not getting any replies, so > I'm somewhat confused. > > ALSO, unrelated, I'm hoping to pick up the PR you dropped before: > https://github.com/openjdk/jfx/pull/1281 > What would be the process for me taking over your PR? I don't have access > to the original RFR email thread or feature proposal as I only recently > joined the mailing list. > > Thanks! > > On Fri, Sep 6, 2024 at 4:32?PM Knee Snap wrote: > >> Hi all, while waiting on Kevin to review the feature proposal (if I >> understand the process correctly), I have created a draft PR if anyone >> wants to have a look. It's not clear to me if we should be discussing >> implementation yet, the guide seems to contradict itself at points. But I >> think since we seem to have no further design discussion points we're okay >> to talk about implementation? >> >> Draft PR: https://github.com/openjdk/jfx/pull/1557 >> >> >> On Thu, Sep 5, 2024 at 9:08?PM Knee Snap wrote: >> >>> Thanks everyone who has commented and given feedback. >>> >>> With no further discussion points brought up, I'd like to move this >>> proposal along for review, and hopefully CSR creation. >>> >>> Is there anything I need to do besides say I'm ready to move forward? @Kevin >>> Rushforth >>> >>> >>> >>> On Wed, Sep 4, 2024, 12:24?PM Knee Snap wrote: >>> >>>> I don't know what gamma refers to in the context of vertex colors, >>>> sorry. >>>> >>>> It's not using the gamma color space if that's the question (but >>>> neither is the rest of JavaFX 3D). >>>> >>>> If gamma is meant as opacity, then setting the alpha color value will >>>> control opacity. >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Sep 4, 2024, 7:44?AM Andy Goryachev >>>> wrote: >>>> >>>>> I am not a 3D expert; one question: how is the gamma value set for >>>>> color interpolation? >>>>> >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> -andy >>>>> >>>>> >>>>> >>>>> *From: *openjfx-dev on behalf of Knee >>>>> Snap >>>>> *Date: *Tuesday, September 3, 2024 at 23:53 >>>>> *To: *openjfx-dev at openjdk.org >>>>> *Subject: *[Feature Proposal]: TriangleMesh - Vertex Color Support >>>>> >>>>> Hello all, >>>>> >>>>> >>>>> >>>>> This is a continuation of a previous email thread: "[Feature Proposal] >>>>> Vertex Colors on TriangleMesh". >>>>> >>>>> I'm creating a new email thread because after discussion I've put >>>>> together a feature proposal, and it serves largely as a summary of the >>>>> previous email thread. (Better organized as a feature proposal) >>>>> >>>>> >>>>> >>>>> *Feature Proposal:* >>>>> https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md >>>>> >>>>> I had previously discussed a draft PR, but considering how simple the >>>>> proposed public API additions are to discuss, I don't think it's actually >>>>> that helpful. >>>>> >>>>> >>>>> >>>>> *What's next?* >>>>> >>>>> I'm currently happy with the design and seeing as it's been discussed >>>>> already, I could probably ask Kevin for a review. But, I'd like to give >>>>> another opportunity for design discussion before doing so, just in-case >>>>> there are any further considerations brought up. >>>>> >>>>> So, I open up the floor again. Does anyone have any thoughts on this >>>>> proposal? Concerns? Questions? Suggestions? Constructive criticism? I >>>>> eagerly await the feedback. >>>>> >>>>> >>>>> >>>>> After API discussion concludes, I plan to pass it off to Kevin for >>>>> review/approval, and if it is approved, the subsequent CSR creation. >>>>> >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Thu Sep 12 13:08:20 2024 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 12 Sep 2024 16:08:20 +0300 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: By the way, regarding Metal, I don't know what state it's in. The work is done only by Oracle, so they will have to answer that (probably Kevin). The work is ongoing in the jfx sandbox: https://github.com/openjdk/jfx-sandbox/tree/master. I didn't see questions other than that. Did I miss them? On Thu, Sep 12, 2024 at 3:59?PM Nir Lisker wrote: > Do you mind taking a look, and maybe helping answer some of my questions? >> I'm just not getting any replies, so I'm somewhat confused. >> > > I'll try to take a closer look during the weekend. There are a lot of > issues in my queue that I can't find the time to get to. Also be patient > with the replies, it takes time to get to an issue because there are many > ideas/drafts and not a lot of people. > > The #1281 PR was closed due to inactivity. The next step there is to do a > review of potential settings to add and check if it makes sense to add both > sampler states and render states to the same class. See > https://github.com/openjdk/jfx/pull/1281#discussion_r1412368579. > > You can see all the threads in the mailing list archive: > http://mail.openjdk.java.net/pipermail/openjfx-dev/. > > On Tue, Sep 10, 2024 at 4:22?AM Knee Snap wrote: > >> @Nir Lisker Do you mind taking a look, and maybe >> helping answer some of my questions? I'm just not getting any replies, so >> I'm somewhat confused. >> >> ALSO, unrelated, I'm hoping to pick up the PR you dropped before: >> https://github.com/openjdk/jfx/pull/1281 >> What would be the process for me taking over your PR? I don't have access >> to the original RFR email thread or feature proposal as I only recently >> joined the mailing list. >> >> Thanks! >> >> On Fri, Sep 6, 2024 at 4:32?PM Knee Snap wrote: >> >>> Hi all, while waiting on Kevin to review the feature proposal (if I >>> understand the process correctly), I have created a draft PR if anyone >>> wants to have a look. It's not clear to me if we should be discussing >>> implementation yet, the guide seems to contradict itself at points. But I >>> think since we seem to have no further design discussion points we're okay >>> to talk about implementation? >>> >>> Draft PR: https://github.com/openjdk/jfx/pull/1557 >>> >>> >>> On Thu, Sep 5, 2024 at 9:08?PM Knee Snap wrote: >>> >>>> Thanks everyone who has commented and given feedback. >>>> >>>> With no further discussion points brought up, I'd like to move this >>>> proposal along for review, and hopefully CSR creation. >>>> >>>> Is there anything I need to do besides say I'm ready to move forward? @Kevin >>>> Rushforth >>>> >>>> >>>> >>>> On Wed, Sep 4, 2024, 12:24?PM Knee Snap wrote: >>>> >>>>> I don't know what gamma refers to in the context of vertex colors, >>>>> sorry. >>>>> >>>>> It's not using the gamma color space if that's the question (but >>>>> neither is the rest of JavaFX 3D). >>>>> >>>>> If gamma is meant as opacity, then setting the alpha color value will >>>>> control opacity. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Sep 4, 2024, 7:44?AM Andy Goryachev >>>>> wrote: >>>>> >>>>>> I am not a 3D expert; one question: how is the gamma value set for >>>>>> color interpolation? >>>>>> >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -andy >>>>>> >>>>>> >>>>>> >>>>>> *From: *openjfx-dev on behalf of Knee >>>>>> Snap >>>>>> *Date: *Tuesday, September 3, 2024 at 23:53 >>>>>> *To: *openjfx-dev at openjdk.org >>>>>> *Subject: *[Feature Proposal]: TriangleMesh - Vertex Color Support >>>>>> >>>>>> Hello all, >>>>>> >>>>>> >>>>>> >>>>>> This is a continuation of a previous email thread: "[Feature >>>>>> Proposal] Vertex Colors on TriangleMesh". >>>>>> >>>>>> I'm creating a new email thread because after discussion I've put >>>>>> together a feature proposal, and it serves largely as a summary of the >>>>>> previous email thread. (Better organized as a feature proposal) >>>>>> >>>>>> >>>>>> >>>>>> *Feature Proposal:* >>>>>> https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md >>>>>> >>>>>> I had previously discussed a draft PR, but considering how simple the >>>>>> proposed public API additions are to discuss, I don't think it's actually >>>>>> that helpful. >>>>>> >>>>>> >>>>>> >>>>>> *What's next?* >>>>>> >>>>>> I'm currently happy with the design and seeing as it's been discussed >>>>>> already, I could probably ask Kevin for a review. But, I'd like to give >>>>>> another opportunity for design discussion before doing so, just in-case >>>>>> there are any further considerations brought up. >>>>>> >>>>>> So, I open up the floor again. Does anyone have any thoughts on this >>>>>> proposal? Concerns? Questions? Suggestions? Constructive criticism? I >>>>>> eagerly await the feedback. >>>>>> >>>>>> >>>>>> >>>>>> After API discussion concludes, I plan to pass it off to Kevin for >>>>>> review/approval, and if it is approved, the subsequent CSR creation. >>>>>> >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Thu Sep 12 13:25:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Sep 2024 13:25:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Thu, 12 Sep 2024 12:45:25 GMT, Nir Lisker wrote: >> That may be the case, but I think that's preferrable to requiring two iterations of the list (one to figure out how many non-null values it contains, the second to copy over the values). In practice, there shouldn't be any nulls in most cases, as I don't know why someone would construct a `Background` or `Border` with many nulls in there. > > Is this code required to be so highly performant that you need to check for `RandomAccess`? Under normal circumstances, I would just stream the list and filter for `null`s. This can run tens of thousands of times per second, which is probably not the ideal use case for streams. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1756849114 From nlisker at openjdk.org Thu Sep 12 13:25:17 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 12 Sep 2024 13:25:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: <_HFbQ0Ac0dGcxeGuaK0SLatqTY7-h2wLbG_zYqkloWM=.7a8040bd-0f14-44aa-9f34-b1179edde064@github.com> Message-ID: On Thu, 12 Sep 2024 13:19:26 GMT, Michael Strau? wrote: >> Is this code required to be so highly performant that you need to check for `RandomAccess`? Under normal circumstances, I would just stream the list and filter for `null`s. > > This can run tens of thousands of times per second, which is probably not the ideal use case for streams. So looks like the circumstances are not normal :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1756854095 From nlisker at openjdk.org Thu Sep 12 13:43:18 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 12 Sep 2024 13:43:18 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Sun, 8 Sep 2024 20:55:53 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small doc changes, copyright header I won't be doing a full review, but I want to look at the API in case something was missed and regret it later :) The only other thing I was curious about is how the css specs decides which interpolation type to use for each type of value, and if we do the same. I thought that image interpolation is ambiguous: do you just jump to the other image or do you fade/blend from one to the other? I see that you went with the former, which is simpler, but the latter is more intuitive for me. One can use a custom interpolator, but I didn't look if it works with css. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2346312200 From mstrauss at openjdk.org Thu Sep 12 14:19:16 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Sep 2024 14:19:16 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 13:37:07 GMT, Nir Lisker wrote: > I won't be doing a full review, but I want to look at the API in case something was missed and regret it later :) > > The only other thing I was curious about is how the css specs decides which interpolation type to use for each type of value, and if we do the same. I thought that image interpolation is ambiguous: do you just jump to the other image or do you fade/blend from one to the other? I see that you went with the former, which is simpler, but the latter is more intuitive for me. One can use a custom interpolator, but I didn't look if it works with css. Fading between images is really hard, as its implications reach deep into the rendering system. For performance reasons, blending the images shouldn't be done by the CSS system on the CPU; instead, we would need a way to feed both images into the rendering system, such that they can be combined with two render passes. In addition to that, a background or border can layer multiple images on top of each other. In this case, it is unclear whether we would want each image layer to blend separately, or if the stack of images should blend as a whole. This would also require special support in the rendering system. That's probably the reason why smooth interpolation of images is not supported by specifications such as [Backgrounds Level 3](https://drafts.csswg.org/css-backgrounds-3/#propdef-background-image). Support for interpolation of images is coming in [Images Level 4](https://drafts.csswg.org/css-images-4/#interpolating-images), but that has not made its way yet into the work-in-progress [Backgrounds Level 4](https://drafts.csswg.org/css-backgrounds-4/). I'd say we take a slow approach here and wait until the pieces settle down to see where this potential future feature lands. As for the mor general question how we decide which interpolation type we support: the current implementation always tries to support smooth interpolation, except where it would be hard to do so. That's the same approach that the W3C spec uses. I think we can (and should) extend support for smooth interpolation in the future. For example, currently we can't smoothly interpolate between relative and absolute values, but this is a feature that can be added later. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2346429243 From kcr at openjdk.org Thu Sep 12 15:25:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Sep 2024 15:25:15 GMT Subject: [jfx23] RFR: 8339247: Create release notes for JavaFX 23 In-Reply-To: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com> References: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com> Message-ID: On Thu, 12 Sep 2024 11:43:14 GMT, Kevin Rushforth wrote: > Backport the JavaFX 23 release notes to the `jfx23` branch. Note that we will _not_ trigger a respin of JavaFX 23 as a result of this. @andy-goryachev-oracle @arapte @johanvos Can I get a quick review from one of you for this clean backport of the JavaFX 23 release notes to the `jfx23` branch? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1563#issuecomment-2346598157 From jvos at openjdk.org Thu Sep 12 16:09:16 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 12 Sep 2024 16:09:16 GMT Subject: [jfx23] RFR: 8339247: Create release notes for JavaFX 23 In-Reply-To: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com> References: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com> Message-ID: On Thu, 12 Sep 2024 11:43:14 GMT, Kevin Rushforth wrote: > Backport the JavaFX 23 release notes to the `jfx23` branch. Note that we will _not_ trigger a respin of JavaFX 23 as a result of this. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1563#pullrequestreview-2300796728 From kcr at openjdk.org Thu Sep 12 16:16:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Sep 2024 16:16:13 GMT Subject: [jfx23] Integrated: 8339247: Create release notes for JavaFX 23 In-Reply-To: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com> References: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com> Message-ID: On Thu, 12 Sep 2024 11:43:14 GMT, Kevin Rushforth wrote: > Backport the JavaFX 23 release notes to the `jfx23` branch. Note that we will _not_ trigger a respin of JavaFX 23 as a result of this. This pull request has now been integrated. Changeset: de5902cf Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/de5902cf2274894536686db69589240f2a13ae3d Stats: 145 lines in 1 file changed: 145 ins; 0 del; 0 mod 8339247: Create release notes for JavaFX 23 Reviewed-by: jvos Backport-of: 639f138380a4091befa3046f7211aab77f8d77dd ------------- PR: https://git.openjdk.org/jfx/pull/1563 From nlisker at openjdk.org Fri Sep 13 01:44:20 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Fri, 13 Sep 2024 01:44:20 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Sun, 8 Sep 2024 20:55:53 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small doc changes, copyright header But the docs specify the interpolation type. Changing it will not be backwards compatible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2347865771 From kneester77 at gmail.com Fri Sep 13 02:51:47 2024 From: kneester77 at gmail.com (Knee Snap) Date: Thu, 12 Sep 2024 19:51:47 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: Thanks Nir! No worries about being busy, my concern was when I didn't get replies to my questions about what I should be doing and procedural questions. But, it seems maybe I wasn't super clear about my questions since you aren't sure what they were. I also went through many days waiting for responses about expectations all while he was replying quickly to other emails, seemingly ignoring mine. I'm not suggesting he's done anything wrong, I can imagine perfectly good reasons for not having replied, but my questions were related to the contribution guidelines and expectations. So I've felt like I've been going foward without clear expectations of both myself and contributors, and like I wasn't even guaranteed a response at all. The only reference I had for how long I should expect to wait was based on the other emails I saw, which had fast replies. I'm hoping to clarify my responsibilities and expectations, and what I should expect from contributors, since there's a lot of stuff to get familiar with in the contribution guide, and it's my first time contributing. Due to that, it felt like those questions went mostly ignored and it wasn't a matter of being busy, as other emails were getting quick replies, though perhaps I didn't phrase them clearly. Hoping to now clear up my confusions about responsibilities. Your email has helped reassure me that I was not getting ignored, but instead just had a lower priority or something else that could cause it to take longer to get a reply. *Overall, I'd like to give some insight into what it has felt like for me to contribute to JavaFX for my first time. The contribution guide is good, but it hasn't been enough.* *This isn't here to point blame or to criticize, but instead give some perspective into my experience here and why this has been such a frustrating experience. Perhaps this will help improve the contribution experience for newcomers like me going forward keeping this in mind, but ideally it'll help set the stage for why I am so confused and help you guys resolve my confusions.* -> The contribution guide misled me in many ways here, and there are many questions I still do not have an answer to. -> To start off, it said to include a feature proposal, and it gave suggestions for various things to include. -> So, I wrote a long feature proposal email and sent it off. For a week I had a discussion with a contributor where we hashed out different design choices, I felt like we had appropriately discussed everything which had been discussed adequately, and was ready to get my feature proposal approved by Kevin. -> Everything was going great until one week in when Kevin replied and said he "would need to be convinced that multiple applications would benefit from such a feature, and that your proposed solution -- as documented and exposed by the public API -- is the best way to go." -> He also asked if I had read the contribution guide, implying he didn't think what I had previously sent wasn't me 1:1 following the contribution guide. -> I still don't understand why he sent that, I believe I presented exactly what the contribution guide wanted. There were a handful of things that got missed, but each were discussed in the email thread. -> Did he not read the proposal and assume I did it wrong? Did he read it and think it wasn't convincing? Did he want a new proposal which included the things which had been discussed in the email thread? -> So, with this confusion I asked for clarification as well as other questions relating to Metal like who was working on it, if I could have a contact for them, etc. -> Never got a reply! Okay, so what the heck am I supposed to do here? Kevin asked for new a feature proposal, and I guess for some inexplicable reason this one wasn't good enough? It doesn't seem like he even realized this was a feature proposal, but either way, he asked for a new one, so I'll make a new one. -> After looking at other feature proposals, I retooled my proposal and come up with something I was happy with, which I felt went above/beyond what was necessary. I've even prototyped an implementation which works that I can use to get a screenshot for the proposal, and to ensure my opinions of the design didn't change even after seeing it in practice. -> During this time Kevin even helped me sort out an issue building JavaFX, so here I am thinking that I've been given the green light to present a final feature proposal with all of my changes, and Kevin will review it. -> So, after finalizing a new proposal, I'm feeling good. I've expanded the proposal significantly, and it's now in a Git repository, which is what other contributors have been doing. -> I'd like to give everyone a chance to review the updated proposal, who knows maybe there could be something I missed. Then, I'll pass it off to Kevin. -> There's some discussion and Kevin even chimes in at one point. After a few days when there's no more discussion, I send out an email saying I'm reading to pass it off to Kevin for review. -> Then, I don't get a reply. After a little bit, I start to get very concerned since I see him actively replying to other emails, and he's still never touched the original email I sent asking him for clarification, and follow-up questions. -> At this point it's been almost 3 weeks since his confusing email, and I still have no clarification, and I've spent quite a lot of effort on this. The questions from before have come back. Did he even read my initial feature proposal? What if all this time he had just not read the original one? I've got 3 weeks since an email which is still waiting for a reply from him and I've just not heard anything. Not even an indication he plans to reply but is busy. I have no idea what's normal/what I should expect, but I can't even ask for clarification on that. So, at this point I've lost track. I have no idea where I am in the contribution process, none of my questions have been answered, and the only outcome I see happening right now is that this proposal is lost & forgotten. I don't know what else on the guide I can do, nor does it feel like Kevin is bothering to answer important questions, let alone review it. *I completely understand the slowness, it's an open source project after all, no less a very mature one which tries to avoid all changes to public APIs. My frustration has mainly been that I believe I've been asking questions that take little effort to reply to, but are getting ignored while I see him actively replying to other threads. Perhaps my emails are too long and contain so much detail that the questions don't immediately pop out, and thus they get missed. But at this point it feels more like I'm getting ignored for an unknown reason.* If I had some sort of confirmation that it's normal for low-priority emails to sit a bit, but that Kevin WILL eventually get to it, this would go a LONG way. But from this I've learned that I need to be extremely explicit with my questions. So here are the questions I'd like answered (Some of these I hadn't asked earlier, others have gotten lost): *1) Eg: I either want an explanation of the workflow for Metal. How I will be including vertex colors (a feature which hasn't officially been merged yet!!) in Metal, or will I wait until vertex colors are officially merged before adding support to Metal? I'm fine with either, I just want the process laid out for me.* -> I know Metal support is getting done by Oracle, but I think you guys can still provide input to this question. (I will also be asking them, if I can get contact info for them) -> The Metal Pipeline doesn't strike me as being very close to being finished, so it feels like vertex colors can be merged before them. If that is the case, I'd like to have vertex colors merged without Metal support, then at that point I can add vertex color support to Metal, as this is the clearest path that I see to avoiding conflicts between 3 different repositories. -> I see this as a very conservative approach though, and it's my proposal because I'm not familiar with JavaFX contribution workflow yet. I'd like to hear feedback from others on how they suggest I handle this. *2) Where can I get contact info for those who are working on Metal support? Looking for a lead or someone prominent.* -> I mentioned several questions regarding Metal support, but I think the best people to answer them will be the people actually working on the Metal support. So a contact should be enough. 3) Can I get some clarification on expectations for contribution? -> From the contribution guide, my understanding is that the current thing I'm waiting on is for design approval (on the feature proposal) from Kevin. -> But, I think I'm OK to seek out feedback on my PR as well, which I've recently realized already has a JBS Bug ID (or I think that's what it is? It's got an entry on at least one of the multiple web portals I've seen which track issues.) * -> 3a) How long does it generally take to get responses on low priority feature proposals? I have no reference for what to temper my expectations against, which would help me a lot. Should I expect it to take a week before Kevin weighs in? Two weeks? One month? 6 months? One year? I've seen projects with response times covering the whole spectrum, and I just don't know where to set my expectations for when it is appropriate to follow-up on an email which hasn't gotten a reply. * * -> 3b) Every single other recent active PR besides mine has had a review comment from at least one other person, including ones created after mine. How should I interpret this besides me having done something wrong? At what point should I ask for a follow-up and for people to review it if I don't hear back from anyone?* *4) How long should I expect before my OCA signature is reviewed? I submitted it around 2 weeks ago at this point, and I don't think it's been reviewed yet, which is significantly longer than the website stated it would take.* * -> We're also beyond the timeframe that the JFX repository said it would take.* * -> Also, nobody has commented on my PR to run the expected commands whereas other PRs uploaded later have ~25 comments. Why is this? Is it due to low priority? Is it due to the 3D rendering system having fewer people working on it?* *5) **Why does the Direct3D 3D pipeline appear to use fixed vertex buffer definitions in the D3D calls, as opposed to making a more modern vertex buffer definition?* -> The 2D pipeline uses the more modern vertex buffer definitions, but the 3D pipeline uses an FVF definition, which means many non-texCoord values are marked as texCoords in the shaders. (I don't know if that's necessary, but it seems weird to me). -> My best guess for this is there was some kind of compatibility consideration, but I haven't been able to find any information on it. Does anyone (maybe you) know why it's done as an FVF declaration instead of a vertex declaration? *6) Why was your PR for #1281 not labelled as a draft PR or WIP? If I follow the contribution guidelines, I think it should be labelled as a draft? Hoping for some clarification.* *7) Do you mind sending out a reply to the original thread so I am able to reply to it instead of violating the contribution guidelines? Thanks!* * -> *What I was hoping for PR #1281 was that since I joined the mailing list recently, while I can read the previous emails in the archive, I have no way to reply to pre-existing threads, as they're not in my inbox. I'd have to start a new email thread which the contributing guidelines say explicitly not to do. *8) Where am I currently in the contribution guide? What is the next steps? What is expected from me?* *9) What is some reasonable criteria for me to use.* * -> 9a) If I send out a proposal for design discussion, how long should I wait from the last email before sending it to Kevin* * -> 9b) If I send out a feature proposal to Kevin for approval, how long should I wait before following up with Kevin if I don't hear back?* * -> 9c) If I send out a PR/Draft PR, how long after receiving no feedback should I wait before following up?* Thanks again! I really appreciate JavaFX contributors and I want to make it clear that I'm not taking any of this for granted. I just am very confused and feel like the documentation has left me in a situation where I'm just utterly confused and don't know what's going on, and haven't been getting my questions answered. In retrospect, I definitely didn't make these questions anywhere near clear enough, so I can understand why they were missed. So ideally this email can serve as both a way for me to clear up my confusion, but also to improve the experience for future contributors who can be spun around by having a mismatch between their expectations from the contribution guide and the demonstrated behavior of contributors up to the project lead Kevin. I want to be fully clear again that I'm not trying to argue or start a war, just neutrally explain my perspective, and express the desire to work with everyone to get everything sorted. I look forward to your feedback when you have a chance to review the PR. On Thu, Sep 12, 2024 at 6:08?AM Nir Lisker wrote: > By the way, regarding Metal, I don't know what state it's in. The work is > done only by Oracle, so they will have to answer that (probably Kevin). The > work is ongoing in the jfx sandbox: > https://github.com/openjdk/jfx-sandbox/tree/master. > > I didn't see questions other than that. Did I miss them? > > On Thu, Sep 12, 2024 at 3:59?PM Nir Lisker wrote: > >> Do you mind taking a look, and maybe helping answer some of my questions? >>> I'm just not getting any replies, so I'm somewhat confused. >>> >> >> I'll try to take a closer look during the weekend. There are a lot of >> issues in my queue that I can't find the time to get to. Also be patient >> with the replies, it takes time to get to an issue because there are many >> ideas/drafts and not a lot of people. >> >> The #1281 PR was closed due to inactivity. The next step there is to do a >> review of potential settings to add and check if it makes sense to add both >> sampler states and render states to the same class. See >> https://github.com/openjdk/jfx/pull/1281#discussion_r1412368579. >> >> You can see all the threads in the mailing list archive: >> http://mail.openjdk.java.net/pipermail/openjfx-dev/. >> >> On Tue, Sep 10, 2024 at 4:22?AM Knee Snap wrote: >> >>> @Nir Lisker Do you mind taking a look, and maybe >>> helping answer some of my questions? I'm just not getting any replies, so >>> I'm somewhat confused. >>> >>> ALSO, unrelated, I'm hoping to pick up the PR you dropped before: >>> https://github.com/openjdk/jfx/pull/1281 >>> What would be the process for me taking over your PR? I don't have >>> access to the original RFR email thread or feature proposal as I only >>> recently joined the mailing list. >>> >>> Thanks! >>> >>> On Fri, Sep 6, 2024 at 4:32?PM Knee Snap wrote: >>> >>>> Hi all, while waiting on Kevin to review the feature proposal (if I >>>> understand the process correctly), I have created a draft PR if anyone >>>> wants to have a look. It's not clear to me if we should be discussing >>>> implementation yet, the guide seems to contradict itself at points. But I >>>> think since we seem to have no further design discussion points we're okay >>>> to talk about implementation? >>>> >>>> Draft PR: https://github.com/openjdk/jfx/pull/1557 >>>> >>>> >>>> On Thu, Sep 5, 2024 at 9:08?PM Knee Snap wrote: >>>> >>>>> Thanks everyone who has commented and given feedback. >>>>> >>>>> With no further discussion points brought up, I'd like to move this >>>>> proposal along for review, and hopefully CSR creation. >>>>> >>>>> Is there anything I need to do besides say I'm ready to move forward? @Kevin >>>>> Rushforth >>>>> >>>>> >>>>> >>>>> On Wed, Sep 4, 2024, 12:24?PM Knee Snap wrote: >>>>> >>>>>> I don't know what gamma refers to in the context of vertex colors, >>>>>> sorry. >>>>>> >>>>>> It's not using the gamma color space if that's the question (but >>>>>> neither is the rest of JavaFX 3D). >>>>>> >>>>>> If gamma is meant as opacity, then setting the alpha color value will >>>>>> control opacity. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Sep 4, 2024, 7:44?AM Andy Goryachev < >>>>>> andy.goryachev at oracle.com> wrote: >>>>>> >>>>>>> I am not a 3D expert; one question: how is the gamma value set for >>>>>>> color interpolation? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -andy >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From: *openjfx-dev on behalf of >>>>>>> Knee Snap >>>>>>> *Date: *Tuesday, September 3, 2024 at 23:53 >>>>>>> *To: *openjfx-dev at openjdk.org >>>>>>> *Subject: *[Feature Proposal]: TriangleMesh - Vertex Color Support >>>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is a continuation of a previous email thread: "[Feature >>>>>>> Proposal] Vertex Colors on TriangleMesh". >>>>>>> >>>>>>> I'm creating a new email thread because after discussion I've put >>>>>>> together a feature proposal, and it serves largely as a summary of the >>>>>>> previous email thread. (Better organized as a feature proposal) >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Feature Proposal:* >>>>>>> https://github.com/Kneesnap/misc-public/blob/main/documents/javafx/feature-proposals/vertex-colors/proposal.md >>>>>>> >>>>>>> I had previously discussed a draft PR, but considering how simple >>>>>>> the proposed public API additions are to discuss, I don't think it's >>>>>>> actually that helpful. >>>>>>> >>>>>>> >>>>>>> >>>>>>> *What's next?* >>>>>>> >>>>>>> I'm currently happy with the design and seeing as it's been >>>>>>> discussed already, I could probably ask Kevin for a review. But, I'd like >>>>>>> to give another opportunity for design discussion before doing so, just >>>>>>> in-case there are any further considerations brought up. >>>>>>> >>>>>>> So, I open up the floor again. Does anyone have any thoughts on this >>>>>>> proposal? Concerns? Questions? Suggestions? Constructive criticism? I >>>>>>> eagerly await the feedback. >>>>>>> >>>>>>> >>>>>>> >>>>>>> After API discussion concludes, I plan to pass it off to Kevin for >>>>>>> review/approval, and if it is approved, the subsequent CSR creation. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Fri Sep 13 03:44:20 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 13 Sep 2024 03:44:20 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 01:41:24 GMT, Nir Lisker wrote: > But the docs specify the interpolation type. Changing it will not be backwards compatible. The docs only specify the interpolation type, but not the transition type. If users need a discrete transition, they can always use a step easing function. It would be unusual to transition images with a `linear` easing function (seeing as that will as of now not result in a linear transition), so I think the amount of surprise will be limited if, at some point in the future, a `-fx-background-image` transition with a `linear` function will start to smoothly fade between images. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2347974594 From michaelstrau2 at gmail.com Fri Sep 13 04:22:42 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 13 Sep 2024 06:22:42 +0200 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: Just a comment about the culture of the OpenJFX project, which you seem to be struggling with: >From my experience, this project is usually quite democratic in its processes. The features and enhancements that successfully make it into JFX start with a discussion on the mailing list. This is where you gather buy-in from other developers (if no one is interested in your proposed enhancement, you're in a tough spot). Don't worry too much about formal processes, it's about community support at this stage. Get other people to be excited about your enhancement, and hopefully some will find the time to look at the design and your implementation. Some proposals build up inertia and move forward, others end up dying due to a lack of interest. 3D graphics in JavaFX is a bit of a niche feature (and vertex colors is even more niche), which is probably why the response to your proposal is a bit slow. That being said, I'll take a closer look at your proposal during the weekend. On Fri, Sep 13, 2024 at 4:59?AM Knee Snap wrote: > > Thanks Nir! No worries about being busy, my concern was when I didn't get replies to my questions about what I should be doing and procedural questions. But, it seems maybe I wasn't super clear about my questions since you aren't sure what they were. > I also went through many days waiting for responses about expectations all while he was replying quickly to other emails, seemingly ignoring mine. I'm not suggesting he's done anything wrong, I can imagine perfectly good reasons for not having replied, but my questions were related to the contribution guidelines and expectations. So I've felt like I've been going foward without clear expectations of both myself and contributors, and like I wasn't even guaranteed a response at all. The only reference I had for how long I should expect to wait was based on the other emails I saw, which had fast replies. I'm hoping to clarify my responsibilities and expectations, and what I should expect from contributors, since there's a lot of stuff to get familiar with in the contribution guide, and it's my first time contributing. Due to that, it felt like those questions went mostly ignored and it wasn't a matter of being busy, as other emails were getting quick replies, though perhaps I didn't phrase them clearly. Hoping to now clear up my confusions about responsibilities. Your email has helped reassure me that I was not getting ignored, but instead just had a lower priority or something else that could cause it to take longer to get a reply. > > Overall, I'd like to give some insight into what it has felt like for me to contribute to JavaFX for my first time. The contribution guide is good, but it hasn't been enough. > This isn't here to point blame or to criticize, but instead give some perspective into my experience here and why this has been such a frustrating experience. Perhaps this will help improve the contribution experience for newcomers like me going forward keeping this in mind, but ideally it'll help set the stage for why I am so confused and help you guys resolve my confusions. > -> The contribution guide misled me in many ways here, and there are many questions I still do not have an answer to. > -> To start off, it said to include a feature proposal, and it gave suggestions for various things to include. > -> So, I wrote a long feature proposal email and sent it off. For a week I had a discussion with a contributor where we hashed out different design choices, I felt like we had appropriately discussed everything which had been discussed adequately, and was ready to get my feature proposal approved by Kevin. > -> Everything was going great until one week in when Kevin replied and said he "would need to be convinced that multiple applications would benefit from such a feature, and that your proposed solution -- as documented and exposed by the public API -- is the best way to go." > -> He also asked if I had read the contribution guide, implying he didn't think what I had previously sent wasn't me 1:1 following the contribution guide. > -> I still don't understand why he sent that, I believe I presented exactly what the contribution guide wanted. There were a handful of things that got missed, but each were discussed in the email thread. > -> Did he not read the proposal and assume I did it wrong? Did he read it and think it wasn't convincing? Did he want a new proposal which included the things which had been discussed in the email thread? > -> So, with this confusion I asked for clarification as well as other questions relating to Metal like who was working on it, if I could have a contact for them, etc. > -> Never got a reply! Okay, so what the heck am I supposed to do here? Kevin asked for new a feature proposal, and I guess for some inexplicable reason this one wasn't good enough? It doesn't seem like he even realized this was a feature proposal, but either way, he asked for a new one, so I'll make a new one. > -> After looking at other feature proposals, I retooled my proposal and come up with something I was happy with, which I felt went above/beyond what was necessary. I've even prototyped an implementation which works that I can use to get a screenshot for the proposal, and to ensure my opinions of the design didn't change even after seeing it in practice. > -> During this time Kevin even helped me sort out an issue building JavaFX, so here I am thinking that I've been given the green light to present a final feature proposal with all of my changes, and Kevin will review it. > -> So, after finalizing a new proposal, I'm feeling good. I've expanded the proposal significantly, and it's now in a Git repository, which is what other contributors have been doing. > -> I'd like to give everyone a chance to review the updated proposal, who knows maybe there could be something I missed. Then, I'll pass it off to Kevin. > -> There's some discussion and Kevin even chimes in at one point. After a few days when there's no more discussion, I send out an email saying I'm reading to pass it off to Kevin for review. > -> Then, I don't get a reply. After a little bit, I start to get very concerned since I see him actively replying to other emails, and he's still never touched the original email I sent asking him for clarification, and follow-up questions. > -> At this point it's been almost 3 weeks since his confusing email, and I still have no clarification, and I've spent quite a lot of effort on this. The questions from before have come back. Did he even read my initial feature proposal? What if all this time he had just not read the original one? I've got 3 weeks since an email which is still waiting for a reply from him and I've just not heard anything. Not even an indication he plans to reply but is busy. I have no idea what's normal/what I should expect, but I can't even ask for clarification on that. > > So, at this point I've lost track. I have no idea where I am in the contribution process, none of my questions have been answered, and the only outcome I see happening right now is that this proposal is lost & forgotten. > I don't know what else on the guide I can do, nor does it feel like Kevin is bothering to answer important questions, let alone review it. > I completely understand the slowness, it's an open source project after all, no less a very mature one which tries to avoid all changes to public APIs. My frustration has mainly been that I believe I've been asking questions that take little effort to reply to, but are getting ignored while I see him actively replying to other threads. Perhaps my emails are too long and contain so much detail that the questions don't immediately pop out, and thus they get missed. But at this point it feels more like I'm getting ignored for an unknown reason. > If I had some sort of confirmation that it's normal for low-priority emails to sit a bit, but that Kevin WILL eventually get to it, this would go a LONG way. > > But from this I've learned that I need to be extremely explicit with my questions. So here are the questions I'd like answered (Some of these I hadn't asked earlier, others have gotten lost): > 1) Eg: I either want an explanation of the workflow for Metal. How I will be including vertex colors (a feature which hasn't officially been merged yet!!) in Metal, or will I wait until vertex colors are officially merged before adding support to Metal? I'm fine with either, I just want the process laid out for me. > -> I know Metal support is getting done by Oracle, but I think you guys can still provide input to this question. (I will also be asking them, if I can get contact info for them) > -> The Metal Pipeline doesn't strike me as being very close to being finished, so it feels like vertex colors can be merged before them. If that is the case, I'd like to have vertex colors merged without Metal support, then at that point I can add vertex color support to Metal, as this is the clearest path that I see to avoiding conflicts between 3 different repositories. > -> I see this as a very conservative approach though, and it's my proposal because I'm not familiar with JavaFX contribution workflow yet. I'd like to hear feedback from others on how they suggest I handle this. > 2) Where can I get contact info for those who are working on Metal support? Looking for a lead or someone prominent. > -> I mentioned several questions regarding Metal support, but I think the best people to answer them will be the people actually working on the Metal support. So a contact should be enough. > 3) Can I get some clarification on expectations for contribution? > -> From the contribution guide, my understanding is that the current thing I'm waiting on is for design approval (on the feature proposal) from Kevin. > -> But, I think I'm OK to seek out feedback on my PR as well, which I've recently realized already has a JBS Bug ID (or I think that's what it is? It's got an entry on at least one of the multiple web portals I've seen which track issues.) > -> 3a) How long does it generally take to get responses on low priority feature proposals? I have no reference for what to temper my expectations against, which would help me a lot. Should I expect it to take a week before Kevin weighs in? Two weeks? One month? 6 months? One year? I've seen projects with response times covering the whole spectrum, and I just don't know where to set my expectations for when it is appropriate to follow-up on an email which hasn't gotten a reply. > -> 3b) Every single other recent active PR besides mine has had a review comment from at least one other person, including ones created after mine. How should I interpret this besides me having done something wrong? At what point should I ask for a follow-up and for people to review it if I don't hear back from anyone? > 4) How long should I expect before my OCA signature is reviewed? I submitted it around 2 weeks ago at this point, and I don't think it's been reviewed yet, which is significantly longer than the website stated it would take. > -> We're also beyond the timeframe that the JFX repository said it would take. > -> Also, nobody has commented on my PR to run the expected commands whereas other PRs uploaded later have ~25 comments. Why is this? Is it due to low priority? Is it due to the 3D rendering system having fewer people working on it? > 5) Why does the Direct3D 3D pipeline appear to use fixed vertex buffer definitions in the D3D calls, as opposed to making a more modern vertex buffer definition? > -> The 2D pipeline uses the more modern vertex buffer definitions, but the 3D pipeline uses an FVF definition, which means many non-texCoord values are marked as texCoords in the shaders. (I don't know if that's necessary, but it seems weird to me). > -> My best guess for this is there was some kind of compatibility consideration, but I haven't been able to find any information on it. Does anyone (maybe you) know why it's done as an FVF declaration instead of a vertex declaration? > 6) Why was your PR for #1281 not labelled as a draft PR or WIP? If I follow the contribution guidelines, I think it should be labelled as a draft? Hoping for some clarification. > 7) Do you mind sending out a reply to the original thread so I am able to reply to it instead of violating the contribution guidelines? Thanks! > -> What I was hoping for PR #1281 was that since I joined the mailing list recently, while I can read the previous emails in the archive, I have no way to reply to pre-existing threads, as they're not in my inbox. I'd have to start a new email thread which the contributing guidelines say explicitly not to do. > 8) Where am I currently in the contribution guide? What is the next steps? What is expected from me? > 9) What is some reasonable criteria for me to use. > -> 9a) If I send out a proposal for design discussion, how long should I wait from the last email before sending it to Kevin > -> 9b) If I send out a feature proposal to Kevin for approval, how long should I wait before following up with Kevin if I don't hear back? > -> 9c) If I send out a PR/Draft PR, how long after receiving no feedback should I wait before following up? > > Thanks again! I really appreciate JavaFX contributors and I want to make it clear that I'm not taking any of this for granted. I just am very confused and feel like the documentation has left me in a situation where I'm just utterly confused and don't know what's going on, and haven't been getting my questions answered. > In retrospect, I definitely didn't make these questions anywhere near clear enough, so I can understand why they were missed. So ideally this email can serve as both a way for me to clear up my confusion, but also to improve the experience for future contributors who can be spun around by having a mismatch between their expectations from the contribution guide and the demonstrated behavior of contributors up to the project lead Kevin. I want to be fully clear again that I'm not trying to argue or start a war, just neutrally explain my perspective, and express the desire to work with everyone to get everything sorted. > I look forward to your feedback when you have a chance to review the PR. From kneester77 at gmail.com Fri Sep 13 07:18:53 2024 From: kneester77 at gmail.com (Knee Snap) Date: Fri, 13 Sep 2024 00:18:53 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: Gottttcha, thank you Michael, that really helps a lot. I read the contribution guide and I definitely took away the wrong thing. I expected a very bearaucratic process, so I've largely interpreted the conversations this far with that mindset. It makes a lot more sense if I consider the previous conversations as a democratic process. The 3D system being niche therefore getting less attention makes sense. I hope some of these changes can make it become less niche since I think a handful of missing features will make a very large impact on its usability/how appealing it is to different projects. Unfortunately that's pretty hard to measure, but I hope that can be made up for by showing how the rest of the 3D world support these features without fail. That won't make up for a lack of overwhelming enthusiasm, but I'm hopeful that because my planned proposals all have very mature specifications for how they work across the broader 3D world with consistent operations across pretty much all applications (except JavaFX) that it counts for something. Perhaps I should start following other conversations more closely to get a better feel on how these discussions tend to go. The bottom line is that your message has helped me reconceive how I should be thinking about this and I feel a lot more confident in my ability to be a helpful contributor from that. Thank you (and everyone else) for being so understanding, contributing to an open source project so mature/stable/widely used is a new experience for me I must say, so I really do appreciate helping me acclimate like this. It's nice to not need to accompdate business pressures/goals and just make decisions based on what provides the most utility to yourself and others. On Thu, Sep 12, 2024, 9:23?PM Michael Strau? wrote: > Just a comment about the culture of the OpenJFX project, which you > seem to be struggling with: > > From my experience, this project is usually quite democratic in its > processes. The features and enhancements that successfully make it > into JFX start with a discussion on the mailing list. This is where > you gather buy-in from other developers (if no one is interested in > your proposed enhancement, you're in a tough spot). Don't worry too > much about formal processes, it's about community support at this > stage. Get other people to be excited about your enhancement, and > hopefully some will find the time to look at the design and your > implementation. Some proposals build up inertia and move forward, > others end up dying due to a lack of interest. > > 3D graphics in JavaFX is a bit of a niche feature (and vertex colors > is even more niche), which is probably why the response to your > proposal is a bit slow. That being said, I'll take a closer look at > your proposal during the weekend. > > > > On Fri, Sep 13, 2024 at 4:59?AM Knee Snap wrote: > > > > Thanks Nir! No worries about being busy, my concern was when I didn't > get replies to my questions about what I should be doing and procedural > questions. But, it seems maybe I wasn't super clear about my questions > since you aren't sure what they were. > > I also went through many days waiting for responses about expectations > all while he was replying quickly to other emails, seemingly ignoring mine. > I'm not suggesting he's done anything wrong, I can imagine perfectly good > reasons for not having replied, but my questions were related to the > contribution guidelines and expectations. So I've felt like I've been going > foward without clear expectations of both myself and contributors, and like > I wasn't even guaranteed a response at all. The only reference I had for > how long I should expect to wait was based on the other emails I saw, which > had fast replies. I'm hoping to clarify my responsibilities and > expectations, and what I should expect from contributors, since there's a > lot of stuff to get familiar with in the contribution guide, and it's my > first time contributing. Due to that, it felt like those questions went > mostly ignored and it wasn't a matter of being busy, as other emails were > getting quick replies, though perhaps I didn't phrase them clearly. Hoping > to now clear up my confusions about responsibilities. Your email has helped > reassure me that I was not getting ignored, but instead just had a lower > priority or something else that could cause it to take longer to get a > reply. > > > > Overall, I'd like to give some insight into what it has felt like for me > to contribute to JavaFX for my first time. The contribution guide is good, > but it hasn't been enough. > > This isn't here to point blame or to criticize, but instead give some > perspective into my experience here and why this has been such a > frustrating experience. Perhaps this will help improve the contribution > experience for newcomers like me going forward keeping this in mind, but > ideally it'll help set the stage for why I am so confused and help you guys > resolve my confusions. > > -> The contribution guide misled me in many ways here, and there are > many questions I still do not have an answer to. > > -> To start off, it said to include a feature proposal, and it gave > suggestions for various things to include. > > -> So, I wrote a long feature proposal email and sent it off. For a > week I had a discussion with a contributor where we hashed out different > design choices, I felt like we had appropriately discussed everything which > had been discussed adequately, and was ready to get my feature proposal > approved by Kevin. > > -> Everything was going great until one week in when Kevin replied and > said he "would need to be convinced that multiple applications would > benefit from such a feature, and that your proposed solution -- as > documented and exposed by the public API -- is the best way to go." > > -> He also asked if I had read the contribution guide, implying he > didn't think what I had previously sent wasn't me 1:1 following the > contribution guide. > > -> I still don't understand why he sent that, I believe I presented > exactly what the contribution guide wanted. There were a handful of things > that got missed, but each were discussed in the email thread. > > -> Did he not read the proposal and assume I did it wrong? Did he read > it and think it wasn't convincing? Did he want a new proposal which > included the things which had been discussed in the email thread? > > -> So, with this confusion I asked for clarification as well as other > questions relating to Metal like who was working on it, if I could have a > contact for them, etc. > > -> Never got a reply! Okay, so what the heck am I supposed to do here? > Kevin asked for new a feature proposal, and I guess for some inexplicable > reason this one wasn't good enough? It doesn't seem like he even realized > this was a feature proposal, but either way, he asked for a new one, so > I'll make a new one. > > -> After looking at other feature proposals, I retooled my proposal and > come up with something I was happy with, which I felt went above/beyond > what was necessary. I've even prototyped an implementation which works that > I can use to get a screenshot for the proposal, and to ensure my opinions > of the design didn't change even after seeing it in practice. > > -> During this time Kevin even helped me sort out an issue building > JavaFX, so here I am thinking that I've been given the green light to > present a final feature proposal with all of my changes, and Kevin will > review it. > > -> So, after finalizing a new proposal, I'm feeling good. I've expanded > the proposal significantly, and it's now in a Git repository, which is what > other contributors have been doing. > > -> I'd like to give everyone a chance to review the updated proposal, > who knows maybe there could be something I missed. Then, I'll pass it off > to Kevin. > > -> There's some discussion and Kevin even chimes in at one point. After > a few days when there's no more discussion, I send out an email saying I'm > reading to pass it off to Kevin for review. > > -> Then, I don't get a reply. After a little bit, I start to get very > concerned since I see him actively replying to other emails, and he's still > never touched the original email I sent asking him for clarification, and > follow-up questions. > > -> At this point it's been almost 3 weeks since his confusing email, > and I still have no clarification, and I've spent quite a lot of effort on > this. The questions from before have come back. Did he even read my initial > feature proposal? What if all this time he had just not read the original > one? I've got 3 weeks since an email which is still waiting for a reply > from him and I've just not heard anything. Not even an indication he plans > to reply but is busy. I have no idea what's normal/what I should expect, > but I can't even ask for clarification on that. > > > > So, at this point I've lost track. I have no idea where I am in the > contribution process, none of my questions have been answered, and the only > outcome I see happening right now is that this proposal is lost & forgotten. > > I don't know what else on the guide I can do, nor does it feel like > Kevin is bothering to answer important questions, let alone review it. > > I completely understand the slowness, it's an open source project after > all, no less a very mature one which tries to avoid all changes to public > APIs. My frustration has mainly been that I believe I've been asking > questions that take little effort to reply to, but are getting ignored > while I see him actively replying to other threads. Perhaps my emails are > too long and contain so much detail that the questions don't immediately > pop out, and thus they get missed. But at this point it feels more like I'm > getting ignored for an unknown reason. > > If I had some sort of confirmation that it's normal for low-priority > emails to sit a bit, but that Kevin WILL eventually get to it, this would > go a LONG way. > > > > But from this I've learned that I need to be extremely explicit with my > questions. So here are the questions I'd like answered (Some of these I > hadn't asked earlier, others have gotten lost): > > 1) Eg: I either want an explanation of the workflow for Metal. How I > will be including vertex colors (a feature which hasn't officially been > merged yet!!) in Metal, or will I wait until vertex colors are officially > merged before adding support to Metal? I'm fine with either, I just want > the process laid out for me. > > -> I know Metal support is getting done by Oracle, but I think you guys > can still provide input to this question. (I will also be asking them, if I > can get contact info for them) > > -> The Metal Pipeline doesn't strike me as being very close to being > finished, so it feels like vertex colors can be merged before them. If that > is the case, I'd like to have vertex colors merged without Metal support, > then at that point I can add vertex color support to Metal, as this is the > clearest path that I see to avoiding conflicts between 3 different > repositories. > > -> I see this as a very conservative approach though, and it's my > proposal because I'm not familiar with JavaFX contribution workflow yet. > I'd like to hear feedback from others on how they suggest I handle this. > > 2) Where can I get contact info for those who are working on Metal > support? Looking for a lead or someone prominent. > > -> I mentioned several questions regarding Metal support, but I think > the best people to answer them will be the people actually working on the > Metal support. So a contact should be enough. > > 3) Can I get some clarification on expectations for contribution? > > -> From the contribution guide, my understanding is that the current > thing I'm waiting on is for design approval (on the feature proposal) from > Kevin. > > -> But, I think I'm OK to seek out feedback on my PR as well, which > I've recently realized already has a JBS Bug ID (or I think that's what it > is? It's got an entry on at least one of the multiple web portals I've seen > which track issues.) > > -> 3a) How long does it generally take to get responses on low priority > feature proposals? I have no reference for what to temper my expectations > against, which would help me a lot. Should I expect it to take a week > before Kevin weighs in? Two weeks? One month? 6 months? One year? I've seen > projects with response times covering the whole spectrum, and I just don't > know where to set my expectations for when it is appropriate to follow-up > on an email which hasn't gotten a reply. > > -> 3b) Every single other recent active PR besides mine has had a > review comment from at least one other person, including ones created after > mine. How should I interpret this besides me having done something wrong? > At what point should I ask for a follow-up and for people to review it if I > don't hear back from anyone? > > 4) How long should I expect before my OCA signature is reviewed? I > submitted it around 2 weeks ago at this point, and I don't think it's been > reviewed yet, which is significantly longer than the website stated it > would take. > > -> We're also beyond the timeframe that the JFX repository said it > would take. > > -> Also, nobody has commented on my PR to run the expected commands > whereas other PRs uploaded later have ~25 comments. Why is this? Is it due > to low priority? Is it due to the 3D rendering system having fewer people > working on it? > > 5) Why does the Direct3D 3D pipeline appear to use fixed vertex buffer > definitions in the D3D calls, as opposed to making a more modern vertex > buffer definition? > > -> The 2D pipeline uses the more modern vertex buffer definitions, but > the 3D pipeline uses an FVF definition, which means many non-texCoord > values are marked as texCoords in the shaders. (I don't know if that's > necessary, but it seems weird to me). > > -> My best guess for this is there was some kind of compatibility > consideration, but I haven't been able to find any information on it. Does > anyone (maybe you) know why it's done as an FVF declaration instead of a > vertex declaration? > > 6) Why was your PR for #1281 not labelled as a draft PR or WIP? If I > follow the contribution guidelines, I think it should be labelled as a > draft? Hoping for some clarification. > > 7) Do you mind sending out a reply to the original thread so I am able > to reply to it instead of violating the contribution guidelines? Thanks! > > -> What I was hoping for PR #1281 was that since I joined the mailing > list recently, while I can read the previous emails in the archive, I have > no way to reply to pre-existing threads, as they're not in my inbox. I'd > have to start a new email thread which the contributing guidelines say > explicitly not to do. > > 8) Where am I currently in the contribution guide? What is the next > steps? What is expected from me? > > 9) What is some reasonable criteria for me to use. > > -> 9a) If I send out a proposal for design discussion, how long should > I wait from the last email before sending it to Kevin > > -> 9b) If I send out a feature proposal to Kevin for approval, how long > should I wait before following up with Kevin if I don't hear back? > > -> 9c) If I send out a PR/Draft PR, how long after receiving no > feedback should I wait before following up? > > > > Thanks again! I really appreciate JavaFX contributors and I want to make > it clear that I'm not taking any of this for granted. I just am very > confused and feel like the documentation has left me in a situation where > I'm just utterly confused and don't know what's going on, and haven't been > getting my questions answered. > > In retrospect, I definitely didn't make these questions anywhere near > clear enough, so I can understand why they were missed. So ideally this > email can serve as both a way for me to clear up my confusion, but also to > improve the experience for future contributors who can be spun around by > having a mismatch between their expectations from the contribution guide > and the demonstrated behavior of contributors up to the project lead Kevin. > I want to be fully clear again that I'm not trying to argue or start a war, > just neutrally explain my perspective, and express the desire to work with > everyone to get everything sorted. > > I look forward to your feedback when you have a chance to review the PR. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aghaisas at openjdk.org Fri Sep 13 10:50:23 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Fri, 13 Sep 2024 10:50:23 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 Message-ID: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> This converts FXML module tests to junit5. All changes are trivial API replacements from junit4 to junit5. There are no parameterized tests in this module. ------------- Commit messages: - 8339513: Convert fxml tests to JUnit 5 Changes: https://git.openjdk.org/jfx/pull/1564/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1564&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339513 Stats: 169 lines in 31 files changed: 45 ins; 16 del; 108 mod Patch: https://git.openjdk.org/jfx/pull/1564.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1564/head:pull/1564 PR: https://git.openjdk.org/jfx/pull/1564 From kcr at openjdk.org Fri Sep 13 13:09:18 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Sep 2024 13:09:18 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 In-Reply-To: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> Message-ID: On Fri, 13 Sep 2024 10:45:33 GMT, Ajit Ghaisas wrote: > This converts FXML module tests to junit5. > > All changes are trivial API replacements from junit4 to junit5. > There are no parameterized tests in this module. All looks good. I presume you verified that there are no `assertXxxx` calls with a message string? I didn't see any, and the GHA build is green. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1564#pullrequestreview-2303083363 From angorya at openjdk.org Fri Sep 13 14:52:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 14:52:14 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 In-Reply-To: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> Message-ID: On Fri, 13 Sep 2024 10:45:33 GMT, Ajit Ghaisas wrote: > This converts FXML module tests to junit5. > > All changes are trivial API replacements from junit4 to junit5. > There are no parameterized tests in this module. I might suggest fixing the formatting for readability. This is minor, will re-approve if you decide to fix it. modules/javafx.fxml/src/test/java/test/javafx/fxml/RT_19008Test.java line 37: > 35: @Test > 36: public void testMissingResource() throws IOException { > 37: assertThrows(NullPointerException.class, () -> {FXMLLoader.load(getClass().getResource("rt_19008.fxml")); minor: I would fix the formatting here (move the lambda to its own line) modules/javafx.fxml/src/test/java/test/javafx/fxml/RT_19329Test.java line 37: > 35: @Test > 36: public void testIncludeException() throws IOException { > 37: assertThrows(IOException.class, () -> { FXMLLoader.load(getClass().getResource("rt_19329.fxml")); }); minor: formatting modules/javafx.fxml/src/test/java/test/javafx/fxml/RT_25494_Cycle_DetectionTest.java line 47: > 45: @Test > 46: public void test_cycle() throws Exception { > 47: assertThrows(IOException.class, () -> {FXMLLoader.load(RT_25494_Cycle_DetectionTest.class.getResource("cycle.fxml")); }); ... and here for readability ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1564#pullrequestreview-2303335860 PR Review Comment: https://git.openjdk.org/jfx/pull/1564#discussion_r1759005526 PR Review Comment: https://git.openjdk.org/jfx/pull/1564#discussion_r1759006194 PR Review Comment: https://git.openjdk.org/jfx/pull/1564#discussion_r1759007072 From kcr at openjdk.org Fri Sep 13 14:58:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Sep 2024 14:58:23 GMT Subject: RFR: 8339550: Enable javac lint options for tests Message-ID: This PR enables the `removal` lint option, along with `-Werror`, for compiling shims and test classes. In order to do that, I had to also do the following: * Disable the `options` lint warning as is done for the `javafx.swing` module, and for the same reason: using `-source NN -release NN` produces a warning that we know about and don't care to see (and will fail the build with `-Werror`) * Change the `apiguardian` dependency from `testRuntimeOnly` to `testImplementation`, since it needs to be a compile-time dependency to avoid many compile-time warnings for a missing annotation * Add a missing `@SuppressWarnings("removal")` in one place * Fix the varargs warnings filed in [JDK-8338340](https://bugs.openjdk.org/browse/JDK-8338340) I tested locally and with our CI test system. The GHA build passes. ------------- Commit messages: - 8338340: [TestBug] fix varargs parameter type warnings - 8339550: Enable javac lint options for tests Changes: https://git.openjdk.org/jfx/pull/1565/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1565&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339550 Stats: 10 lines in 4 files changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1565.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1565/head:pull/1565 PR: https://git.openjdk.org/jfx/pull/1565 From arapte at openjdk.org Fri Sep 13 16:10:15 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 13 Sep 2024 16:10:15 GMT Subject: RFR: 8339517: Add --enable-native-access flag when running tests [v3] In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 12:51:27 GMT, Kevin Rushforth wrote: >> When running JavaFX tests and apps with JDK 24, we now get illegal access warnings of the following form: >> >> >> WARNING: A restricted method in java.lang.System has been called >> WARNING: java.lang.System::load has been called by com.sun.glass.utils.NativeLibLoader in module javafx.graphics (file:build/shims/javafx.graphics/) >> WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module >> WARNING: Restricted methods will be blocked in a future release unless native access is enabled >> >> >> With the current jfx master, I get 301 such warnings on my macOS system (see the `test.log` file attached to the JBS bug report). >> >> In order to avoid those warnings, and to avoid the eventual errors in the future, we need to pass one of the following two options when running test programs: >> >> * "java --enable-native-access=javafx.graphics,javafx.media,javafx.web" -- for unit tests in the web and systemTests subprojects, as well as in the generated `build/run.args` file >> * "java --enable-native-access=javafx.graphics" -- for all other unit tests >> >> With this patch, we are down to 5 such warnings on macOS (on Linux there are few more, but the reasons are the same). The remaining warnings are due to the following two issues: >> >> 1. We are making a native JNI call from javafx.swing, which we should not be doing. This is a JavaFX bug. The native library in question is loaded by the javafx.graphics modules, so the solution will likely be to move the native method call to somewhere in javafx.graphics and call that new method from javafx.swing. >> 2. We have two unit tests that use a custom `ModuleLayer` to load the JavaFX modules at runtime, after the test application is launched. In this case the "--enable-native-access" is ineffective. I suspect this is a JDK bug. >> >> I will file a pair of follow-on bugs for these. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Enable native access in ModuleLayer tests (using reflection until JDK 22 is the minimum) Verified that warnings disappear with this change. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1562#pullrequestreview-2303514057 From kcr at openjdk.org Fri Sep 13 17:09:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Sep 2024 17:09:17 GMT Subject: Integrated: 8339517: Add --enable-native-access flag when running tests In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 14:42:19 GMT, Kevin Rushforth wrote: > When running JavaFX tests and apps with JDK 24, we now get illegal access warnings of the following form: > > > WARNING: A restricted method in java.lang.System has been called > WARNING: java.lang.System::load has been called by com.sun.glass.utils.NativeLibLoader in module javafx.graphics (file:build/shims/javafx.graphics/) > WARNING: Use --enable-native-access=javafx.graphics to avoid a warning for callers in this module > WARNING: Restricted methods will be blocked in a future release unless native access is enabled > > > With the current jfx master, I get 301 such warnings on my macOS system (see the `test.log` file attached to the JBS bug report). > > In order to avoid those warnings, and to avoid the eventual errors in the future, we need to pass one of the following two options when running test programs: > > * "java --enable-native-access=javafx.graphics,javafx.media,javafx.web" -- for unit tests in the web and systemTests subprojects, as well as in the generated `build/run.args` file > * "java --enable-native-access=javafx.graphics" -- for all other unit tests > > With this patch, we are down to 5 such warnings on macOS (on Linux there are few more, but the reasons are the same). The remaining warnings are due to the following two issues: > > 1. We are making a native JNI call from javafx.swing, which we should not be doing. This is a JavaFX bug. The native library in question is loaded by the javafx.graphics modules, so the solution will likely be to move the native method call to somewhere in javafx.graphics and call that new method from javafx.swing. > 2. We have two unit tests that use a custom `ModuleLayer` to load the JavaFX modules at runtime, after the test application is launched. In this case the "--enable-native-access" is ineffective. I suspect this is a JDK bug. > > I will file a pair of follow-on bugs for these. This pull request has now been integrated. Changeset: 4f1d42af Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/4f1d42af38ba494bf083ca3647f9b285f1886cbd Stats: 59 lines in 5 files changed: 52 ins; 0 del; 7 mod 8339517: Add --enable-native-access flag when running tests Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1562 From angorya at openjdk.org Fri Sep 13 18:27:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 18:27:21 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 Message-ID: Converting control module tests to junit5. Most of the changes are trivial, except for the following: 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) 2. parameterized tests: junit5 allows for parameterizing individual tests 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` ### Parameterized Class-Level Tests junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. To summarize: - remove `@Before` from the setup method - call the setup method from each parameterized method (adding parameters and replacing `@Test` with @ParameterizedTest @MethodSource("parameters") where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: private static Stream parameters() { return Stream.of( Arguments.of("a", 1), Arguments.of("foo", 3) ); } ### Migration Tricks Here are the steps that might speed up the process: 1. remove all the junit4 imports 2. paste the following junit5 imports (below) 3. fix the errors 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) 7. after all is done, verify that there is no more junit4 names by running the command mentioned below junit5 imports (in no particular order): import org.junit.jupiter.api.AfterEach; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.Test; import org.junit.jupiter.api.Disabled; import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.MethodSource; import org.junit.jupiter.params.provider.Arguments; import static org.junit.jupiter.api.Assertions.assertEquals; import static org.junit.jupiter.api.Assertions.assertFalse; import static org.junit.jupiter.api.Assertions.assertNotNull; import static org.junit.jupiter.api.Assertions.assertNull; import static org.junit.jupiter.api.Assertions.assertSame; import static org.junit.jupiter.api.Assertions.assertNotSame; import static org.junit.jupiter.api.Assertions.assertTrue; import static org.junit.jupiter.api.Assertions.fail; import static org.junit.jupiter.api.Assertions.assertThrows; import static org.junit.jupiter.api.Assertions.assertArrayEquals; import static org.junit.jupiter.api.Assertions.assertTimeout; import static org.junit.jupiter.api.Assertions.assertNotEquals; import org.junit.jupiter.api.Assumptions; import org.junit.jupiter.api.BeforeAll; import org.junit.jupiter.api.AfterAll; import org.junit.jupiter.params.provider.Arguments; The following command verifies that there is no junit4 imports and inline fully qualified names: grep -lre 'org.junit.[^j][^u][^p][^i][^t][^e][^r]' . (A regex provided by @lukostyra `grep -lre 'org.junit.(?!jupiter)' .` did not work for some reason.) ### Acceptance Criteria Aside from the standard review process, I think the following criteria should be sufficient: - successful GHA (Github Actions) run on all platforms - the same number of tests executed (number of tests minus number of ignored tests) - grep shows no hits for junit4 imports ------------- Commit messages: - part 12, 9274 - 185 = 9089 - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - part 11, 9242 tests, 185 ignored - part 10 - part 9 cell - part 8 - part 7 - part 6 - part 5 charts - part 4 - ... and 4 more: https://git.openjdk.org/jfx/compare/4f1d42af...5e942478 Changes: https://git.openjdk.org/jfx/pull/1561/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1561&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338468 Stats: 9672 lines in 212 files changed: 3426 ins; 1855 del; 4391 mod Patch: https://git.openjdk.org/jfx/pull/1561.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1561/head:pull/1561 PR: https://git.openjdk.org/jfx/pull/1561 From mhanl at openjdk.org Fri Sep 13 18:27:21 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 13 Sep 2024 18:27:21 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: Message-ID: <9bnWpwSzbNBJDnTjT5BfssU0-kg1_M-9AX0HQBx12Aw=.4590cb09-406e-4078-a318-1762b704b67e@github.com> On Tue, 10 Sep 2024 18:25:40 GMT, Andy Goryachev wrote: > Converting control module tests to junit5. > > Most of the changes are trivial, except for the following: > > 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) > 2. parameterized tests: junit5 allows for parameterizing individual tests > 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) > 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes > 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` > > ### Parameterized Class-Level Tests > > junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) > > The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. > > To summarize: > - remove `@Before` from the setup method > - call the setup method from each parameterized method (adding parameters and replacing `@Test` with > > @ParameterizedTest > @MethodSource("parameters") > > where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: > > private static Stream parameters() { > return Stream.of( > Arguments.of("a", 1), > Arguments.of("foo", 3) > ); > } > > > ### Migration Tricks > > Here are the steps that might speed up the process: > > 1. remove all the junit4 imports > 2. paste the following junit5 imports (below) > 3. fix the errors > 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) > 7. after all is done, verify that there is no more junit4 names by running the command mentioned below > > junit5 imports (in no particular order): > > import org.junit.jupiter.api.AfterEach; > import org.junit.jupiter.api.BeforeEach; > import org.junit.jupiter.api.Test; > import org.junit.jupiter.api.Disabled; > import org.junit.jupiter.params.ParameterizedTest; > import org.junit.jupiter.params.provider.MethodSource; > import org.junit.jupiter.params.provider.Arguments; > import static org.junit.jupiter.api.Assertions.assertEquals; > import static org.junit.jupiter.api.Assertions.assertFalse; > import static org.junit.jupiter.api.Asser... `@MethodSource`, `@ValueSource` or `@EnumSource` are the best replacements for parameterized tests. But whatever option you choose, it is a bit of refactoring involved indeed. I would suggest to do the parameterized tests in a new ticket, after converting the 'easy' cases to JUnit5 for that particular module/package. I can also help on that if desired since I also think this is a good idea and logical step for the future of our tests (and all tests that will be written in the future of course). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2342288625 From angorya at openjdk.org Fri Sep 13 18:27:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 18:27:21 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: <9bnWpwSzbNBJDnTjT5BfssU0-kg1_M-9AX0HQBx12Aw=.4590cb09-406e-4078-a318-1762b704b67e@github.com> References: <9bnWpwSzbNBJDnTjT5BfssU0-kg1_M-9AX0HQBx12Aw=.4590cb09-406e-4078-a318-1762b704b67e@github.com> Message-ID: On Tue, 10 Sep 2024 22:40:35 GMT, Marius Hanl wrote: >> Converting control module tests to junit5. >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupiter.api.Test; >> import org.junit.jupiter.api.Disabled; >> import org.junit.jupiter.params.ParameterizedTest; >> import org.junit.jupiter.params.provider.MethodSource; >> import org.junit.jupiter.params.provider.Arguments; >> import static org.junit.jupiter.api.Assertions.assertEqu... > > `@MethodSource`, `@ValueSource` or `@EnumSource` are the best replacements for parameterized tests. But whatever option you choose, it is a bit of refactoring involved indeed. I would suggest to do the parameterized tests in a new ticket, after converting the 'easy' cases to JUnit5 for that particular module/package. > > I can also help on that if desired since I also think this is a good idea and logical step for the future of our tests (and all tests that will be written in the future of course). Thank you @Maran23 ! It's pretty surprising that junit people thought it will be a good idea to drop support for class-wide parameterized tests... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2342317644 From mhanl at openjdk.org Fri Sep 13 18:27:21 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 13 Sep 2024 18:27:21 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: <9bnWpwSzbNBJDnTjT5BfssU0-kg1_M-9AX0HQBx12Aw=.4590cb09-406e-4078-a318-1762b704b67e@github.com> Message-ID: On Tue, 10 Sep 2024 23:11:12 GMT, Andy Goryachev wrote: > It's pretty surprising that junit people thought it will be a good idea to drop support for class-wide parameterized tests... Well, I would rephrase it: - In Junit4, you were very restricted how to write parameterized tests. You always need to do on a new class + class level annotation + configuration - In Junit5, you can do it with the different Source annotations, which enable more flexibility as you don't need a separate class with and all the configuration attached to it. The Parameters are now essentially MethodSources, and nothing more is needed other than to mark the Test as ParameterizedTest So I would not compare it directly but rather say it is a new, better and more flexible way to write them. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2342336612 From angorya at openjdk.org Fri Sep 13 18:27:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 18:27:21 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: <9bnWpwSzbNBJDnTjT5BfssU0-kg1_M-9AX0HQBx12Aw=.4590cb09-406e-4078-a318-1762b704b67e@github.com> Message-ID: <9j4UViPl60jWMo2aL7hCWRerp6GnwQU33yDHlyNpqkA=.c0ac7903-c61b-4434-b305-17ce8dd33135@github.com> On Tue, 10 Sep 2024 23:32:31 GMT, Marius Hanl wrote: > I would rephrase it: To clarify, the main problem introduced by the decision not to support class-level parameterization is backward compatibility (our use case). The issue is that in many tests we have, the `@Before` and sometimes `@After` methods are also effectively parameterized. Yes, one can bring a bunch of extra files (see https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but one still has to modify all the existing `@Test`s with the parameters, basically negating the possible savings. Keeping backward compatibility should have been a priority. `/rant` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2343912547 From angorya at openjdk.org Fri Sep 13 18:31:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 18:31:11 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 18:25:40 GMT, Andy Goryachev wrote: > Converting control module tests to junit5. > > Most of the changes are trivial, except for the following: > > 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) > 2. parameterized tests: junit5 allows for parameterizing individual tests > 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) > 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes > 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` > > ### Parameterized Class-Level Tests > > junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) > > The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. > > To summarize: > - remove `@Before` from the setup method > - call the setup method from each parameterized method (adding parameters and replacing `@Test` with > > @ParameterizedTest > @MethodSource("parameters") > > where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: > > private static Stream parameters() { > return Stream.of( > Arguments.of("a", 1), > Arguments.of("foo", 3) > ); > } > > > ### Migration Tricks > > Here are the steps that might speed up the process: > > 1. remove all the junit4 imports > 2. paste the following junit5 imports (below) > 3. fix the errors > 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) > 7. after all is done, verify that there is no more junit4 names by running the command mentioned below > > junit5 imports (in no particular order): > > import org.junit.jupiter.api.AfterEach; > import org.junit.jupiter.api.BeforeEach; > import org.junit.jupiter.api.Test; > import org.junit.jupiter.api.Disabled; > import org.junit.jupiter.params.ParameterizedTest; > import org.junit.jupiter.params.provider.MethodSource; > import org.junit.jupiter.params.provider.Arguments; > import static org.junit.jupiter.api.Assertions.assertEquals; > import static org.junit.jupiter.api.Assertions.assertFalse; > import static org.junit.jupiter.api.Asser... For reviewers: it might be easier to review commit-by-commit, just keep in mind that in several places I had to go back to fix things (just check the final version). @aghaisas and/or @lukostyra could you be the reviewers please? @Maran23 I can't ask you to do a (full) review, but if you could do a spot check, I'd appreciate! thank you all in advance! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2349808258 From angorya at openjdk.org Fri Sep 13 18:40:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 18:40:12 GMT Subject: RFR: 8339550: Enable javac lint options for tests In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 14:52:22 GMT, Kevin Rushforth wrote: > This PR enables the `removal` lint option, along with `-Werror`, for compiling shims and test classes. In order to do that, I had to also do the following: > > * Disable the `options` lint warning as is done for the `javafx.swing` module, and for the same reason: using `-source NN -release NN` produces a warning that we know about and don't care to see (and will fail the build with `-Werror`) > * Change the `apiguardian` dependency from `testRuntimeOnly` to `testImplementation`, since it needs to be a compile-time dependency to avoid many compile-time warnings for a missing annotation > * Add a missing `@SuppressWarnings("removal")` in one place > * Fix the varargs warnings filed in [JDK-8338340](https://bugs.openjdk.org/browse/JDK-8338340) > > I tested locally and with our CI test system. The GHA build passes. The build fails with inexact types in varargs as expected. Now I can finally enable this warning in Eclipse. Nice work, thank you! ![Screenshot 2024-09-13 at 11 35 32](https://github.com/user-attachments/assets/2840b2d4-feea-458b-a087-34692a9b46bb) ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1565#pullrequestreview-2303818392 From angorya at openjdk.org Fri Sep 13 19:02:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 19:02:13 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 In-Reply-To: <-Hga2Og1agRuHsoe1NsmVR1aBVORi4lrWf1IKnImTdo=.0c23f583-5f0f-4e31-8067-82dcd7a46e28@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> <-Hga2Og1agRuHsoe1NsmVR1aBVORi4lrWf1IKnImTdo=.0c23f583-5f0f-4e31-8067-82dcd7a46e28@github.com> Message-ID: <3RhCwbBpA9XCPw6Y-k3GlZvQoop_Dy4ls7Mq2lqUILo=.121e47b2-08b3-42ad-8d63-a2a6f90446c5@github.com> On Thu, 12 Sep 2024 11:11:32 GMT, Ambarish Rapte wrote: >> Further additions to the MonkeyTester application: >> >> - tree/table view column property sheets ? >> - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? >> - properties... context menu ? >> - context menu: table columns, toolbar items ? >> - control.context menu option >> - property monitor tool ? >> - accessibility logging ? >> >> - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) >> - Page -> Snapped Split Panes menu option for the control container >> >> This PR simply syncs up with the dev repository >> https://github.com/andy-goryachev-oracle/MonkeyTest > > tests/manual/monkey/src/com/oracle/tools/fx/monkey/util/WritingSystemsDemo.java line 2: > >> 1: /* >> 2: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. > > Looks like unintended change. could be reverted. good catch, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1560#discussion_r1759339935 From angorya at openjdk.org Fri Sep 13 19:35:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 19:35:26 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 [v2] In-Reply-To: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: > Further additions to the MonkeyTester application: > > - tree/table view column property sheets ? > - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? > - properties... context menu ? > - context menu: table columns, toolbar items ? > - control.context menu option > - property monitor tool ? > - accessibility logging ? > > - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) > - Page -> Snapped Split Panes menu option for the control container > > This PR simply syncs up with the dev repository > https://github.com/andy-goryachev-oracle/MonkeyTest Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into 8328828.monkey - whitespace - 8328828: Monkey Tester Application Part 4 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1560/files - new: https://git.openjdk.org/jfx/pull/1560/files/9de2dfd7..0aee6d12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1560&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1560&range=00-01 Stats: 2190 lines in 26 files changed: 1120 ins; 1022 del; 48 mod Patch: https://git.openjdk.org/jfx/pull/1560.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1560/head:pull/1560 PR: https://git.openjdk.org/jfx/pull/1560 From angorya at openjdk.org Fri Sep 13 19:35:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 19:35:26 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 In-Reply-To: <-Hga2Og1agRuHsoe1NsmVR1aBVORi4lrWf1IKnImTdo=.0c23f583-5f0f-4e31-8067-82dcd7a46e28@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> <-Hga2Og1agRuHsoe1NsmVR1aBVORi4lrWf1IKnImTdo=.0c23f583-5f0f-4e31-8067-82dcd7a46e28@github.com> Message-ID: On Thu, 12 Sep 2024 11:09:49 GMT, Ambarish Rapte wrote: >> Further additions to the MonkeyTester application: >> >> - tree/table view column property sheets ? >> - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? >> - properties... context menu ? >> - context menu: table columns, toolbar items ? >> - control.context menu option >> - property monitor tool ? >> - accessibility logging ? >> >> - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) >> - Page -> Snapped Split Panes menu option for the control container >> >> This PR simply syncs up with the dev repository >> https://github.com/andy-goryachev-oracle/MonkeyTest > > Providing a few comments observed when running MonkeyTester app. > > 1. Z transformations Scale Z / Translate Z can be avoided for 2D controls / shapes > 2. TreeTableView height is fixed. It always shows 1 row. Changes in TreeTableView->Root does not have any effect. Height of TTV could vary with the number of rows. > 3. Button: Button does not receive ENTER key press event when set as default button.
      > 3.1 Check default button.
      > 3.2 Move focus on button by clicking on it >
      3.3 Press ENTER key
      > => button does not show pressed effect. Press space button, button shows pressed effect. > 4. ChoiceBox/ColorPicker/MenuBar background cannot be set back to the default. Changing back the background to has no effect > 5. No pages were getting rendered after following NPE was observed with RadioButton sample:
      Attaching the user preferences file with which issue can be reproduced [ui-settings.properties.zip](https://github.com/user-attachments/files/16978042/ui-settings.properties.zip)
      > Start MonkeyTester app with the provided user preferences file and navigate to RadioButton page
      => NPE should be observed on terminal and page does not render any controls. Navigating to other pages also does not render any controls > > > Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "javafx.geometry.Pos.getHpos()" because the return value of "javafx.scene.control.RadioButton.getAlignment()" is null > at javafx.controls at 24-internal/javafx.scene.control.skin.RadioButtonSkin.layoutChildren(RadioButtonSkin.java:136) > at javafx.controls at 24-internal/javafx.scene.control.Control.layoutChildren(Control.java:612) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1208) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.java:1215) > at javafx.graphics at 24-internal/javafx.scene.Parent.layout(Parent.... @arapte thank you for testing! > 1. Z transformations Scale Z / Translate Z can be avoided for 2D controls / shapes I'd rather keep them, might be useful for testing (i.e. to ensure there is no change when setting these properties in 2D) > * TreeTableView height is fixed. It always shows 1 row. Changes in TreeTableView->Root does not have any effect. Height of TTV could vary with the number of rows. You probably need to make sure the "Root:" has a number of items, and click the root node to expand. I did notice one thing though: setting the Background and the Fixed Cell Size 33.4 results in a weird rendering (probably because of the fractional cell size). Not sure if it's a bug though: ![Screenshot 2024-09-13 at 12 11 55](https://github.com/user-attachments/assets/67483347-dfba-4371-98ca-5f6441f4bb21) > * Button: Button does not receive ENTER key press event when set as default button. My understanding is that a default button creates an accelerator at the Scene level, so the button rendering is unaffected when ENTER is pressed. Try Window -> Open Modal Window and hit ENTER. No change. > * ChoiceBox/ColorPicker/MenuBar background cannot be set back to the default. Changing back the background to has no effect I am not sure why this is happening - possibly the interaction with the skin. Setting background back to null does not resurrect the skin's visuals, neither setting a new skin with Skin -> Set New Skin. Only re-creating the control by switching to a different page and back does the trick. This could be a P5 product bug, possibly. > * No pages were getting rendered after following NPE was observed with RadioButton sample So this is either a product bug or a case of incomplete documentation. I've raised this issue before (see https://bugs.openjdk.org/browse/JDK-8334883), but basically some properties allow for null values and some do not. The documentation is unclear. In this particular case, we might have encountered a product bug: even though the code in Labeled:190 shows some attempt to deal with null property instance, it fails when the property _value_ is null: public final Pos getAlignment() { return alignment == null ? Pos.CENTER_LEFT : alignment.get(); } so we need to either: - throw NPE when setting a null value - fix the getter to handle null value as some valid value - consider documenting whether nulls are allowed in various javafx properties In any case, these are product issues and not the MT issue. In fact, the MT serves its purpose of uncovering product issues, so thank you! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1560#issuecomment-2350016125 From angorya at openjdk.org Fri Sep 13 19:35:26 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 19:35:26 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 In-Reply-To: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: <8VCrn-9ylZ-8VkqcYySXxD0N55U0dKCTtl3N3rpgQeI=.eea44b95-d4f9-40b3-bfe7-e12d905fe92d@github.com> On Mon, 9 Sep 2024 19:36:29 GMT, Andy Goryachev wrote: > Further additions to the MonkeyTester application: > > - tree/table view column property sheets ? > - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? > - properties... context menu ? > - context menu: table columns, toolbar items ? > - control.context menu option > - property monitor tool ? > - accessibility logging ? > > - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) > - Page -> Snapped Split Panes menu option for the control container > > This PR simply syncs up with the dev repository > https://github.com/andy-goryachev-oracle/MonkeyTest Just a note: removing the `io-settings.properties` file is a legitimate approach. it is *very* difficult to create a full-proof solution that will be backward and forward compatible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1560#issuecomment-2350018452 From angorya at openjdk.org Fri Sep 13 20:15:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 20:15:13 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v4] In-Reply-To: <-MDyv6QoViXBw0Qi6XjKyaa9eNoxLP5-ZyvRcQ8NEiU=.0b7b1231-0a68-456f-b190-b8b70601d247@github.com> References: <-MDyv6QoViXBw0Qi6XjKyaa9eNoxLP5-ZyvRcQ8NEiU=.0b7b1231-0a68-456f-b190-b8b70601d247@github.com> Message-ID: On Tue, 10 Sep 2024 20:22:43 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 f... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Improve test > - 8218745: TableView: visual glitch at borders on horizontal scrolling Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1462#pullrequestreview-2304035756 From kcr at openjdk.org Fri Sep 13 20:57:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Sep 2024 20:57:13 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: Message-ID: <5tEA2xhX-RYYZmDpIU7tcPDLSF5nCjHwo_lLhf8wErA=.82156460-1310-47e7-9e17-28e85dea4e49@github.com> On Mon, 9 Sep 2024 16:15:22 GMT, Andy Goryachev wrote: > > This method seems redundant: `fromInlineStyle(style)` and `fromStyles(style)` are equivalent. Do we need both? > > These are not the same. > > `fromInlineStyle(String)` accepts as single string containing fx-style CSS with one more more styles. Example: `"-fx-fill:red; -fx-font-size:200%;"` > > `fromStyles(String style, String ... names)` is more generic, allows for setting the inline style as well as CSS stylesheet names. My point was that `fromStyles` with an empty list of names should do exactly the same thing as `fromInlineStyle`. Looking at the code that does appear to be the case (and if not, I would wonder _why_ not). So, do we really need `fromInlineStyle`? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2350153718 From angorya at openjdk.org Fri Sep 13 20:59:08 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 20:59:08 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024 17:18:58 GMT, Michael Strau? wrote: >> Thank you @mstr2 for a detailed writeup! >> >> I fully agree with you that the majority of use cases can be handled with the existing policies. >> >> The default one seems to be geometry-based ("directional") _where supported_, and the other being a "logical" one which is not explicitly accessible. The question, therefore, is do we need a static getter for that kind of a policy? (I'd say no since the logical order depends on a particular control). >> >> A couple of points: >> >> 1. setting via CSS is not a goal (I probably should mention this in the JEP) >> 2. the 4-item enumeration is not complete. For example, application may specify some other, or even dynamic, order of traversal, which would require a custom policy. >> >> Another question is whether there exists a policy that cannot be implemented by the new APIs provided by this PR. >> >> What do you think? > >> The default one seems to be geometry-based ("directional") _where supported_, and the other being a "logical" one which is not explicitly accessible. The question, therefore, is do we need a static getter for that kind of a policy? (I'd say no since the logical order depends on a particular control). > > I don't quite understand what you mean by "not explicitly accessible". Both categories are exposed with the `TraversalDirection` enum: `UP`, `DOWN`, `LEFT`, and `RIGHT` are the directional modes, whereas `NEXT`, `NEXT_IN_LINE`, and `PREVIOUS` are the logical modes. > > I think that disentangling those two categories, and having a set of predefined traversal policies that can be set independently for both of those, will be good enough for 99% of cases. The reason I'm bringing this up is that `Algorithm` (now `TraversalPolicy`) is too low-level to be useful for most application developers. _We_ should be implementing those algorithms, and then allow developers to compose them as they see fit. > > When I look at the existing code, I see quite a lot of bespoke `Algorithm` implementations. For example, `ToolBarSkin` has almost 100 lines of code dedicated to a custom implementation. However, when I just remove this implementation entirely, I get _almost_ the exact same focus traversal behavior, even in complicated scenarios like when a toolbar item is itself a focus-traversable container. > > This suggests to me that we shouldn't encourage the proliferation of even more bespoke implementations, but make it easier to compose well-tested existing algorithms. > >> >> A couple of points: >> >> 1. setting via CSS is not a goal (I probably should mention this in the JEP) >> 2. the 4-item enumeration is not complete. For example, application may specify some other, or even dynamic, order of traversal, which would require a custom policy. > > We can add scenarios to this list if it is not complete, and then see if we still need the option to create a custom traversal algorithm. My point is that the API should be tailored to be simple and useful in 99% of cases, and then maybe have an additional extension point for the rest. Right now, you're proposing to expose the lowest-level API which requires developers to reason about the scene graph and find individual nodes, which I think should be reconsidered. > > When I look at various JBS issues and browse StackOverflow, I notice that most developers are only looking for pretty simple things like cyclic traversal in a container. It's probably p... Thank you @mstr2 for your comments! Since we also have a parallel discussion in the mailing list, I'll respond there. I think we both agree that the main goal of this proposal (or any proposal) is to make _the things_ easier in the most common scenarios, while making all other scenarios possible. Right now it is simply not possible to do focus traversal on the application side. This proposal makes focus traversal and custom policies possible. You are right that in most cases the default policy would be sufficient, and we also might provide additional standard policies (like one based on an array of Nodes within a Parent), and that should cover 99% of the use cases. One thought I'd like to vocalize: the idea of setting traversal properties or policies from CSS does not feel right to me. The CSS define presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2350160842 From angorya at openjdk.org Fri Sep 13 21:06:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 21:06:11 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: <5tEA2xhX-RYYZmDpIU7tcPDLSF5nCjHwo_lLhf8wErA=.82156460-1310-47e7-9e17-28e85dea4e49@github.com> References: <5tEA2xhX-RYYZmDpIU7tcPDLSF5nCjHwo_lLhf8wErA=.82156460-1310-47e7-9e17-28e85dea4e49@github.com> Message-ID: On Fri, 13 Sep 2024 20:54:12 GMT, Kevin Rushforth wrote: > So, do we really need `fromInlineStyle`? Now I understand the question! A bit of history: I had a single method before that accepted `(String style, String ... names)`. Turns out it was a trap: it's easy to forget about it and simply supply a list of style names, which results in the first style name being interpreted as an inline style (and cause an error message). Since I fell into this trap myself, I thought it would be better to have two methods with descriptive names. Is there a better solution? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2350190960 From kcr at openjdk.org Fri Sep 13 21:24:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Sep 2024 21:24:09 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: <5tEA2xhX-RYYZmDpIU7tcPDLSF5nCjHwo_lLhf8wErA=.82156460-1310-47e7-9e17-28e85dea4e49@github.com> Message-ID: On Fri, 13 Sep 2024 21:03:05 GMT, Andy Goryachev wrote: > I had a single method before that accepted `(String style, String ... names)`. Turns out it was a trap: it's easy to forget about it and simply supply a list of style names, which results in the first style name being interpreted as an inline style (and cause an error message). Yeah, that's always a potential problem with a method like this where there is a single argument before the varargs list of the same type as the varargs list. > Since I fell into this trap myself, I thought it would be better to have two methods with descriptive names. > > Is there a better solution? I can't immediately think of one. At least you might add a note to the `fromInlineStyle` docs that it is equivalent to `fromStyles(style)`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2350258805 From angorya at openjdk.org Fri Sep 13 21:24:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 21:24:09 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: <5tEA2xhX-RYYZmDpIU7tcPDLSF5nCjHwo_lLhf8wErA=.82156460-1310-47e7-9e17-28e85dea4e49@github.com> Message-ID: On Fri, 13 Sep 2024 21:19:54 GMT, Kevin Rushforth wrote: > `fromInlineStyle` docs that it is equivalent to `fromStyles(style)`. good point, thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2350266648 From angorya at openjdk.org Fri Sep 13 21:35:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 21:35:43 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v10] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - hide impl. detail - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - removed duplicate files - moved to apps, review comments - bsd license for sample code - fixes and review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - improved vertical scrolling - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - cleanup - ... and 7 more: https://git.openjdk.org/jfx/compare/8c2ef65c...1aafab27 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/9a984533..1aafab27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=08-09 Stats: 2313 lines in 28 files changed: 1180 ins; 1083 del; 50 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From andy.goryachev at oracle.com Fri Sep 13 22:17:41 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 13 Sep 2024 22:17:41 +0000 Subject: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: Dear John, Everyone: Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: 1. move the focus traversal logic away from the components and into the Scene 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents 3. (more) standard policies 4. using CSS (there is of course more topics in your response, but let me start with the 4 above) #1 I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? #2 This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. #3 One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. #4 The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. -- There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. So I would like to ask the following two questions: - are there requirements that will be still impossible to deliver with this proposal and how important they are? - is there anything in this proposal that will make some important feature impossible? What do you think? Thank you, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, September 11, 2024 at 19:05 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Focus Traversal API Hi Andy / List, I've given this some thought first, without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ## KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: - OPEN This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: Node from = ... switch (((KeyEvent)event).getCode()) { case UP: FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); event.consume(); break; case DOWN: // or use the convenience method FocusTraversal.traverseDown(from); event.consume(); break; } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: Node from = ... Node result = switch(traversalEvent.getEventType()) { case TraversalEvent.UP -> FocusTraversals.findUp(from); case TraversalEvent.DOWN -> FocusTraversals.findDown(from); // etc } if (result != null) { result.requestFocus(); traversalEvent.consume(); } Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Sep 13 22:27:19 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Sep 2024 22:27:19 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v10] In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 21:35:43 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - hide impl. detail > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - removed duplicate files > - moved to apps, review comments > - bsd license for sample code > - fixes and review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - improved vertical scrolling > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - cleanup > - ... and 7 more: https://git.openjdk.org/jfx/compare/f7fe32a1...1aafab27 A few more comments on the `RichTextArea` class. The following directories should be refactored / renamed from `rich` to `richtext` (the one in `doc-files` is causing the images to not show up in the generated docs) modules/jfx.incubator.richtext/ build/classes/java/test/test/com/sun/jfx/incubator/scene/control/rich/ src/main/docs/jfx/incubator/scene/control/rich/ src/test/java/test/com/sun/jfx/incubator/scene/control/rich/ modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 154: > 152: *

> 153: * > 154: * @author Andy Goryachev I recommend adding `@see StyledTextModel`. Btw, we don't typically use the `@author` tag. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 314: > 312: /** > 313: * Creates the instance with the in-memory model {@link RichTextModel}. > 314: */ I recommend adding `@defaultValue` modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 367: > 365: *

> 366: * Note: > 367: * {@code StyledTextModel.selectionProperty()}, {@link #anchorPositionProperty()}, and {@link #caretPositionProperty()} Typo: `StyledTextModel.selectionProperty` --> `selectionProperty` (it is a property of _this_ class, not the model) modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 437: > 435: *

> 436: * Note: > 437: * {@code StyledTextModel.selectionProperty()}, {@link #anchorPositionProperty()}, and {@link #caretPositionProperty()} `StyledTextModel.selectionProperty` --> `selectionProperty` modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 735: > 733: *

> 734: * Note: > 735: * {@code StyledTextModel.selectionProperty()}, {@link #anchorPositionProperty()}, and {@link #caretPositionProperty()} `StyledTextModel.selectionProperty` --> `selectionProperty` ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2304200371 PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2350512541 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1759550704 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1759561651 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1759547329 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1759547688 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1759547868 From angorya at openjdk.org Fri Sep 13 22:40:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 22:40:14 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: <-p3qrpSExozs9TdScY15h9Z5aBRyBRyj8F12HPMY0YI=.0152f739-8b8d-4295-a9eb-3ddf7ec7c402@github.com> On Tue, 10 Sep 2024 16:21:30 GMT, Kevin Rushforth wrote: >> Public APIs for focus traversal and the focus traversal policy: >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md >> >> This work is loosely based on the patch >> https://cr.openjdk.org/~jgiles/8061673/ > > modules/javafx.graphics/src/main/java/javafx/scene/Parent.java line 850: > >> 848: /** >> 849: * The {@link TraversalPolicy} to be used by this Parent to provide assistance to the >> 850: * JavaFX focus traversal subsystem. > > What assistance does this policy provide? When is it used? re-phrased ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1759585761 From angorya at openjdk.org Fri Sep 13 22:50:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 22:50:10 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 16:26:17 GMT, Kevin Rushforth wrote: >> Public APIs for focus traversal and the focus traversal policy: >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md >> >> This work is loosely based on the patch >> https://cr.openjdk.org/~jgiles/8061673/ > > modules/javafx.graphics/src/main/java/javafx/scene/traversal/FocusTraversal.java line 34: > >> 32: >> 33: /** >> 34: * Provides the mechanism for focus traversal in the JavaFX application. > > I'd like to see additional documentation here describing focus traversal. more info added > modules/javafx.graphics/src/main/java/javafx/scene/traversal/FocusTraversal.java line 40: > >> 38: public final class FocusTraversal { >> 39: /** >> 40: * Traverses focus to the adjacent node as specified by the direction. > > What does it do if the `node` to traverse from is not the currently focused node? > > How does traversal differ if the method is `KEY` vs `DEFAULT`? this is explained in `TraversalMethod` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1759591189 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1759591036 From angorya at openjdk.org Fri Sep 13 23:02:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 23:02:16 GMT Subject: RFR: 8090456: Focus Management In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 16:42:22 GMT, Kevin Rushforth wrote: >> Public APIs for focus traversal and the focus traversal policy: >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md >> >> This work is loosely based on the patch >> https://cr.openjdk.org/~jgiles/8061673/ > > modules/javafx.graphics/src/main/java/javafx/scene/traversal/TraversalPolicy.java line 51: > >> 49: * @since 999 TODO >> 50: */ >> 51: public abstract class TraversalPolicy { > > Who subclasses this? And for what purpose? This should be documented in the class docs. added clarifications. not sure what to say beyond "The base class for any algorithm that determines focus traversal between elements in the JavaFX scene graph." > modules/javafx.graphics/src/main/java/javafx/scene/traversal/TraversalPolicy.java line 63: > >> 61: *

    >> 62: *
  1. Find the nearest parent of the "owner" that is handled by this TraversalPolicy (i.e. it's a direct child of the root). >> 63: *
  2. select the next node within this direct child using the context.selectInSubtree() and return it > > I'm going to need a second pass to understand what this does, but one thing that jumps out at me: what is "context" ? and what is the "selectInSubtree" method? I see no such method in the public API, so this description is not comprehensible (nor suitable for public documentation). fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1759596385 PR Review Comment: https://git.openjdk.org/jfx/pull/1555#discussion_r1759596532 From angorya at openjdk.org Fri Sep 13 23:13:10 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Sep 2024 23:13:10 GMT Subject: RFR: 8090456: Focus Management [v2] In-Reply-To: References: Message-ID: > Public APIs for focus traversal and the focus traversal policy: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > This work is loosely based on the patch > https://cr.openjdk.org/~jgiles/8061673/ Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into 8090456.focus.traversal - review comments part 1 - Merge remote-tracking branch 'origin/master' into 8090456.focus.traversal - Merge remote-tracking branch 'origin/master' into 8090456.focus.traversal - whitespace - 8090456: focus traversal ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1555/files - new: https://git.openjdk.org/jfx/pull/1555/files/4f168952..ddd3b281 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=00-01 Stats: 2245 lines in 32 files changed: 1137 ins; 1022 del; 86 mod Patch: https://git.openjdk.org/jfx/pull/1555.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1555/head:pull/1555 PR: https://git.openjdk.org/jfx/pull/1555 From nlisker at openjdk.org Sat Sep 14 06:10:19 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 14 Sep 2024 06:10:19 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Sun, 8 Sep 2024 20:55:53 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > small doc changes, copyright header I went over the API and some of the implementation, looks good. One sore thumb I saw were the private constructors with the `ignored` parameter to avoid name clash. I think there could have been a better way to do that, but since it's in the implementation I won't get into it here. modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 54: > 52: * Two lists are combined by pairwise interpolation. If the start list has fewer elements than > 53: * the target list, the missing elements are copied from the target list. If the start list has > 54: * more elements than the target list, the excess elements are discarded. Are the elements within the lists interpolated as well? For example, if one list is `[red, blue]` and the other is `[green]`, then `blue` is discarded as excess, but will `red` be linearly interpolated to `green`? modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 73: > 71: * to 1 (inclusive). > 72: *

    > 73: * The returned value may not be a new instance; the implementation might also return one of the "might not be a new instance". "may not" can mean that it's disallowed. modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 109: > 107: public TransitionEvent(EventType eventType, > 108: StyleableProperty property, > 109: String propertyName, Does this break backwards compatibility? modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 292: > 290: private Background(List fills, List images, int ignored) { > 291: Objects.requireNonNull(fills, "fills cannot be null"); > 292: Objects.requireNonNull(images, "images cannot be null"); Are these reached if there is an interpolation from/to null with a non-null? ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2300363858 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1756900815 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759655761 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1756906715 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759665107 From mstrauss at openjdk.org Sat Sep 14 06:52:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 14 Sep 2024 06:52:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: <4rqts06pUy5VcVdPfkrmBOCGNRJbFuHtR1jqZFLTyew=.20923d8b-f9a8-4c99-94c6-9ca90ae94041@github.com> On Thu, 12 Sep 2024 13:41:53 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> small doc changes, copyright header > > modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 54: > >> 52: * Two lists are combined by pairwise interpolation. If the start list has fewer elements than >> 53: * the target list, the missing elements are copied from the target list. If the start list has >> 54: * more elements than the target list, the excess elements are discarded. > > Are the elements within the lists interpolated as well? For example, if one list is `[red, blue]` and the other is `[green]`, then `blue` is discarded as excess, but will `red` be linearly interpolated to `green`? > > I understand that this specs is for the list itself, but in practice the list can contain interpolatable elements, so it might be clearer to say what happens with them. Yes, in your example, `red` will be linearly interpolated with `green`. That's what I intended to say with "pairwise interpolation": you pair up elements of both lists, and then for each pair, you apply the interpolation rules as described. I don't understand what you mean that the spec "is for the list itself". ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759682578 From mstrauss at openjdk.org Sat Sep 14 06:57:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 14 Sep 2024 06:57:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 13:45:04 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> small doc changes, copyright header > > modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 109: > >> 107: public TransitionEvent(EventType eventType, >> 108: StyleableProperty property, >> 109: String propertyName, > > Does this break backwards compatibility? Sure, but I don't really mind: 1. `TransitionEvent` is a CSS event, it can not usefully be created by application developers. 2. This API (without `propertyName`) will be introduced with JFX 23, so developers will need to hurry if they intend to misuse it until JFX 24 rolls around... I wouldn't mind removing the public constructor altogether, but this is not something that we usually do for JavaFX events. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759683190 From mstrauss at openjdk.org Sat Sep 14 07:05:57 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 14 Sep 2024 07:05:57 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v37] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/f9187a1d..c9cf1392 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=36 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=35-36 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Sat Sep 14 07:05:59 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 14 Sep 2024 07:05:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Sat, 14 Sep 2024 04:36:09 GMT, Nir Lisker wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> small doc changes, copyright header > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 292: > >> 290: private Background(List fills, List images, int ignored) { >> 291: Objects.requireNonNull(fills, "fills cannot be null"); >> 292: Objects.requireNonNull(images, "images cannot be null"); > > Are these reached if there is an interpolation from/to null with a non-null? Interpolation with `null` is not possible: `Interpolatable.interpolate(T, double)` is specified to throw NPE when `null` is passed in. When a styleable property transitions from a null value to a non-null value, it always transitions as discrete (i.e. is switches at the 50% mark) and doesn't use `Interpolatable.interpolate`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759683672 From nlisker at openjdk.org Sat Sep 14 07:05:59 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 14 Sep 2024 07:05:59 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: <3H8yC96ReHNfJ3wdUCI0bONR_kba5PkyMg97V0EdnLM=.254adf4e-f59a-44ee-80ab-213796067172@github.com> On Sat, 14 Sep 2024 06:58:04 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 292: >> >>> 290: private Background(List fills, List images, int ignored) { >>> 291: Objects.requireNonNull(fills, "fills cannot be null"); >>> 292: Objects.requireNonNull(images, "images cannot be null"); >> >> Are these reached if there is an interpolation from/to null with a non-null? > > Interpolation with `null` is not possible: `Interpolatable.interpolate(T, double)` is specified to throw NPE when `null` is passed in. When a styleable property transitions from a null value to a non-null value, it always transitions as discrete (i.e. is switches at the 50% mark) and doesn't use `Interpolatable.interpolate`. So when will these checks fail? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759684220 From nlisker at openjdk.org Sat Sep 14 07:11:17 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 14 Sep 2024 07:11:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: <4rqts06pUy5VcVdPfkrmBOCGNRJbFuHtR1jqZFLTyew=.20923d8b-f9a8-4c99-94c6-9ca90ae94041@github.com> References: <4rqts06pUy5VcVdPfkrmBOCGNRJbFuHtR1jqZFLTyew=.20923d8b-f9a8-4c99-94c6-9ca90ae94041@github.com> Message-ID: On Sat, 14 Sep 2024 06:49:33 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 54: >> >>> 52: * Two lists are combined by pairwise interpolation. If the start list has fewer elements than >>> 53: * the target list, the missing elements are copied from the target list. If the start list has >>> 54: * more elements than the target list, the excess elements are discarded. >> >> Are the elements within the lists interpolated as well? For example, if one list is `[red, blue]` and the other is `[green]`, then `blue` is discarded as excess, but will `red` be linearly interpolated to `green`? >> >> I understand that this specs is for the list itself, but in practice the list can contain interpolatable elements, so it might be clearer to say what happens with them. > > Yes, in your example, `red` will be linearly interpolated with `green`. > That's what I intended to say with "pairwise interpolation": you pair up elements of both lists, and then for each pair, you apply the interpolation rules as described. I don't understand what you mean that the spec "is for the list itself". Then maybe mention that paired elements are interpolated? By "this specs is for the list itself" I meant that pairwise interpolation is only relevant for the list itself and not for an element in the list (unless it's a list itself). So a question I would have as a user is what happens with the elements. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759684825 From mstrauss at openjdk.org Sat Sep 14 07:11:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 14 Sep 2024 07:11:17 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: <3H8yC96ReHNfJ3wdUCI0bONR_kba5PkyMg97V0EdnLM=.254adf4e-f59a-44ee-80ab-213796067172@github.com> References: <3H8yC96ReHNfJ3wdUCI0bONR_kba5PkyMg97V0EdnLM=.254adf4e-f59a-44ee-80ab-213796067172@github.com> Message-ID: On Sat, 14 Sep 2024 07:02:33 GMT, Nir Lisker wrote: >> Interpolation with `null` is not possible: `Interpolatable.interpolate(T, double)` is specified to throw NPE when `null` is passed in. When a styleable property transitions from a null value to a non-null value, it always transitions as discrete (i.e. is switches at the 50% mark) and doesn't use `Interpolatable.interpolate`. > > So when will these checks fail? They will never fail as currently implemented. I just added them as documentation for future maintainers. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759684905 From mstrauss at openjdk.org Sat Sep 14 07:46:51 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 14 Sep 2024 07:46:51 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v38] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/c9cf1392..1227a79f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=37 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=36-37 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From nlisker at openjdk.org Sat Sep 14 07:46:51 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 14 Sep 2024 07:46:51 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v38] In-Reply-To: References: Message-ID: On Sat, 14 Sep 2024 07:43:41 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > javadoc change Approving from the perspective of the API with the remark that there is a theoretical API break for `TransitionEvent`. ------------- Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2304400930 From mstrauss at openjdk.org Sat Sep 14 07:46:51 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 14 Sep 2024 07:46:51 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: <4rqts06pUy5VcVdPfkrmBOCGNRJbFuHtR1jqZFLTyew=.20923d8b-f9a8-4c99-94c6-9ca90ae94041@github.com> Message-ID: On Sat, 14 Sep 2024 07:08:22 GMT, Nir Lisker wrote: >> Yes, in your example, `red` will be linearly interpolated with `green`. >> That's what I intended to say with "pairwise interpolation": you pair up elements of both lists, and then for each pair, you apply the interpolation rules as described. I don't understand what you mean that the spec "is for the list itself". > > Then maybe mention that paired elements are interpolated? > By "this specs is for the list itself" I meant that pairwise interpolation is only relevant for the list itself and not for an element in the list (unless it's a list itself). So a question I would have as a user is what happens with the elements. I added another sentence, do you think this clears things up? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759688927 From nlisker at openjdk.org Sat Sep 14 07:46:51 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sat, 14 Sep 2024 07:46:51 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: <4rqts06pUy5VcVdPfkrmBOCGNRJbFuHtR1jqZFLTyew=.20923d8b-f9a8-4c99-94c6-9ca90ae94041@github.com> Message-ID: On Sat, 14 Sep 2024 07:38:38 GMT, Michael Strau? wrote: >> Then maybe mention that paired elements are interpolated? >> By "this specs is for the list itself" I meant that pairwise interpolation is only relevant for the list itself and not for an element in the list (unless it's a list itself). So a question I would have as a user is what happens with the elements. > > I added another sentence, do you think this clears things up? Yes, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1759689226 From john.hendrikx at gmail.com Sat Sep 14 16:41:29 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 14 Sep 2024 18:41:29 +0200 Subject: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: Hi Andy, First let me say that when it comes to designing an API, you really need to take the time to think the solution through.? The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API.? This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX.? Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that.? You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver.? This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX.? Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. On 14/09/2024 00:17, Andy Goryachev wrote: > > Dear John, Everyone: > > Thank you for a thoughtful response!? Some of the ideas you described > definitely deserve further consideration.? If I were to summarize: > > 1. move the focus traversal logic away from the components and into > the Scene > > 2. re-implement focus traversal through TraversalEvents rather than > responding directly to KeyEvents > > 3. (more) standard policies > > 4. using CSS > > (there is of course more topics in your response, but let me start > with the 4 above) > > #1 > > I generally like this idea.? In some sense it is already how things > work internally, but without the ability to customize that (i.e. by > introducing custom traversal keys, or removing existing ones).? The > downside is substantial: not only we'd need to re-design the whole of > the focus traversal, but also rework the existing control's > behaviors.? Did I mention the risk of regression, given the absence of > comprehensive behavioral tests? > There's two things here. 1. There is no need to re-design the whole focus traversal.? The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). 2. Regression.? When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX?? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button.? Is it a regression if FX is adjusted to also only react to the left mouse button?? It's not specified anywhere. I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. Can there be regressions versus the current (unspecified) implementation?? Sure, there can be.? Is that necessarily bad?? That depends.? If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix.? Did we break something with the new implementation?? That's always possible, but will then be fixed as soon as it is reported. > > #2 > > This may or may not be an integral part of #1.? Potentially, it allows > for injection of events by the application code, as well as simplifies > creation of complex custom controls.? The latter becomes possible with > the original proposal, so net benefit is limited to the first part, I > think. > I think TraversalEvents are quite central to making this an API that will really stand the test of time.? It leverages the existing event system, giving you all the power that comes with it.? You did not answer my question about the TraversalEvents in your design.? Why are the Events when they can't be triggered, filtered or?consumed? > > #3 > > One obvious possibility is to enable creation of a simple policy based > on a list of Nodes.? I must mention one use case that is impossible to > cover with pre-defined policy is one where navigation depends on some > state.? Such a policy must be implemented programmatically.? I think > one property should be sufficient - I am strongly against adding two > properties here. > Programmatic escapes can always be achieved by responding directly to a TraversalEvent.? I think however this should be a rare case, and standard policies should really cover almost all use cases.? It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard").? As for being "strongly against" having two properties -- that's an odd stance to take without motivating it.? It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here.? First the API, then the implementation. I do think however there is great value in having the Logical and Directional navigation split.? Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control.? For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). > #4 > > The idea of using CSS to specify traversal policy seems wrong to me: > the CSS defines the presentation aspects (styles) rather than > behavioral ones.? I know it is possible to set custom skins and the > corresponding behavior via CSS, and we know why (skins define the > appearance), but we should not go beyond that, in my opinion. > I see no problem styling such properties.? They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls.? "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more.? Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. Note: I'm not saying this needs to be there immediately.? I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically.? In "code" the only things I usually do on my controls are the following: - I define the container hierarchy (VBox, HBox, which children go where) - I set a style name - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). All the rest I don't touch, or want to touch.? Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary.? There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not?style, but only?*visual* style) or do we just expose these properties as Styleable?leveraging an existing powerful system with almost zero effort? > -- > > There is one more aspect of the problem that I think we should > consider.? The current proposal does not change the implementation in > any material way, nor does it change the behavior, thus can be done > quickly.? The benefit everyone gets from it is ability to trigger > focus traversal and to control it via custom policies.? Any other > solution will require resources and the bandwidth we currently don't > have, which means the /probability/ of it being added to FX is > virtually zero.? Let me emphasize, I am not against attempting to > discuss or implement the best possible solution, but we should be > aware of the limitations of the reality we live in. > "Quickly" and API's are incompatible with each other.? There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. This is exactly what I did.? I did not look at the implementation, although I'm aware of some of it.? I looked at how I as a user of FX am building applications, the struggles I have?with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal.? Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"?? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"?? These things should be abstracted, and preferably I should just be able to choose from common navigation standards.? And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application.? How do I do such things currently if I want to change something for all controls in my application?? I use CSS. Also I think this can be implemented gradually.? Here's a potential plan: 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents Benefit:?gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... Public API: Limited to a new Event 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now.? It can be done in a few batches. Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys Public API: none 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are Public API: none Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. 4. Expose policy property/properties?on Parent Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted.? We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like.? This is not FX's problem, and can be improved upon later. Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. Public API: new properties on Parent 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. This can be done at any stage, and can be considered completely separate.? It is IMHO a relatively low?priority need. Benefit: less work for control implementors (although they could just "copy" said code) Public API: Maybe some methods in Node, or some kind of static helper. 6. CSS styleable properties If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). Public API: Nothing in Java, but document as CSS properties --John > Thank you, > > -andy > > *From: *openjfx-dev on behalf of John > Hendrikx > *Date: *Wednesday, September 11, 2024 at 19:05 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: Proposal: Focus Traversal API > > Hi Andy / List, > > I've given this some thought first,?without looking too much at the > proposal. > > In my view, focus traversal should be implemented using events, and FX > should provide standard handling of these events controlled with > properties (potentially even CSS stylable for easy mass changing of > the default navigation policy). > > ##?KeyEvent and TraversalEvent separation > > I think the cleanest implementation would be to implement a KeyEvent > listener on Scene that takes any unused KeyEvents, checks if they're > considered navigation keys, and converts these keys to a new type of > event, the TraversalEvent. The TraversalEvent is then fired at the > original target. The TraversalEvent is structured into Directional and > Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and > NEXT/PREVIOUS. Scene is the logical place to handle this as without a > Scene there is no focus owner, and so there is no point in doing focus > traversal. > > This separation of KeyEvents into TraversalEvents achieves the following: > > - User can decide to act on **any** key, even navigation keys, without > the system interfering by consuming keys early, unexpectedly or even > consuming these keys without doing anything (sometimes keys get > consumed that don't actually change focus...).? The navigation keys > have many possible dual purposes, and robbing the user of the > opportunity to use them due to an overzealous component interpreting > them as traversal keys is very annoying.? Dual purposes include for > example cursor control in TextField/TextArea, Scrollbars, etc.? The > user should have the same control here as these FX controls have. > > - Scene is interpreting the KeyEvents, and this interpretation is now > controllable.? If I want a Toolbar (or the whole application) to react > to WASD navigation keys, then installing a KeyEvent handler at Scene > level or at any intermediate Parent level that converts WASD to > UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. > > - The separation also allows to block Focus Traversal only, without > blocking the actual Keys involved.? If I want to stop a Toolbar from > reacting to LEFT/RIGHT, but I need those keys higher up in the > hierarchy, then I'm screwed.? With the separation, the key events are > unaffected, and I can block Toolbars from reacting specifically to > traversal events only. > > ## Traversal Policy Properties on Parent > > I think FX should provide several policies out of the box, based on > common navigation patterns.? The goal here is to have policies in > place that cover all use cases in current FX provided controls.? This > will provide a good base that will cover probably all realistic work > loads that custom controls may have. The goal is not to support every > esoteric form of navigation, instead an escape hatch will be provided > in the form of disabling the standard navigation. > > In order to achieve this, I think Parent should get two new > properties, which control how it will react to Directional and Logical > navigation.? These will have default values that allow navigation to > flow from Node to Node within a Parent and from Parent to its Parent > when navigation options in a chosen direction are exhausted within a > Parent.? Custom controls like Combo boxes, Toolbars, Button groups, > etc, can change the default provided by a Parent (similar to how some > controls change the mouse transparent flag default). > > These two properties should cover all realistic needs, and IMHO should > be considered to be CSS stylable in the future to allow easy changing > of default policies of controls (ie. want all Toolbars to react > differently to navigation keys, then just style the appropriate > property for all toolbars in one go). > > Parent will use these properties to install an event handler that > reacts to TraversalEvents (not KeyEvents). This handler can be fully > disabled, or overridden (using setOnTraversalEvent). > > - logicalTraversalPolicy > - directionalTraversalPolicy > > The properties can be set with a value from a TraversalPolicy enum.? I > would suggest the following options: > > - OPEN > > This policy should be the default policy for all Parents.? It will act > and consume a given TraversalEvent only when there is a suitable > target within its hierarchy.? If there is no suitable target, or the > target would remain unchanged, the event is NOT consumed and left to > bubble up, allowing its parent(s) to act on it instead. > > - CONFINED > > This policy consumes all TraversalEvents, regardless of whether there > is something to navigate to or not.? This policy is suitable for > controls that have some kind of substructure that we don't want to > accidentally exit with either Directional or Logical navigation.? In > most cases, you only want to set one of the properties to CONFINED as > otherwise there would be no keyboard supported way to exit your > control.? This is a suitable policy for say button groups, toolbars, > comboboxes, etc. > > - CYCLIC > > Similar to CONFINED but instead of stopping navigation at the controls > logical boundaries, the navigation wraps around to the logical start.? > For example, when were positioned on the right most button in a button > group, pressing RIGHT again would navigate to the left most button. > > - IGNORED > > This is similar to the mouseTransparent property, and basically leaves > the TraversalEvent to bubble up.? This policy allows you to completely > disable directional and/or logical navigation for a control.? Useful > if you want to install your own handler (the escape hatch) but still > want to keep either the default directional or logical navigation. > > Possible other options for this enum could include a version that > consumes all TraversalEvents (BLOCK) but I don't see a use for it at > the moment.? There may also be variants of CONFINED and CYCLIC that > make an exception for cases where there is only a single choice > available.? A ButtonGroup for example may want to react differently > depending on whether it has 0, 1 or more buttons.? Whether these > should be enshrined with a custom enum value, or perhaps a flag, or > just left up to a custom implementation is something we'd need to > decide still. > > ## Use Cases > > 1) User wants to change the behavior of a control from its default to > something else (ie. a Control that is CYCLIC can be changed to OPEN or > CONFINED) > > Just call the setters with the appropriate preferred policy.? This > could be done in CSS for maximum convenience to enable a global change > of all similar controls. > > 2) User wants to act on Traversal events that the standard policy > leaves to bubble up > > Just install a Traversal event handler either on the control or on its > parent (depending on their needs).? A potential action to an unused > Traversal event could be to close a Dialog/Toast popup, or a custom > behavior like selecting the first/last item or next/previous row (ie. > if I press "RIGHT" and there is no further right item, a user could > decide to have this select the first item again in the current Row or > the first item in the **next** Row). > > 3) User wants to do crazy custom navigation > > Set both policies to?IGNORED, then install your own event handler (or > use the setOnTraversalHandler to completely override the handler).? > Now react on the Traversal events, consuming them at will and changing > focus to whatever control you desire. > > 4) User wants to change what keys are considered navigation keys > > Install event handler on Scene (or any intermediate Parent) for > KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a > corresponding Traversal event > > 5) User wants to use keys that are considered navigation keys for > their own purposes > > Just install a KeyEvent handler as usual, without having to worry that > Skins/Controls eat these events before you can get to them > > 6) User wants to stop a control from reacting to traversal events, > without filtering navigation keys completely > > With the separation of unconsumed KeyEvents into TraversalEvents, a > user can now block only the latter to achieve this goal without having > to blanket block certain KeyEvents. > > ----- > > About the Proposal: > > I think the Goals are fine as stated, although I think we differ on > what the Traversal events signify. > > I think CSS support should be considered a possible future goal.? The > proposal should therefore take into account that we may want to offer > this in the future. > > Motivation looks okay. > > > The focus traversal is provided by the FocusTraversal class which > offers static methods for traversing focus in various directions, > determined by the TraversalDirection enum. > > I think these methods don't need to be exposed with a good selection > of standard TraversalPolicy options. After all, there are only so many > ways that you can do a sensible navigation action without confusing > the user, and therefore I think these policy options will cover 99% of > the use cases already.? For the left over 1% we could **consider** > providing these focus traversal functions as a separate public API, > but I would have them return the Node they would suggest, and leave > the final decision to call requestFocus up to the caller. Initially > however I think there is already more than enough power for custom > implementations to listen to Traversal events and do their own custom > navigation.? If it is not similar to one of the standard navigation > options, the traverseUp/Down functions won't be of much use then anyway. > > About your typical example: > > ??? Node from = ... > ??? switch (((KeyEvent)event).getCode()) { > ??? case UP: > ??????? FocusTraversal.traverse(from, TraversalDirection.UP, > TraversalMethod.KEY); > ??????? event.consume(); > ??????? break; > ??? case DOWN: > ??????? // or use the convenience method > ??????? FocusTraversal.traverseDown(from); > ??????? event.consume(); > ??????? break; > ??? } > > I think this is not a good way to deal with events. > > 1) The event is consumed regardless of the outcome of traverse.? What > if focus did not change?? Should the event be consumed? > > 2) This is consuming KeyEvents directly, robbing the user of the > opportunity to act on keys considered "special" by FX. > > 3) This code is not only consuming KeyEvents directly, but also > deciding what keys are navigation keys. > > So I think this example?code should be different. However, first I > expect that in most cases, configuring a different traversal policy on > your Parent subclass will already be sufficient in almost all cases > (especially if we look at FX current controls and see if the suggested > policies would cover those use cases).? So this code will almost never > be needed.? However, in the event that you need something even more > specific, you may consider handling Traversal events directly.? In > which case the code should IMHO look something like this: > > ??? Node from = ... > > ??? Node result = switch(traversalEvent.getEventType()) { > ?? ?? case TraversalEvent.UP -> FocusTraversals.findUp(from); > ?? ?? case TraversalEvent.DOWN -> FocusTraversals.findDown(from); > ? ? ? // etc > ?? } > > ??? if (result != null) { > ???????? result.requestFocus(); > ???????? traversalEvent.consume(); > ??? } > > Note that the above code leaves the final decision to call > requestFocus up to the caller.? It also allows the caller to > distinguish between the case where there is no suitable Node in the > indicated direction and act accordingly. > > This allows it to?NOT consume the event if it prefers its Parent to > handle it (if the control doesn't want CYCLIC or CONFINED style > navigation).? It also allows it to further scrutinize the suggested > Node, and if it decides it does not like it (due to some property or > CSS style or whatever) it may follow up with another findXXX call or > some other option to pick the Node it wants.? It also allows (in the > case of no Node being found) to pick its own preferred Node in those > cases.? In other words, it is just far more flexible. > > I'm not sure yet where to place these static helper methods (if we > decide to expose them at all initially), or even if they should be > static.? Given that its first parameter is always a Node, a non-static > location for them could simply be on Node itself, in which case the > calling convention would become "Node result? = > from.findTraversableUp()" (suggested name only) > > > Focus traversals generate a new type of event, encapsulated by the > class TraversalEvent which extends javafx.event.Event, using the event > type TraversalEvent.NODE_TRAVERSED. > > What is the point of this event?? If you want to know that focus > changed, you can add a listener to Scene.focusOwnerProperty.? What > does it mean if I filter this event?? What if I consume it?? I don't > think this should be an event at all, unless implemented as I > suggested above, where consuming/filtering/bubbling can be used to > control how controls will react to navigation events. > > --John > > On 03/09/2024 21:33, Andy Goryachev wrote: > > Dear fellow developers: > > I'd like to propose the public focus traversal API: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > > Draft PR: > > https://github.com/openjdk/jfx/pull/1555 > > Your comments and suggestions will be warmly accepted and appreciated. > > Thank you > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Sat Sep 14 16:57:16 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 14 Sep 2024 16:57:16 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v38] In-Reply-To: References: Message-ID: On Sat, 14 Sep 2024 07:42:45 GMT, Nir Lisker wrote: > Approving from the perspective of the API with the remark that there is a theoretical API break for `TransitionEvent`. Thanks for the review! I added the changed `TransitionEvent` API as a compatibility risk in the CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1522#issuecomment-2351060449 From jbhaskar at openjdk.org Sun Sep 15 12:34:43 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sun, 15 Sep 2024 12:34:43 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 Message-ID: Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. ------------- Commit messages: - 8339515: [TestBug] Convert web tests to JUnit 5 Changes: https://git.openjdk.org/jfx/pull/1567/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339515 Stats: 1186 lines in 44 files changed: 128 ins; 135 del; 923 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From mhanl at openjdk.org Sun Sep 15 12:55:13 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 15 Sep 2024 12:55:13 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 In-Reply-To: References: Message-ID: On Sun, 15 Sep 2024 12:31:03 GMT, Jay Bhaskar wrote: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. There is one major issue with the parameterized test as far as I can see. Some minor style guide things, looks good otherwise! modules/javafx.web/src/test/java/test/com/sun/webkit/network/CookieTest.java line 454: > 452: } > 453: > 454: assertEquals(expected.name, actual.getName(),"Unexpected name" + s); minor: missing space after the comma -> `, ` modules/javafx.web/src/test/java/test/com/sun/webkit/network/CookieTest.java line 455: > 453: > 454: assertEquals(expected.name, actual.getName(),"Unexpected name" + s); > 455: assertEquals(expected.value, actual.getValue(),"Unexpected value" + s); minor: missing space after the comma -> `, ` modules/javafx.web/src/test/java/test/javafx/scene/web/FileReaderTest.java line 248: > 246: assertEquals(expectedLength, actualLength, message); > 247: for (int i = 0; i < expectedArrayBuffer.length; i++) { > 248: assertEquals(expectedArrayBuffer[i], ((Number)(obj.getSlot(i))).byteValue(),"Unexpected file content received"); minor: missing space after the comma -> `, ` modules/javafx.web/src/test/java/test/javafx/scene/web/LoadTest.java line 132: > 130: Element html = doc.getDocumentElement(); > 131: assertNotNull(html, "There should be an HTML element"); > 132: assertEquals("HTML", html.getTagName(),"HTML element should have tag HTML"); minor: missing space after the comma -> `, ` modules/javafx.web/src/test/java/test/javafx/scene/web/LoadTest.java line 218: > 216: WebEngine webEngine = new WebEngine(); > 217: webEngine.titleProperty().addListener((observable, oldValue, newValue) -> { > 218: assertTrue(webEngine.getLoadWorker().getState() == SUCCEEDED,"loadContent in SUCCEEDED State"); minor: missing space after the comma -> `, ` modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java line 99: > 97: @ParameterizedTest > 98: @MethodSource("dataProvider") > 99: public void testScriptTagWithCorrectHashValue() { Major: This methods need the parameters from the `MethodSource` AFAIK, that is: `testScriptTagWithCorrectHashValue(String hashValue, String expected) { .. }` The member variables should be removed then: ``` private final String hashValue = ""; private final String expected = ""; ------------- Changes requested by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1567#pullrequestreview-2305353159 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1760039063 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1760039105 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1760039605 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1760040160 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1760040230 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1760041171 From mhanl at openjdk.org Sun Sep 15 12:59:09 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 15 Sep 2024 12:59:09 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 In-Reply-To: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> Message-ID: On Fri, 13 Sep 2024 10:45:33 GMT, Ajit Ghaisas wrote: > This converts FXML module tests to junit5. > > All changes are trivial API replacements from junit4 to junit5. > There are no parameterized tests in this module. Looks good to me too, just some formatting is off (as Andy also noticed) modules/javafx.fxml/src/test/java/test/javafx/fxml/RT_18933Test.java line 38: > 36: @Test > 37: public void testDefaultListProperty() throws IOException { > 38: assertThrows(LoadException.class, () -> { FXMLLoader fxmlLoader = new FXMLLoader(getClass().getResource("rt_18933.fxml")); formatting looks off here as well, especially `assertThrows` is indented too much modules/javafx.fxml/src/test/java/test/javafx/fxml/RT_25494_Cycle_DetectionTest.java line 37: > 35: @Test > 36: public void test_dummy_cycle() throws Exception { > 37: assertThrows(IOException.class, () -> {FXMLLoader.load(RT_25494_Cycle_DetectionTest.class.getResource("dummy-cycle.fxml")); }); minor: formatting looks off modules/javafx.fxml/src/test/java/test/javafx/fxml/RT_26449Test.java line 38: > 36: @Test > 37: public void testRootNotSet() throws IOException { > 38: assertThrows(LoadException.class, () -> {FXMLLoader fxmlLoader = new FXMLLoader(getClass().getResource("rt_26449.fxml")); minor: formatting looks a bit off here ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1564#pullrequestreview-2305355800 PR Review Comment: https://git.openjdk.org/jfx/pull/1564#discussion_r1760042070 PR Review Comment: https://git.openjdk.org/jfx/pull/1564#discussion_r1760041712 PR Review Comment: https://git.openjdk.org/jfx/pull/1564#discussion_r1760041679 From mhanl at openjdk.org Sun Sep 15 13:00:12 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 15 Sep 2024 13:00:12 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 In-Reply-To: References: Message-ID: On Sun, 15 Sep 2024 12:31:03 GMT, Jay Bhaskar wrote: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Also one note: The copyright year was not updated, but this could also be done by the script afterwards I guess. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1567#issuecomment-2351582630 From mhanl at openjdk.org Sun Sep 15 13:59:19 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 15 Sep 2024 13:59:19 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 18:25:40 GMT, Andy Goryachev wrote: > Converting control module tests to junit5. > > The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ## JUnit5 Migration Notes > > Most of the changes are trivial, except for the following: > > 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) > 2. parameterized tests: junit5 allows for parameterizing individual tests > 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) > 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes > 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` > > ### Parameterized Class-Level Tests > > junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) > > The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. > > To summarize: > - remove `@Before` from the setup method > - call the setup method from each parameterized method (adding parameters and replacing `@Test` with > > @ParameterizedTest > @MethodSource("parameters") > > where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: > > private static Stream parameters() { > return Stream.of( > Arguments.of("a", 1), > Arguments.of("foo", 3) > ); > } > > > ### Migration Tricks > > Here are the steps that might speed up the process: > > 1. remove all the junit4 imports > 2. paste the following junit5 imports (below) > 3. fix the errors > 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) > 7. after all is done, verify that there is no more junit4 names by running the command mentioned below > > junit5 imports (in no particular order): > > import org.junit.jupiter.api.AfterEach; > import org.junit.jupiter.api.BeforeEach; > import org.junit.jupiter.api.Test; > import org.junit.jupiter.api.Disabled; > import org.junit.jupiter.params.ParameterizedTest; > imp... Looks good overall. Could not spot any obvious error. Left some comments regarding code style to reduce warnings or use newer/better API. modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleObservableHandlerTest.java line 129: > 127: public void testUnregistersNotRegistered(boolean useChangeListener) { > 128: IntegerProperty p = new SimpleIntegerProperty(); > 129: assertTrue(unregisterListeners(useChangeListener, p) == null); This could be `assertNull` still? modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleObservableHandlerTest.java line 135: > 133: @MethodSource("data") > 134: public void testUnregistersNull(boolean useChangeListener) { > 135: assertTrue(unregisterListeners(useChangeListener, null) == null); This could be `assertNull` still? modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleObservableHandlerTest.java line 362: > 360: > 361: /** parameters */ > 362: private static Collection data() { Minor: This could also be just a Stream of Boolean Arguments modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/behavior/AccordionBehaviorTest.java line 39: > 37: > 38: @Test > 39: public void focusGainedIsCaughtByBehavior() { Wait, is this an empty test? Why? modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirerTest.java line 203: > 201: // ------------- parameterized in not/alternative mouseEvent creation > 202: > 203: public static Collection data() { Minor: Could also be simplified with the argument stream modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberChartsTest.java line 99: > 97: @ParameterizedTest > 98: @MethodSource("parameters") > 99: public void testSeriesClearAnimated_rt_40632(Class chartClass, int nodesPerSeries) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberChartsTest.java line 106: > 104: @ParameterizedTest > 105: @MethodSource("parameters") > 106: public void testSeriesRemove(Class chartClass, int nodesPerSeries) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 63: > 61: } > 62: > 63: protected void createChart(Class chartClass, int seriesFadeOutTime, int dataFadeOutTime) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 83: > 81: @ParameterizedTest > 82: @MethodSource("parameters") > 83: public void testSeriesClearAnimatedWithoutSymbols_rt_40632(Class chartClass, int seriesFadeOutTime, int dataFadeOutTime) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 90: > 88: @ParameterizedTest > 89: @MethodSource("parameters") > 90: public void testSeriesRemoveWithoutSymbols(Class chartClass, int seriesFadeOutTime, int dataFadeOutTime) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 98: > 96: @ParameterizedTest > 97: @MethodSource("parameters") > 98: public void testSeriesRemoveWithoutSymbolsAnimated_rt_22124(Class chartClass, int seriesFadeOutTime, int dataFadeOutTime) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 119: > 117: @ParameterizedTest > 118: @MethodSource("parameters") > 119: public void testDataWithoutSymbolsAddWithAnimation_rt_39353(Class chartClass, int seriesFadeOutTime, int dataFadeOutTime) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 131: > 129: @ParameterizedTest > 130: @MethodSource("parameters") > 131: public void testSeriesClearWithoutSymbolsAnimated_8150264(Class chartClass, int seriesFadeOutTime, int dataFadeOutTime) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/chart/XYNumberLineChartsTest.java line 151: > 149: @ParameterizedTest > 150: @MethodSource("parameters") > 151: public void testMinorTicksMatchMajorTicksAfterAnimation(Class chartClass, int seriesFadeOutTime, int dataFadeOutTime) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/control/AcceleratorParameterizedTest.java line 75: > 73: private KeyEventFirer keyboard; > 74: > 75: private static List parameters() { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/control/CellTest.java line 76: > 74: // @BeforeEach > 75: // junit5 does not support parameterized class-level tests yet > 76: private void setup(Class type) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/control/EventAnyTest.java line 78: > 76: @ParameterizedTest > 77: @MethodSource("parameters") > 78: public void testEventDelivery(EventType type, Event event, Class target, boolean matches) throws Exception { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/control/FireButtonBaseTest.java line 48: > 46: public class FireButtonBaseTest { > 47: public static Collection parameters() { > 48: return Arrays.asList( Minor: Could also use List.of(..) modules/javafx.controls/src/test/java/test/javafx/scene/control/FireButtonBaseTest.java line 63: > 61: //@BeforeEach > 62: // junit5 does not support parameterized class-level tests yet > 63: public void setup(Class type) { Minor: `Class` modules/javafx.controls/src/test/java/test/javafx/scene/control/MultipleSelectionModelImplTest.java line 118: > 116: > 117: private static Collection> parameters() { > 118: return Arrays.asList( Minor: Could also use List.of(..) modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionFocusModelMemoryTest.java line 259: > 257: private static Collection parameters() { > 258: // show the control before replacing the selectionModel > 259: return Arrays.asList(false, true); Minor: Could also use List.of(..) modules/javafx.controls/src/test/java/test/javafx/scene/control/SelectionModelImplTest.java line 117: > 115: > 116: private static Collection> parameters() { > 117: return Arrays.asList( Minor: Could also use List.of(..) modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewHorizontalArrowsTest.java line 72: > 70: public class TableViewHorizontalArrowsTest { > 71: public static Collection parameters() { > 72: return Arrays.asList( Minor: Could also use List.of(..) modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 64: > 62: public class TextInputControlTest { > 63: private static Collection parameters() { > 64: return Arrays.asList( Minor: Could also use List.of(..) modules/javafx.controls/src/test/java/test/javafx/scene/control/ToolBarHorizontalArrowsTest.java line 72: > 70: public class ToolBarHorizontalArrowsTest { > 71: private static Collection parameters() { > 72: return Arrays.asList( Minor: Could also use List.of(..) modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ArrayLinkedListTest.java line 90: > 88: @Test > 89: public void testArrayLinkedList_Empty_GetResultsInArrayIndexOutOfBounds() { > 90: assertThrows(IndexOutOfBoundsException.class, () -> { good catch modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinCreationTest.java line 98: > 96: } > 97: > 98: public record Parameter( Minor: Can also imagine a name like `LabelParameter` or `LabelConfig` modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/QueryAccessibleAttributeTest.java line 50: > 48: // @BeforeEach > 49: // junit5 does not support parameterized class-level tests yet > 50: public void setup(Class nodeClass) { Minor: Since `Control` is used above, should also be used here and below as Generic. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/SkinLabeledCleanupTest.java line 86: > 84: //----------- parameterized > 85: > 86: private static Collection parameters() { Minor: `Class` ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1561#pullrequestreview-2305357236 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760043185 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760043199 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760043466 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760043562 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760044016 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760044770 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760044814 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760044835 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760044967 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760044988 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760045000 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760045045 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760045057 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760045069 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760045091 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760045314 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760046599 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760048634 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760046666 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760048539 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760048473 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760048405 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760048203 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760049380 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760049638 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760051126 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760051466 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760052040 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1760052590 From jbhaskar at openjdk.org Sun Sep 15 23:59:23 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sun, 15 Sep 2024 23:59:23 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: copyright year updated along with minor spcae related review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1567/files - new: https://git.openjdk.org/jfx/pull/1567/files/86f73271..27275c3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=00-01 Stats: 48 lines in 43 files changed: 0 ins; 0 del; 48 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From jbhaskar at openjdk.org Sun Sep 15 23:59:23 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sun, 15 Sep 2024 23:59:23 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Sun, 15 Sep 2024 12:50:25 GMT, Marius Hanl wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright year updated along with minor spcae related review > > modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java line 99: > >> 97: @ParameterizedTest >> 98: @MethodSource("dataProvider") >> 99: public void testScriptTagWithCorrectHashValue() { > > Major: This methods need the parameters from the `MethodSource` AFAIK, that is: > `testScriptTagWithCorrectHashValue(String hashValue, String expected) { .. }` > > The member variables should be removed then: > ``` > private final String hashValue = ""; > private final String expected = ""; In this case, keeping the values as instance variables is more reliable. Since all the tests pass when hashValue and expected are instance variables and some of them fail when I adding parameter to testScriptTagWithCorrectHashValue , it's likely that their assignment happens at the correct time relative to the @BeforeEach setup. Using parameters may interfere with the test lifecycle, since hasValue is being used in @BeforeEach public void setup() ....{} it's safer and more straightforward to use instance variables.This would also make it easier to manage the state across @BeforeEach ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1760400171 From jbhaskar at openjdk.org Mon Sep 16 00:09:38 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 00:09:38 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Jay Bhaskar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - resolve conflict - copyright year updated along with minor spcae related review - 8339515: [TestBug] Convert web tests to JUnit 5 ------------- Changes: https://git.openjdk.org/jfx/pull/1567/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=02 Stats: 1229 lines in 44 files changed: 128 ins; 135 del; 966 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From jbhaskar at openjdk.org Mon Sep 16 01:23:52 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 01:23:52 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: converting newly added tests to JUNIT5 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1567/files - new: https://git.openjdk.org/jfx/pull/1567/files/23853ba4..af58da2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=02-03 Stats: 42 lines in 2 files changed: 1 ins; 1 del; 40 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From arapte at openjdk.org Mon Sep 16 05:22:10 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 16 Sep 2024 05:22:10 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 [v2] In-Reply-To: References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: <_8cYfO9knLVi8yimmFHwqoSWlH5lyWTLMVfXonEkAh4=.99308590-c96e-4d50-8c88-e355298815cf@github.com> On Fri, 13 Sep 2024 19:35:26 GMT, Andy Goryachev wrote: >> Further additions to the MonkeyTester application: >> >> - tree/table view column property sheets ? >> - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? >> - properties... context menu ? >> - context menu: table columns, toolbar items ? >> - control.context menu option >> - property monitor tool ? >> - accessibility logging ? >> >> - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) >> - Page -> Snapped Split Panes menu option for the control container >> >> This PR simply syncs up with the dev repository >> https://github.com/andy-goryachev-oracle/MonkeyTest > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8328828.monkey > - whitespace > - 8328828: Monkey Tester Application Part 4 Few quick copyright year changes required. Shall approve once changed. tests/manual/monkey/src/com/oracle/tools/fx/monkey/settings/FxSettingsSchema.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Looks unintended, can be reverted. tests/manual/monkey/src/com/oracle/tools/fx/monkey/settings/SStream.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Looks unintended, can be reverted. tests/manual/monkey/src/com/oracle/tools/fx/monkey/tools/Native2AsciiPane.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Looks unintended, can be reverted. ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1560#pullrequestreview-2305734523 PR Review Comment: https://git.openjdk.org/jfx/pull/1560#discussion_r1760522617 PR Review Comment: https://git.openjdk.org/jfx/pull/1560#discussion_r1760522836 PR Review Comment: https://git.openjdk.org/jfx/pull/1560#discussion_r1760525928 From lkostyra at openjdk.org Mon Sep 16 09:17:44 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 16 Sep 2024 09:17:44 GMT Subject: RFR: 8339508: RenderPerf Test Application Message-ID: This PR migrates RenderPerf performance test application from jfx-sandbox metal branch: https://github.com/openjdk/jfx-sandbox/tree/metal/tests/performance/animation/RenderPerfTest/src/renderperf RenderPerf is a performance test application which draws provided number of "particles" (JFX nodes) on the screen and animates them. After some time (default 10 seconds of testing + warmup) the test automatically closes and reports FPS values. Test was developed as part of Metal backend for performance testing and we decided to integrate it with mainline for any potential further development and fixes. Command line options for the test: - `-n` - number of particles to draw, defaults to 1000 - `-t` - name of test to run, defaults to running all tests in random order. Can provide multiple tests, ex. `-t Rectangle Image` - `-d` - test duration in seconds, defaults to 10. Can be set to 0, which means the test will run infinitely long and end only when user manually closes the stage, mostly useful for stability testing. Some tests use `duke.png` image provided with this PR. This is an openly available Duke Wave image taken from https://wiki.openjdk.org/display/duke/Gallery and rescaled for test purposes. PR consists of two commits: - Base version of RenderPerfTest developed by @karthikpandelu - My commit adding `-d` flag and implementing plenty of other fixes as part of [JDK-8331570](https://bugs.openjdk.org/browse/JDK-8331570) ------------- Commit messages: - Add test duration argument and numerous other improvements - Migrate base version of RenderPerfTest Changes: https://git.openjdk.org/jfx/pull/1568/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1568&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339508 Stats: 2326 lines in 2 files changed: 2326 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1568.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1568/head:pull/1568 PR: https://git.openjdk.org/jfx/pull/1568 From lkostyra at openjdk.org Mon Sep 16 09:17:44 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 16 Sep 2024 09:17:44 GMT Subject: RFR: 8339508: RenderPerf Test Application In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 09:10:08 GMT, Lukasz Kostyra wrote: > This PR migrates RenderPerf performance test application from jfx-sandbox metal branch: https://github.com/openjdk/jfx-sandbox/tree/metal/tests/performance/animation/RenderPerfTest/src/renderperf > > RenderPerf is a performance test application which draws provided number of "particles" (JFX nodes) on the screen and animates them. After some time (default 10 seconds of testing + warmup) the test automatically closes and reports FPS values. Test was developed as part of Metal backend for performance testing and we decided to integrate it with mainline for any potential further development and fixes. > > Command line options for the test: > - `-n` - number of particles to draw, defaults to 1000 > - `-t` - name of test to run, defaults to running all tests in random order. Can provide multiple tests, ex. `-t Rectangle Image` > - `-d` - test duration in seconds, defaults to 10. Can be set to 0, which means the test will run infinitely long and end only when user manually closes the stage, mostly useful for stability testing. > > Some tests use `duke.png` image provided with this PR. This is an openly available Duke Wave image taken from https://wiki.openjdk.org/display/duke/Gallery and rescaled for test purposes. > > PR consists of two commits: > - Base version of RenderPerfTest developed by @karthikpandelu > - My commit adding `-d` flag and implementing plenty of other fixes as part of [JDK-8331570](https://bugs.openjdk.org/browse/JDK-8331570) Since this PR both migrates the base version (JDK-8339508) and adds test duration flag (JDK-8331570) I will link the latter issue as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1568#issuecomment-2352385580 From aghaisas at openjdk.org Mon Sep 16 11:04:24 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 16 Sep 2024 11:04:24 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 [v2] In-Reply-To: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> Message-ID: <2EY0HOWLxwcXgqYjf7KTxDgxZu5QrTP55HMUDstLLvw=.c287d6f3-1da9-49a2-84f7-15bf49f6c5bb@github.com> > This converts FXML module tests to junit5. > > All changes are trivial API replacements from junit4 to junit5. > There are no parameterized tests in this module. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Formatting fixes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1564/files - new: https://git.openjdk.org/jfx/pull/1564/files/40556761..e8ba9561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1564&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1564&range=00-01 Stats: 20 lines in 5 files changed: 12 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1564.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1564/head:pull/1564 PR: https://git.openjdk.org/jfx/pull/1564 From aghaisas at openjdk.org Mon Sep 16 11:04:24 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 16 Sep 2024 11:04:24 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 [v2] In-Reply-To: References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> Message-ID: On Fri, 13 Sep 2024 13:06:32 GMT, Kevin Rushforth wrote: > All looks good. I presume you verified that there are no `assertXxxx` calls with a message string? I didn't see any, and the GHA build is green. Yes. There are no `assertXxxx` calls with a message string in these tests. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1564#issuecomment-2352601412 From mhanl at openjdk.org Mon Sep 16 12:05:16 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 16 Sep 2024 12:05:16 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Sun, 15 Sep 2024 23:53:20 GMT, Jay Bhaskar wrote: >> modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java line 99: >> >>> 97: @ParameterizedTest >>> 98: @MethodSource("dataProvider") >>> 99: public void testScriptTagWithCorrectHashValue() { >> >> Major: This methods need the parameters from the `MethodSource` AFAIK, that is: >> `testScriptTagWithCorrectHashValue(String hashValue, String expected) { .. }` >> >> The member variables should be removed then: >> ``` >> private final String hashValue = ""; >> private final String expected = ""; > > In this case, keeping the values as instance variables is more reliable. Since all the tests pass when hashValue and expected are instance variables and some of them fail when I adding parameter to testScriptTagWithCorrectHashValue , > > it's likely that their assignment happens at the correct time relative to the @BeforeEach setup. Using parameters may interfere with the test lifecycle, since hasValue is being used in > @BeforeEach > public void setup() ....{} > > it's safer and more straightforward to use instance variables.This would also make it easier to manage the state across @BeforeEach I think you need to do the same as done by @andy-goryachev-oracle in his JUnit5 replacement PR: public void setup(String hashValue, String expected) throws Exception { htmlFile = new File("subresource-integrity-test.html"); ... } @ParameterizedTest @MethodSource("dataProvider") public void testScriptTagWithCorrectHashValue(String hashValue, String expected) { setup(hashValue, expected); ... } This way you dont need the instance fields, as they will be empty all the time and never assigned. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761017166 From mhanl at openjdk.org Mon Sep 16 12:06:11 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 16 Sep 2024 12:06:11 GMT Subject: RFR: 8339550: Enable javac lint options for tests In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 14:52:22 GMT, Kevin Rushforth wrote: > This PR enables the `removal` lint option, along with `-Werror`, for compiling shims and test classes. In order to do that, I had to also do the following: > > * Disable the `options` lint warning as is done for the `javafx.swing` module, and for the same reason: using `-source NN -release NN` produces a warning that we know about and don't care to see (and will fail the build with `-Werror`) > * Change the `apiguardian` dependency from `testRuntimeOnly` to `testImplementation`, since it needs to be a compile-time dependency to avoid many compile-time warnings for a missing annotation > * Add a missing `@SuppressWarnings("removal")` in one place > * Fix the varargs warnings filed in [JDK-8338340](https://bugs.openjdk.org/browse/JDK-8338340) > > I tested locally and with our CI test system. The GHA build passes. This looks like a reasonable change to ensure somewhat better code quality. +1 ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1565#pullrequestreview-2306446614 From kcr at openjdk.org Mon Sep 16 12:50:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Sep 2024 12:50:15 GMT Subject: Integrated: 8339550: Enable javac lint options for tests In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 14:52:22 GMT, Kevin Rushforth wrote: > This PR enables the `removal` lint option, along with `-Werror`, for compiling shims and test classes. In order to do that, I had to also do the following: > > * Disable the `options` lint warning as is done for the `javafx.swing` module, and for the same reason: using `-source NN -release NN` produces a warning that we know about and don't care to see (and will fail the build with `-Werror`) > * Change the `apiguardian` dependency from `testRuntimeOnly` to `testImplementation`, since it needs to be a compile-time dependency to avoid many compile-time warnings for a missing annotation > * Add a missing `@SuppressWarnings("removal")` in one place > * Fix the varargs warnings filed in [JDK-8338340](https://bugs.openjdk.org/browse/JDK-8338340) > > I tested locally and with our CI test system. The GHA build passes. This pull request has now been integrated. Changeset: 3e6a2724 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/3e6a27240abcffd500a7150a8e934918683d6173 Stats: 10 lines in 4 files changed: 3 ins; 0 del; 7 mod 8339550: Enable javac lint options for tests 8338340: [TestBug] fix varargs parameter type warnings Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1565 From kcr at openjdk.org Mon Sep 16 12:58:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Sep 2024 12:58:15 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 01:23:52 GMT, Jay Bhaskar wrote: >> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > converting newly added tests to JUNIT5 You need to revert the copyright year change, since you've mistakenly removed the start year. modules/javafx.web/src/test/java/test/com/sun/webkit/SharedBufferTest.java line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. You removed the starting copyright year, which is not OK. I recommend to revert all of the copyright changes. Then, if you prefer, you can either update it correctly to leave the starting year, or better still, leave it alone and let the script that @arapte runs periodically take care of it. ------------- PR Review: https://git.openjdk.org/jfx/pull/1567#pullrequestreview-2306563017 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761094620 From kcr at openjdk.org Mon Sep 16 13:59:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Sep 2024 13:59:12 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 [v2] In-Reply-To: <2EY0HOWLxwcXgqYjf7KTxDgxZu5QrTP55HMUDstLLvw=.c287d6f3-1da9-49a2-84f7-15bf49f6c5bb@github.com> References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> <2EY0HOWLxwcXgqYjf7KTxDgxZu5QrTP55HMUDstLLvw=.c287d6f3-1da9-49a2-84f7-15bf49f6c5bb@github.com> Message-ID: On Mon, 16 Sep 2024 11:04:24 GMT, Ajit Ghaisas wrote: >> This converts FXML module tests to junit5. >> >> All changes are trivial API replacements from junit4 to junit5. >> There are no parameterized tests in this module. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Formatting fixes Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1564#pullrequestreview-2306753590 From angorya at openjdk.org Mon Sep 16 14:22:12 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 14:22:12 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 [v2] In-Reply-To: <2EY0HOWLxwcXgqYjf7KTxDgxZu5QrTP55HMUDstLLvw=.c287d6f3-1da9-49a2-84f7-15bf49f6c5bb@github.com> References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> <2EY0HOWLxwcXgqYjf7KTxDgxZu5QrTP55HMUDstLLvw=.c287d6f3-1da9-49a2-84f7-15bf49f6c5bb@github.com> Message-ID: On Mon, 16 Sep 2024 11:04:24 GMT, Ajit Ghaisas wrote: >> This converts FXML module tests to junit5. >> >> All changes are trivial API replacements from junit4 to junit5. >> There are no parameterized tests in this module. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Formatting fixes thank you ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1564#pullrequestreview-2306827329 From mhanl at openjdk.org Mon Sep 16 14:28:09 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 16 Sep 2024 14:28:09 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 [v2] In-Reply-To: <2EY0HOWLxwcXgqYjf7KTxDgxZu5QrTP55HMUDstLLvw=.c287d6f3-1da9-49a2-84f7-15bf49f6c5bb@github.com> References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> <2EY0HOWLxwcXgqYjf7KTxDgxZu5QrTP55HMUDstLLvw=.c287d6f3-1da9-49a2-84f7-15bf49f6c5bb@github.com> Message-ID: On Mon, 16 Sep 2024 11:04:24 GMT, Ajit Ghaisas wrote: >> This converts FXML module tests to junit5. >> >> All changes are trivial API replacements from junit4 to junit5. >> There are no parameterized tests in this module. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Formatting fixes Marked as reviewed by mhanl (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1564#pullrequestreview-2306841505 From angorya at openjdk.org Mon Sep 16 14:43:20 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 14:43:20 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v38] In-Reply-To: References: Message-ID: On Sat, 14 Sep 2024 07:46:51 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > javadoc change latest changes are an improvement, thank you ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2306882542 From angorya at openjdk.org Mon Sep 16 14:57:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 14:57:14 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 12:01:41 GMT, Marius Hanl wrote: >> In this case, keeping the values as instance variables is more reliable. Since all the tests pass when hashValue and expected are instance variables and some of them fail when I adding parameter to testScriptTagWithCorrectHashValue , >> >> it's likely that their assignment happens at the correct time relative to the @BeforeEach setup. Using parameters may interfere with the test lifecycle, since hasValue is being used in >> @BeforeEach >> public void setup() ....{} >> >> it's safer and more straightforward to use instance variables.This would also make it easier to manage the state across @BeforeEach > > I think you need to do the same as done by @andy-goryachev-oracle in his JUnit5 replacement PR: > > public void setup(String hashValue, String expected) throws Exception { > htmlFile = new File("subresource-integrity-test.html"); > ... > } > > @ParameterizedTest > @MethodSource("dataProvider") > public void testScriptTagWithCorrectHashValue(String hashValue, String expected) { > setup(hashValue, expected); > ... > } > > > This way you dont need the instance fields, as they will be empty all the time and never assigned. @Maran23 is right. In the absence of support for parameterized class-level tests the easiest solution (I think) is to parameterize every `@Test`, which means: - add parameters to each method, replace `@Test` with `@ParameterizedTest` and `@MethodSource` - add parameters to setup method (`@Before`, remove the annotation) - call the setup method from each test method - remove the fields that were set in the constructor and the constructor itself Things might be a bit more complicated in the case of test class hierarchies, so additional work and checks will be needed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761320750 From angorya at openjdk.org Mon Sep 16 15:00:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 15:00:11 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 [v2] In-Reply-To: References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> <2EY0HOWLxwcXgqYjf7KTxDgxZu5QrTP55HMUDstLLvw=.c287d6f3-1da9-49a2-84f7-15bf49f6c5bb@github.com> Message-ID: <3m_4n8wiWULEz3QLPh2CHnflGwyujeuZggBWe0-T8SQ=.cb22b3d1-fe56-44c6-a0da-1d2e2af9b265@github.com> On Mon, 16 Sep 2024 13:56:09 GMT, Kevin Rushforth wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> Formatting fixes > > Marked as reviewed by kcr (Lead). @kevinrushforth : assertXXX with strings will most certainly fail during the GHA run, unless the message is exactly the same as the expected or observed parameter, in which case it is probably ok... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1564#issuecomment-2353166865 From angorya at openjdk.org Mon Sep 16 15:07:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 15:07:13 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: <9bnWpwSzbNBJDnTjT5BfssU0-kg1_M-9AX0HQBx12Aw=.4590cb09-406e-4078-a318-1762b704b67e@github.com> Message-ID: On Tue, 10 Sep 2024 23:32:31 GMT, Marius Hanl wrote: >> Thank you @Maran23 ! >> >> It's pretty surprising that junit people thought it will be a good idea to drop support for class-wide parameterized tests... > >> It's pretty surprising that junit people thought it will be a good idea to drop support for class-wide parameterized tests... > > Well, I would rephrase it: > - In Junit4, you were very restricted how to write parameterized tests. You always need to do on a new class + class level annotation + configuration > - In Junit5, you can do it with the different Source annotations, which enable more flexibility as you don't need a separate class with and all the configuration attached to it. The Parameters are now essentially MethodSources, and nothing more is needed other than to mark the Test as ParameterizedTest > > So I would not compare it directly but rather say it is a new, better and more flexible way to write them. Thank you @Maran23 for taking a look! I tried to minimize the changes, so purposely left the original code (empty tests, empty `@AfterEach` etc. intact. I'll fix the small things you pointed out; I would rather avoid making more involved structural changes now. Again, thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2353184337 From jbhaskar at openjdk.org Mon Sep 16 15:10:48 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 15:10:48 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision: - revert copyright date - Revert "copyright year updated along with minor spcae related review" This reverts commit 27275c3e06311b993e7a48eeb8616acc4cc774e8. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1567/files - new: https://git.openjdk.org/jfx/pull/1567/files/af58da2d..b1de60d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=03-04 Stats: 43 lines in 43 files changed: 0 ins; 0 del; 43 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From jbhaskar at openjdk.org Mon Sep 16 15:10:48 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 15:10:48 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 12:54:45 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> converting newly added tests to JUNIT5 > > modules/javafx.web/src/test/java/test/com/sun/webkit/SharedBufferTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. > > You removed the starting copyright year, which is not OK. I recommend to revert all of the copyright changes. Then, if you prefer, you can either update it correctly to leave the starting year, or better still, leave it alone and let the script that @arapte runs periodically take care of it. reverted copyright date change ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761340679 From kcr at openjdk.org Mon Sep 16 15:11:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Sep 2024 15:11:17 GMT Subject: RFR: 8339513: [TestBug] Convert fxml tests to JUnit 5 [v2] In-Reply-To: References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> <2EY0HOWLxwcXgqYjf7KTxDgxZu5QrTP55HMUDstLLvw=.c287d6f3-1da9-49a2-84f7-15bf49f6c5bb@github.com> Message-ID: On Mon, 16 Sep 2024 13:56:09 GMT, Kevin Rushforth wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> Formatting fixes > > Marked as reviewed by kcr (Lead). > @kevinrushforth : assertXXX with strings will most certainly fail during the GHA run, unless the message is exactly the same as the expected or observed parameter, in which case it is probably ok... Indeed, that is what would almost certainly happen. There is a (completely contrived) case where it will render the assert useless. If the message string is identical to the "expected" string (in which case, why would you bother with a message string), like this: assertEquals("some expected string", "some expected string", actualValue); then changing the above case to a JUnit 5 `assertEquals` will cause the test to always pass (the comparison will be done on the first two arguments and "actualValue" will be the message string). I admit that this is so artificial as to be not really worth worrying about. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1564#issuecomment-2353197080 From angorya at openjdk.org Mon Sep 16 15:16:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 15:16:15 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 15:10:48 GMT, Jay Bhaskar wrote: >> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. > > Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision: > > - revert copyright date > - Revert "copyright year updated along with minor spcae related review" > > This reverts commit 27275c3e06311b993e7a48eeb8616acc4cc774e8. looks like there is a merge conflict label added ------------- PR Comment: https://git.openjdk.org/jfx/pull/1567#issuecomment-2353208683 From angorya at openjdk.org Mon Sep 16 15:18:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 15:18:33 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 [v3] In-Reply-To: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: > Further additions to the MonkeyTester application: > > - tree/table view column property sheets ? > - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? > - properties... context menu ? > - context menu: table columns, toolbar items ? > - control.context menu option > - property monitor tool ? > - accessibility logging ? > > - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) > - Page -> Snapped Split Panes menu option for the control container > > This PR simply syncs up with the dev repository > https://github.com/andy-goryachev-oracle/MonkeyTest Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into 8328828.monkey - review comments - Merge remote-tracking branch 'origin/master' into 8328828.monkey - whitespace - 8328828: Monkey Tester Application Part 4 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1560/files - new: https://git.openjdk.org/jfx/pull/1560/files/0aee6d12..442ab4f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1560&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1560&range=01-02 Stats: 13 lines in 7 files changed: 3 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jfx/pull/1560.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1560/head:pull/1560 PR: https://git.openjdk.org/jfx/pull/1560 From angorya at openjdk.org Mon Sep 16 15:21:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 15:21:13 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: Message-ID: On Sun, 15 Sep 2024 13:01:49 GMT, Marius Hanl wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/LambdaMultipleObservableHandlerTest.java line 129: > >> 127: public void testUnregistersNotRegistered(boolean useChangeListener) { >> 128: IntegerProperty p = new SimpleIntegerProperty(); >> 129: assertTrue(unregisterListeners(useChangeListener, p) == null); > > This could be `assertNull` still? yes! I don't know what I was thinking... good catch! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1761362221 From angorya at openjdk.org Mon Sep 16 15:26:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 15:26:13 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: Message-ID: On Sun, 15 Sep 2024 13:03:50 GMT, Marius Hanl wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/behavior/AccordionBehaviorTest.java line 39: > >> 37: >> 38: @Test >> 39: public void focusGainedIsCaughtByBehavior() { > > Wait, is this an empty test? Why? Intentionally did not want to change the number of tests, which should be double checked during the review. Leaving as is for now. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1761370526 From jbhaskar at openjdk.org Mon Sep 16 15:35:19 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 15:35:19 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Jay Bhaskar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into testsprint - revert copyright date - Revert "copyright year updated along with minor spcae related review" This reverts commit 27275c3e06311b993e7a48eeb8616acc4cc774e8. - converting newly added tests to JUNIT5 - resolve conflict - copyright year updated along with minor spcae related review - 8339515: [TestBug] Convert web tests to JUnit 5 ------------- Changes: https://git.openjdk.org/jfx/pull/1567/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=05 Stats: 1230 lines in 46 files changed: 129 ins; 136 del; 965 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From jbhaskar at openjdk.org Mon Sep 16 15:35:19 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 15:35:19 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 14:54:43 GMT, Andy Goryachev wrote: >> I think you need to do the same as done by @andy-goryachev-oracle in his JUnit5 replacement PR: >> >> public void setup(String hashValue, String expected) throws Exception { >> htmlFile = new File("subresource-integrity-test.html"); >> ... >> } >> >> @ParameterizedTest >> @MethodSource("dataProvider") >> public void testScriptTagWithCorrectHashValue(String hashValue, String expected) { >> setup(hashValue, expected); >> ... >> } >> >> >> This way you dont need the instance fields, as they will be empty all the time and never assigned. > > @Maran23 is right. In the absence of support for parameterized class-level tests the easiest solution (I think) is to parameterize every `@Test`, which means: > - add parameters to each method, replace `@Test` with `@ParameterizedTest` and `@MethodSource` > - add parameters to setup method (`@Before`, remove the annotation) > - call the setup method from each test method > - remove the fields that were set in the constructor and the constructor itself > > Things might be a bit more complicated in the case of test class hierarchies, so additional work and checks will be needed. still some tests fail, after applying solution as suggested. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761384513 From angorya at openjdk.org Mon Sep 16 15:47:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 15:47:11 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: Message-ID: On Sun, 15 Sep 2024 13:46:14 GMT, Marius Hanl wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinCreationTest.java line 98: > >> 96: } >> 97: >> 98: public record Parameter( > > Minor: Can also imagine a name like `LabelParameter` or `LabelConfig` rather, this record should be declared private > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/QueryAccessibleAttributeTest.java line 50: > >> 48: // @BeforeEach >> 49: // junit5 does not support parameterized class-level tests yet >> 50: public void setup(Class nodeClass) { > > Minor: Since `Control` is used above, should also be used here and below as Generic. hmm, the code is technically correct since Control extends Node. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1761403946 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1761406985 From jbhaskar at openjdk.org Mon Sep 16 15:51:15 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 15:51:15 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 15:32:15 GMT, Jay Bhaskar wrote: >> @Maran23 is right. In the absence of support for parameterized class-level tests the easiest solution (I think) is to parameterize every `@Test`, which means: >> - add parameters to each method, replace `@Test` with `@ParameterizedTest` and `@MethodSource` >> - add parameters to setup method (`@Before`, remove the annotation) >> - call the setup method from each test method >> - remove the fields that were set in the constructor and the constructor itself >> >> Things might be a bit more complicated in the case of test class hierarchies, so additional work and checks will be needed. > > still some tests fail, after applying solution as suggested. When hashValue and expected are instance variables, they are initialized once per test case due to how JUnit creates a new instance of the test class for each @ParameterizedTest. This ensures that the state is clean between tests and no variable is shared between different test cases. So I think it is ok. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761413603 From arapte at openjdk.org Mon Sep 16 16:26:11 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 16 Sep 2024 16:26:11 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 15:35:19 GMT, Jay Bhaskar wrote: >> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. > > Jay Bhaskar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into testsprint > - revert copyright date > - Revert "copyright year updated along with minor spcae related review" > > This reverts commit 27275c3e06311b993e7a48eeb8616acc4cc774e8. > - converting newly added tests to JUNIT5 > - resolve conflict > - copyright year updated along with minor spcae related review > - 8339515: [TestBug] Convert web tests to JUnit 5 Suggesting a few minor changes. modules/javafx.web/src/test/java/test/javafx/scene/web/FormControlsTest.java line 43: > 41: import org.junit.jupiter.api.extension.ExtendWith; > 42: import org.junit.runners.Parameterized.Parameters; > 43: import org.junit.runners.Parameterized; These two imports should be removed. modules/javafx.web/src/test/java/test/javafx/scene/web/HistoryTest.java line 2: > 1: /* > 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. Year change should be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/MiscellaneousTest.java line 2: > 1: /* > 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. Year change should be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java line 36: > 34: import org.junit.jupiter.api.Test; > 35: import org.junit.jupiter.api.extension.ExtendWith; > 36: import org.junit.runners.Parameterized.Parameters; This import should be removed. ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1567#pullrequestreview-2307066756 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761457630 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761415098 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761415569 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761458384 From jbhaskar at openjdk.org Mon Sep 16 16:32:22 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 16:32:22 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 15:49:39 GMT, Ambarish Rapte wrote: >> Jay Bhaskar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Merge branch 'master' into testsprint >> - revert copyright date >> - Revert "copyright year updated along with minor spcae related review" >> >> This reverts commit 27275c3e06311b993e7a48eeb8616acc4cc774e8. >> - converting newly added tests to JUNIT5 >> - resolve conflict >> - copyright year updated along with minor spcae related review >> - 8339515: [TestBug] Convert web tests to JUnit 5 > > modules/javafx.web/src/test/java/test/javafx/scene/web/HistoryTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. > > Year change should be reverted. already did like Copyright (c) 2011, 2022, > modules/javafx.web/src/test/java/test/javafx/scene/web/MiscellaneousTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. > > Year change should be reverted. already did like Copyright (c) 2011, 2022, ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761471586 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761470974 From angorya at openjdk.org Mon Sep 16 16:34:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 16 Sep 2024 16:34:39 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: > Converting control module tests to junit5. > > The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ## JUnit5 Migration Notes > > Most of the changes are trivial, except for the following: > > 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) > 2. parameterized tests: junit5 allows for parameterizing individual tests > 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) > 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes > 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` > > ### Parameterized Class-Level Tests > > junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) > > The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. > > To summarize: > - remove `@Before` from the setup method > - call the setup method from each parameterized method (adding parameters and replacing `@Test` with > > @ParameterizedTest > @MethodSource("parameters") > > where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: > > private static Stream parameters() { > return Stream.of( > Arguments.of("a", 1), > Arguments.of("foo", 3) > ); > } > > > ### Migration Tricks > > Here are the steps that might speed up the process: > > 1. remove all the junit4 imports > 2. paste the following junit5 imports (below) > 3. fix the errors > 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) > 7. after all is done, verify that there is no more junit4 names by running the command mentioned below > > junit5 imports (in no particular order): > > import org.junit.jupiter.api.AfterEach; > import org.junit.jupiter.api.BeforeEach; > import org.junit.jupiter.api.Test; > import org.junit.jupiter.api.Disabled; > import org.junit.jupiter.params.ParameterizedTest; > imp... 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: - review comments - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - part 12, 9274 - 185 = 9089 - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - part 11, 9242 tests, 185 ignored - part 10 - part 9 cell - part 8 - part 7 - part 6 - ... and 6 more: https://git.openjdk.org/jfx/compare/c43c9162...b5270280 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1561/files - new: https://git.openjdk.org/jfx/pull/1561/files/5e942478..b5270280 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1561&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1561&range=00-01 Stats: 372 lines in 19 files changed: 23 ins; 57 del; 292 mod Patch: https://git.openjdk.org/jfx/pull/1561.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1561/head:pull/1561 PR: https://git.openjdk.org/jfx/pull/1561 From jbhaskar at openjdk.org Mon Sep 16 16:39:55 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 16:39:55 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v7] In-Reply-To: References: Message-ID: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: remove old juini4 imports ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1567/files - new: https://git.openjdk.org/jfx/pull/1567/files/780ef842..7206657e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=05-06 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From jbhaskar at openjdk.org Mon Sep 16 16:39:56 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 16:39:56 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: <9YK_fUUB4cMVWDlps5qCyr59zF3yguEkk5SRW25-h80=.f4045991-9ca4-40c8-b3e3-d810101e35fa@github.com> On Mon, 16 Sep 2024 16:19:19 GMT, Ambarish Rapte wrote: >> Jay Bhaskar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Merge branch 'master' into testsprint >> - revert copyright date >> - Revert "copyright year updated along with minor spcae related review" >> >> This reverts commit 27275c3e06311b993e7a48eeb8616acc4cc774e8. >> - converting newly added tests to JUNIT5 >> - resolve conflict >> - copyright year updated along with minor spcae related review >> - 8339515: [TestBug] Convert web tests to JUnit 5 > > modules/javafx.web/src/test/java/test/javafx/scene/web/FormControlsTest.java line 43: > >> 41: import org.junit.jupiter.api.extension.ExtendWith; >> 42: import org.junit.runners.Parameterized.Parameters; >> 43: import org.junit.runners.Parameterized; > > These two imports should be removed. resolved > modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java line 36: > >> 34: import org.junit.jupiter.api.Test; >> 35: import org.junit.jupiter.api.extension.ExtendWith; >> 36: import org.junit.runners.Parameterized.Parameters; > > This import should be removed. resoled ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761480517 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761480209 From aghaisas at openjdk.org Mon Sep 16 16:44:10 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 16 Sep 2024 16:44:10 GMT Subject: Integrated: 8339513: [TestBug] Convert fxml tests to JUnit 5 In-Reply-To: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> References: <9tCpBYNEHX2RCAGP1ick92faUWFaAJIPOrfdy6-t0nA=.241a9db4-0f1c-401c-9482-287e7aae119f@github.com> Message-ID: On Fri, 13 Sep 2024 10:45:33 GMT, Ajit Ghaisas wrote: > This converts FXML module tests to junit5. > > All changes are trivial API replacements from junit4 to junit5. > There are no parameterized tests in this module. This pull request has now been integrated. Changeset: 5993c09e Author: Ajit Ghaisas URL: https://git.openjdk.org/jfx/commit/5993c09eb21136d7371d355b72cb4b2e5b77c49d Stats: 181 lines in 31 files changed: 57 ins; 16 del; 108 mod 8339513: [TestBug] Convert fxml tests to JUnit 5 Reviewed-by: kcr, angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1564 From kcr at openjdk.org Mon Sep 16 17:12:16 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Sep 2024 17:12:16 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 16:29:25 GMT, Jay Bhaskar wrote: >> modules/javafx.web/src/test/java/test/javafx/scene/web/HistoryTest.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved. >> >> Year change should be reverted. > > already did like Copyright (c) 2011, 2022, No, what happened is that the _way_ you reverted your copyright change caused a change that you had earlier merged in from master to be lost. So you have effectively undone a change that was done by another commit that went into master. Please re-revert the change as Ambarish pointed out. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1761533726 From arapte at openjdk.org Mon Sep 16 18:50:14 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 16 Sep 2024 18:50:14 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 [v3] In-Reply-To: References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: On Mon, 16 Sep 2024 15:18:33 GMT, Andy Goryachev wrote: >> Further additions to the MonkeyTester application: >> >> - tree/table view column property sheets ? >> - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? >> - properties... context menu ? >> - context menu: table columns, toolbar items ? >> - control.context menu option >> - property monitor tool ? >> - accessibility logging ? >> >> - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) >> - Page -> Snapped Split Panes menu option for the control container >> >> This PR simply syncs up with the dev repository >> https://github.com/andy-goryachev-oracle/MonkeyTest > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8328828.monkey > - review comments > - Merge remote-tracking branch 'origin/master' into 8328828.monkey > - whitespace > - 8328828: Monkey Tester Application Part 4 LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1560#pullrequestreview-2307478281 From hmeda at openjdk.org Mon Sep 16 18:50:54 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 16 Sep 2024 18:50:54 GMT Subject: RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 Message-ID: Updated additional webkit-619.1 fixes from webkitgtk-2.44.4. Build is successful on all platforms.No issues seen ------------- Commit messages: - WebKit 619.1 fixes from WebKitGTK 2.44.4 Changes: https://git.openjdk.org/jfx/pull/1570/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1570&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340208 Stats: 546 lines in 103 files changed: 326 ins; 116 del; 104 mod Patch: https://git.openjdk.org/jfx/pull/1570.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1570/head:pull/1570 PR: https://git.openjdk.org/jfx/pull/1570 From jbhaskar at openjdk.org Mon Sep 16 23:03:50 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 23:03:50 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v8] In-Reply-To: References: Message-ID: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Year change should be reverted as main ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1567/files - new: https://git.openjdk.org/jfx/pull/1567/files/7206657e..c7cb5cdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From jbhaskar at openjdk.org Mon Sep 16 23:03:50 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 16 Sep 2024 23:03:50 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 17:09:14 GMT, Kevin Rushforth wrote: >> already did like Copyright (c) 2011, 2022, > > No, what happened is that the _way_ you reverted your copyright change caused a change that you had earlier merged in from master to be lost. So you have effectively undone a change that was done by another commit that went into master. Please re-revert the change as Ambarish pointed out. got it, Thanks ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762059963 From kcr at openjdk.org Mon Sep 16 23:40:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Sep 2024 23:40:09 GMT Subject: RFR: 8339508: RenderPerf Test Application In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 09:12:57 GMT, Lukasz Kostyra wrote: >> This PR migrates RenderPerf performance test application from jfx-sandbox metal branch: https://github.com/openjdk/jfx-sandbox/tree/metal/tests/performance/animation/RenderPerfTest/src/renderperf >> >> RenderPerf is a performance test application which draws provided number of "particles" (JFX nodes) on the screen and animates them. After some time (default 10 seconds of testing + warmup) the test automatically closes and reports FPS values. Test was developed as part of Metal backend for performance testing and we decided to integrate it with mainline for any potential further development and fixes. >> >> Command line options for the test: >> - `-n` - number of particles to draw, defaults to 1000 >> - `-t` - name of test to run, defaults to running all tests in random order. Can provide multiple tests, ex. `-t Rectangle Image` >> - `-d` - test duration in seconds, defaults to 10. Can be set to 0, which means the test will run infinitely long and end only when user manually closes the stage, mostly useful for stability testing. >> >> Some tests use `duke.png` image provided with this PR. This is an openly available Duke Wave image taken from https://wiki.openjdk.org/display/duke/Gallery and rescaled for test purposes. >> >> PR consists of two commits: >> - Base version of RenderPerfTest developed by @karthikpandelu >> - My commit adding `-d` flag and implementing plenty of other fixes as part of [JDK-8331570](https://bugs.openjdk.org/browse/JDK-8331570) > > Since this PR both migrates the base version (JDK-8339508) and adds test duration flag (JDK-8331570) I will link the latter issue as well. @lukostyra Can you do a `/contributor add @karthikpandelu`? Also, can you change the fix version of the secondary bug to tbd to address the following warning: > [JDK-8331570](https://bugs.openjdk.org/browse/JDK-8331570): RenderPerf test: Add infinite test mode for stress-testing scenarios (Bug - P4)(?? The fixVersion in this issue is [internal] but the fixVersion in .jcheck/conf is jfx24, a new backport will be created when this pr is integrated.) Reviewers: @arapte @jayathirthrao ------------- PR Comment: https://git.openjdk.org/jfx/pull/1568#issuecomment-2354214063 From mstrauss at openjdk.org Mon Sep 16 23:49:48 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 16 Sep 2024 23:49:48 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v39] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/1227a79f..1c842ccc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=38 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=37-38 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From kcr at openjdk.org Tue Sep 17 00:06:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Sep 2024 00:06:09 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v8] In-Reply-To: References: Message-ID: <2nQ4cRjRPora0MFgx2rOFW_bLznDsmXab55nzZmu4jQ=.b9976594-af94-44f7-96de-a54b32e4b48b@github.com> On Mon, 16 Sep 2024 23:03:50 GMT, Jay Bhaskar wrote: >> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Year change should be reverted as main Note to reviewers: The GHA build compiles the web tests, but doesn't run them. Someone will need to do an offline test run with this patch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1567#issuecomment-2354238736 From kcr at openjdk.org Tue Sep 17 02:08:13 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Sep 2024 02:08:13 GMT Subject: RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 18:45:45 GMT, Hima Bindu Meda wrote: > Updated additional webkit-619.1 fixes from webkitgtk-2.44.4. Build is successful on all platforms.No issues seen Reviewers: @kevinrushforth @tiainen ------------- PR Comment: https://git.openjdk.org/jfx/pull/1570#issuecomment-2354362163 From jhendrikx at openjdk.org Tue Sep 17 11:01:21 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 17 Sep 2024 11:01:21 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v39] In-Reply-To: References: Message-ID: <__xktkCQ7_Joe2fqzWWgNlQ7Wrz1mUqhdqFwpA1yhEM=.265384f2-c4e7-494b-8a09-450e249bd0cc@github.com> On Mon, 16 Sep 2024 23:49:48 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > javadoc change Marked as reviewed by jhendrikx (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2309414638 From arapte at openjdk.org Tue Sep 17 11:36:16 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 17 Sep 2024 11:36:16 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v8] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 23:03:50 GMT, Jay Bhaskar wrote: >> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Year change should be reverted as main Providing a few comments, majority are related to correcting indentation correction. 1. Only space changes: Some indentation changes only add or remove spaces. I would suggest to avoid these changes. Or add only if the existing formatting is very bad. But would recommend to avoid. 2. Some indendations are bad, which needs correction for example having `);` on a separate line. Another comment is regarding Parameterized test: modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java Looks like the test is not converted correctly. The parameters are never assigned to the member variables. Hence never tested. Please take a look at the specific comment on the test. modules/javafx.web/src/test/java/test/javafx/scene/web/BindingTest.java line 86: > 84: 0.0, > 85: "WebPage zoom factor" > 86: ); Minor reformatting could be done: `0.0, "WebPage zoom factor");` modules/javafx.web/src/test/java/test/javafx/scene/web/CSSTest.java line 368: > 366: " \n" + > 367: " \n" + > 368: "" The formatting change can be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/CallbackTest.java line 200: > 198: clear(); > 199: script = JS_PROMPT.replaceAll("MESSAGE", message) > 200: .replaceAll("DEFAULT", defaultValue); only formatting change, could be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/CallbackTest.java line 282: > 280: Rectangle2D r = ev.getData(); > 281: called(RESIZED, r.getMinX(), r.getMinY(), > 282: r.getWidth(), r.getHeight()); only formatting change, could be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java line 50: > 48: // JDK-8162922 > 49: @Test public void testCanvasStrokeRect() { > 50: final String htmlCanvasContent = "\n" Only formatting change, should be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java line 81: > 79: 255, 0, 0, 255, > 80: 255, 0, 0, 255,}; > 81: */ only formatting change, could be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java line 91: > 89: 0, 0, 0, 0, > 90: 0, 0, 0, 0, > 91: 0, 0, 0, 0}; only formatting change, could be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java line 140: > 138: + "ctx.fillStyle = pattern;\n" > 139: + "ctx.fillRect(0, 0, 100, 100);\n" > 140: + "\n"; only formatting change, could be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java line 167: > 165: ), > 166: "First rect center" > 167: ); formatting/ indentation needs correction. for example: assertEquals(0, (int) getEngine().executeScript("document.getElementById('canvaspattern').getContext('2d').getImageData(1, 1, 1, 1).data[0]"), "Pattern top-left corner"); modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java line 186: > 184: + "" > 185: + "" > 186: , mime); only formatting change, could be reverted. modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java line 196: > 194: exMessage.contains("Exception") || exMessage.contains("Error"), > 195: String.format("Test failed with exception:\n%s", exMessage) > 196: ); Indentation correction: assertFalse(exMessage.contains("Exception") || exMessage.contains("Error"), String.format("Test failed with exception:\n%s", exMessage)); modules/javafx.web/src/test/java/test/javafx/scene/web/WebViewTest.java line 107: > 105: " " + > 106: " " > 107: ); Indentation change, could be reverted. ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1567#pullrequestreview-2309330479 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762989324 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762993041 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762995926 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762995750 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762996408 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762997205 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762997327 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762998971 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1763004526 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1762999828 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1763009212 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1763019008 From arapte at openjdk.org Tue Sep 17 11:36:17 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 17 Sep 2024 11:36:17 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v8] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 12:01:41 GMT, Marius Hanl wrote: >> In this case, keeping the values as instance variables is more reliable. Since all the tests pass when hashValue and expected are instance variables and some of them fail when I adding parameter to testScriptTagWithCorrectHashValue , >> >> it's likely that their assignment happens at the correct time relative to the @BeforeEach setup. Using parameters may interfere with the test lifecycle, since hasValue is being used in >> @BeforeEach >> public void setup() ....{} >> >> it's safer and more straightforward to use instance variables.This would also make it easier to manage the state across @BeforeEach > > I think you need to do the same as done by @andy-goryachev-oracle in his JUnit5 replacement PR: > > public void setup(String hashValue, String expected) throws Exception { > htmlFile = new File("subresource-integrity-test.html"); > ... > } > > @ParameterizedTest > @MethodSource("dataProvider") > public void testScriptTagWithCorrectHashValue(String hashValue, String expected) { > setup(hashValue, expected); > ... > } > > > This way you dont need the instance fields, as they will be empty all the time and never assigned. I also think the test needs to be modified as suggested by @Maran23 and @andy-goryachev-oracle . With the changes in this PR the member variables are never assigned with value. I verified the values of the two member variables by printing them before line 102, They are always empty. Apply below change, after applying this PR changes. diff --git a/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java b/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java index e65ff7d32f..0d2d670777 100644 --- a/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java +++ b/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java @@ -99,6 +99,8 @@ public final class SubresourceIntegrityTest extends TestBase { load(htmlFile); final String bodyText = (String) executeScript("document.body.innerText"); assertNotNull("document.body.innerText must be non null for " + hashValue, bodyText); + System.err.println("hashValue = " + hashValue); + System.err.println("expected = " + expected); assertEquals(hashValue, expected, bodyText); } Screenshot 2024-09-17 at 4 51 46?PM ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1763063040 From sykora at openjdk.org Tue Sep 17 11:49:12 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Tue, 17 Sep 2024 11:49:12 GMT Subject: RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 18:45:45 GMT, Hima Bindu Meda wrote: > Updated additional webkit-619.1 fixes from webkitgtk-2.44.4. Build is successful on all platforms.No issues seen Builds and tests ran fine. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1570#pullrequestreview-2309518303 From jbhaskar at openjdk.org Tue Sep 17 12:13:55 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 17 Sep 2024 12:13:55 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v9] In-Reply-To: References: Message-ID: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Cleaning according review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1567/files - new: https://git.openjdk.org/jfx/pull/1567/files/c7cb5cdd..990037a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=07-08 Stats: 99 lines in 5 files changed: 0 ins; 13 del; 86 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From jbhaskar at openjdk.org Tue Sep 17 12:16:11 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 17 Sep 2024 12:16:11 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v9] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 11:22:56 GMT, Ambarish Rapte wrote: >> I think you need to do the same as done by @andy-goryachev-oracle in his JUnit5 replacement PR: >> >> public void setup(String hashValue, String expected) throws Exception { >> htmlFile = new File("subresource-integrity-test.html"); >> ... >> } >> >> @ParameterizedTest >> @MethodSource("dataProvider") >> public void testScriptTagWithCorrectHashValue(String hashValue, String expected) { >> setup(hashValue, expected); >> ... >> } >> >> >> This way you dont need the instance fields, as they will be empty all the time and never assigned. > > I also think the test needs to be modified as suggested by @Maran23 and @andy-goryachev-oracle . > With the changes in this PR the member variables are never assigned with value. > I verified the values of the two member variables by printing them before line 102, They are always empty. > Apply below change, after applying this PR changes. > > diff --git a/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java b/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java > index e65ff7d32f..0d2d670777 100644 > --- a/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java > +++ b/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java > @@ -99,6 +99,8 @@ public final class SubresourceIntegrityTest extends TestBase { > load(htmlFile); > final String bodyText = (String) executeScript("document.body.innerText"); > assertNotNull("document.body.innerText must be non null for " + hashValue, bodyText); > + System.err.println("hashValue = " + hashValue); > + System.err.println("expected = " + expected); > assertEquals(hashValue, expected, bodyText); > } > > > Screenshot 2024-09-17 at 4 51 46?PM It is ok to use instance variable for SubresourceIntegrityTest. there is no issue. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1763134034 From kcr at openjdk.org Tue Sep 17 13:03:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Sep 2024 13:03:11 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v9] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 12:13:19 GMT, Jay Bhaskar wrote: >> I also think the test needs to be modified as suggested by @Maran23 and @andy-goryachev-oracle . >> With the changes in this PR the member variables are never assigned with value. >> I verified the values of the two member variables by printing them before line 102, They are always empty. >> Apply below change, after applying this PR changes. >> >> diff --git a/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java b/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java >> index e65ff7d32f..0d2d670777 100644 >> --- a/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java >> +++ b/modules/javafx.web/src/test/java/test/javafx/scene/web/SubresourceIntegrityTest.java >> @@ -99,6 +99,8 @@ public final class SubresourceIntegrityTest extends TestBase { >> load(htmlFile); >> final String bodyText = (String) executeScript("document.body.innerText"); >> assertNotNull("document.body.innerText must be non null for " + hashValue, bodyText); >> + System.err.println("hashValue = " + hashValue); >> + System.err.println("expected = " + expected); >> assertEquals(hashValue, expected, bodyText); >> } >> >> >> Screenshot 2024-09-17 at 4 51 46?PM > > It is ok to use instance variable for SubresourceIntegrityTest. there is no issue. @jaybhaskar Yes, there is an issue as the above comment from @arapte shows. Please don't mark this as "resolved" until it is, and @arapte is satisfied. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1763205529 From jbhaskar at openjdk.org Tue Sep 17 13:48:50 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 17 Sep 2024 13:48:50 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v10] In-Reply-To: References: Message-ID: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: remove instance variables in parametrized test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1567/files - new: https://git.openjdk.org/jfx/pull/1567/files/990037a4..54575feb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1567&range=08-09 Stats: 8 lines in 1 file changed: 1 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1567.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1567/head:pull/1567 PR: https://git.openjdk.org/jfx/pull/1567 From jbhaskar at openjdk.org Tue Sep 17 13:48:50 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 17 Sep 2024 13:48:50 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v10] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 13:00:09 GMT, Kevin Rushforth wrote: >> It is ok to use instance variable for SubresourceIntegrityTest. there is no issue. > > @jaybhaskar Yes, there is an issue as the above comment from @arapte shows. Please don't mark this as "resolved" until it is, and @arapte is satisfied. Thanks , I have modified and push according ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1763280155 From jbhaskar at openjdk.org Tue Sep 17 13:48:50 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 17 Sep 2024 13:48:50 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v10] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 13:45:03 GMT, Jay Bhaskar wrote: >> @jaybhaskar Yes, there is an issue as the above comment from @arapte shows. Please don't mark this as "resolved" until it is, and @arapte is satisfied. > > Thanks , I have modified and push according I found issue , and done changes according to review, Thanks all ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1763282127 From jdv at openjdk.org Tue Sep 17 14:33:46 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 17 Sep 2024 14:33:46 GMT Subject: RFR: 8211247: Open-source simple test programs for FX / SWT interop Message-ID: This PR is for open-sourcing HelloFXCanvas test app. JBS : https://bugs.openjdk.org/browse/JDK-8211247 It is an SWT app with SWT button and an FXCanvas with animated rectangle. This is used on our integration testing. This test is now moved to apps/toys, please refer to apps/toys/HelloFXCanvas/README.txt on how to run this toy. Also this toy hangs on exit in macOS and it crashes on Wayland in Ubuntu 24.04, for which separate bugs will be raised. ------------- Commit messages: - 8211247: Open-source simple test programs for FX / SWT interop Changes: https://git.openjdk.org/jfx/pull/1571/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1571&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8211247 Stats: 1266 lines in 9 files changed: 1263 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1571.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1571/head:pull/1571 PR: https://git.openjdk.org/jfx/pull/1571 From jdv at openjdk.org Tue Sep 17 15:38:46 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 17 Sep 2024 15:38:46 GMT Subject: RFR: 8211234: Open-source simple test programs for FX / Swing interop Message-ID: This PR is for open-sourcing 2 closed toys EmbeddedSwing and HelloWorld. JBS : https://bugs.openjdk.org/browse/JDK-8211234 1)EmbeddedSwing - a simple FX test app with a SwingNode containing a Swing application 2)HelloWorld contains 2 test apps : - HelloJFXPanel - a simple Swing test app with a JButton and a JFXPanel containing an animated rectangle - HelloJFXPanel2 - a simple Swing test app with a JButton and a JFXPanel containing a JavaFX Button and ComboBox (with Tooltips) These new test apps are added under apps/toys/ directory. ------------- Commit messages: - 8211234: Open-source simple test programs for FX / Swing interop Changes: https://git.openjdk.org/jfx/pull/1572/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1572&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8211234 Stats: 3379 lines in 18 files changed: 3373 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1572.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1572/head:pull/1572 PR: https://git.openjdk.org/jfx/pull/1572 From angorya at openjdk.org Tue Sep 17 17:39:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Sep 2024 17:39:18 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 nine 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 oh no it got auto closed again... sorry. I think this PR should be re-opened. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1373#issuecomment-2356530936 From kcr at openjdk.org Tue Sep 17 21:11:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Sep 2024 21:11:12 GMT Subject: RFR: 8211234: Open-source simple test programs for FX / Swing interop In-Reply-To: References: Message-ID: <4gtptYyd-z-QyCb5ixOtNrvca9_4kt90dclNhMyNlME=.7a9d2a23-94da-453d-a7ef-dab68a2e94f0@github.com> On Tue, 17 Sep 2024 15:33:06 GMT, Jayathirth D V wrote: > This PR is for open-sourcing 2 closed toys EmbeddedSwing and HelloWorld. > JBS : https://bugs.openjdk.org/browse/JDK-8211234 > > 1)EmbeddedSwing - a simple FX test app with a SwingNode containing a Swing application > > 2)HelloWorld contains 2 test apps : > > - HelloJFXPanel - a simple Swing test app with a JButton and a JFXPanel containing an animated rectangle > > - HelloJFXPanel2 - a simple Swing test app with a JButton and a JFXPanel containing a JavaFX Button and ComboBox (with Tooltips) > > These new test apps are added under apps/toys/ directory. Looks good. The test programs build and run as expected. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1572#pullrequestreview-2311072626 From kcr at openjdk.org Tue Sep 17 21:11:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Sep 2024 21:11:14 GMT Subject: RFR: 8211247: Open-source simple test programs for FX / SWT interop In-Reply-To: References: Message-ID: <7DlZkRxq0N0ugQHDAYTs5JTrLLfVgKxYSk5Y-1dB21Q=.d2df373c-a275-451c-870c-9b4d73c84842@github.com> On Tue, 17 Sep 2024 14:29:11 GMT, Jayathirth D V wrote: > This PR is for open-sourcing HelloFXCanvas test app. > JBS : https://bugs.openjdk.org/browse/JDK-8211247 > It is an SWT app with SWT button and an FXCanvas with animated rectangle. > This is used on our integration testing. > > This test is now moved to apps/toys, please refer to apps/toys/HelloFXCanvas/README.txt on how to run this toy. > > Also this toy hangs on exit in macOS and it crashes on Wayland in Ubuntu 24.04, for which separate bugs will be raised. Looks good. The test program builds and runs as expected. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1571#pullrequestreview-2311073717 From angorya at openjdk.org Tue Sep 17 21:17:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Sep 2024 21:17:33 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v11] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision: - fixed directories - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - hide impl. detail - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - removed duplicate files - moved to apps, review comments - bsd license for sample code - fixes and review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - improved vertical scrolling - ... and 9 more: https://git.openjdk.org/jfx/compare/8f4fe87c...0fdd9987 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/1aafab27..0fdd9987 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=09-10 Stats: 192 lines in 38 files changed: 60 ins; 16 del; 116 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Tue Sep 17 21:25:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Sep 2024 21:25:56 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v12] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/0fdd9987..ce1b6953 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=10-11 Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Tue Sep 17 21:25:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Sep 2024 21:25:57 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v10] In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 22:03:53 GMT, Kevin Rushforth 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 17 additional commits since the last revision: >> >> - hide impl. detail >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - removed duplicate files >> - moved to apps, review comments >> - bsd license for sample code >> - fixes and review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - improved vertical scrolling >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - cleanup >> - ... and 7 more: https://git.openjdk.org/jfx/compare/e688b168...1aafab27 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 314: > >> 312: /** >> 313: * Creates the instance with the in-memory model {@link RichTextModel}. >> 314: */ > > I recommend adding `@defaultValue` Can you clarify please? `@defaultValue` seem to apply to a property, this is a constructor. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1764031629 From angorya at openjdk.org Tue Sep 17 22:49:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Sep 2024 22:49:13 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: <-fAKMTWFJTGwUcS6ZdrN1V0CLMOvIMjvuDg5R7RcbBc=.c4f08339-f4bc-4b0e-9745-c62c1e89f113@github.com> On Mon, 16 Sep 2024 16:34:39 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - part 9 cell > - part 8 > - part 7 > - part 6 > - ... and 6 more: https://git.openjdk.org/jfx/compare/58de5174...b5270280 @lukostyra @jaybhaskar please review ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2357061070 From andy.goryachev at oracle.com Tue Sep 17 23:09:06 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 17 Sep 2024 23:09:06 +0000 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: Dear John: You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. Thank you -andy From: John Hendrikx Date: Saturday, September 14, 2024 at 09:41 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Proposal: Focus Traversal API Hi Andy, First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. On 14/09/2024 00:17, Andy Goryachev wrote: Dear John, Everyone: Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: 1. move the focus traversal logic away from the components and into the Scene 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents 3. (more) standard policies 4. using CSS (there is of course more topics in your response, but let me start with the 4 above) #1 I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? There's two things here. 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. #2 This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? #3 One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). #4 The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: - I define the container hierarchy (VBox, HBox, which children go where) - I set a style name - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? -- There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. Also I think this can be implemented gradually. Here's a potential plan: 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... Public API: Limited to a new Event 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys Public API: none 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are Public API: none Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. 4. Expose policy property/properties on Parent Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. Public API: new properties on Parent 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. Benefit: less work for control implementors (although they could just "copy" said code) Public API: Maybe some methods in Node, or some kind of static helper. 6. CSS styleable properties If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). Public API: Nothing in Java, but document as CSS properties --John Thank you, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, September 11, 2024 at 19:05 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Focus Traversal API Hi Andy / List, I've given this some thought first, without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ## KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: - OPEN This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: Node from = ... switch (((KeyEvent)event).getCode()) { case UP: FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); event.consume(); break; case DOWN: // or use the convenience method FocusTraversal.traverseDown(from); event.consume(); break; } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: Node from = ... Node result = switch(traversalEvent.getEventType()) { case TraversalEvent.UP -> FocusTraversals.findUp(from); case TraversalEvent.DOWN -> FocusTraversals.findDown(from); // etc } if (result != null) { result.requestFocus(); traversalEvent.consume(); } Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Tue Sep 17 23:10:13 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 17 Sep 2024 23:10:13 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 16:34:39 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - part 9 cell > - part 8 > - part 7 > - part 6 > - ... and 6 more: https://git.openjdk.org/jfx/compare/efb7e09d...b5270280 Looks good to me. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1561#pullrequestreview-2311274542 From mhanl at openjdk.org Tue Sep 17 23:10:14 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 17 Sep 2024 23:10:14 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: <8RUvIYwaOOFt2W1mKrv-z7e7yEATNASJ9vqZWNtZ52g=.a059ded5-c282-4862-8a08-1fb9b25fa923@github.com> On Mon, 16 Sep 2024 15:23:48 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/behavior/AccordionBehaviorTest.java line 39: >> >>> 37: >>> 38: @Test >>> 39: public void focusGainedIsCaughtByBehavior() { >> >> Wait, is this an empty test? Why? > > Intentionally did not want to change the number of tests, which should be double checked during the review. Leaving as is for now. Agree. >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinCreationTest.java line 98: >> >>> 96: } >>> 97: >>> 98: public record Parameter( >> >> Minor: Can also imagine a name like `LabelParameter` or `LabelConfig` > > rather, this record should be declared private Also that is a good idea. >> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/QueryAccessibleAttributeTest.java line 50: >> >>> 48: // @BeforeEach >>> 49: // junit5 does not support parameterized class-level tests yet >>> 50: public void setup(Class nodeClass) { >> >> Minor: Since `Control` is used above, should also be used here and below as Generic. > > hmm, the code is technically correct since Control extends Node. yes, just a minor nitpick since relaxing the bounds is not really needed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1764150535 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1764149338 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1764146934 From arapte at openjdk.org Wed Sep 18 03:37:10 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 18 Sep 2024 03:37:10 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v10] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 13:48:50 GMT, Jay Bhaskar wrote: >> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > remove instance variables in parametrized test LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1567#pullrequestreview-2311544026 From arapte at openjdk.org Wed Sep 18 03:53:13 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 18 Sep 2024 03:53:13 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 16:34:39 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - part 9 cell > - part 8 > - part 7 > - part 6 > - ... and 6 more: https://git.openjdk.org/jfx/compare/a5628025...b5270280 modules/javafx.controls/src/test/java/test/javafx/scene/chart/NumberAxisTest.java line 261: > 259: @Test > 260: public void testCloseValues() { > 261: assertTimeout(Duration.ofMillis(1000), () -> { Could use the [Timeout annotation](https://junit.org/junit5/docs/5.5.1/api/org/junit/jupiter/api/Timeout.html) as : `@Timeout(1)` or `@Timeout(1000 ms)` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1764353218 From john.hendrikx at gmail.com Wed Sep 18 06:05:15 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 18 Sep 2024 08:05:15 +0200 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: Andy, As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. --John On 18/09/2024 01:09, Andy Goryachev wrote: > > Dear John: > > You do bring a lot of good points, no doubt.? And I do agree with a > lot of the suggestion, but I still want to emphasize two points: > > 1. The backward compatibility should not be dismissed that easily.? > There is a number of existing applications out there and we do not > want to break them.? Whether the behavior is specified or not is > irrelevant, we do not want to cause mayhem from the customers and > developers alike whose keyboard navigation suddenly changed. > > 2. I question the cost benefit analysis of the redesign idea. While I > agree with you that it might help with some unusual cases, the overall > benefit is rather limited.? The benefit of the proposed solution is, > in my opinion, far greater: it allows for custom traversal policies (a > feature that has been requested multiple times) and enables focus > traversal from custom components, something of a lesser value, but > still important.? Exposing the existing APIs is a relatively cheap > solution that will give us two features at nearly zero cost.? On the > other hand, I doubt that our team, or yourself, are willing commit > substantial development effort to redesign the thing to use events.? > Which brings me to the choice I mentioned earlier: realistically, we > have a choice of providing two requested features soon, or never. > > I would also encourage other members of the development community to > voice their opinion on the subject, perhaps there is something else we > can do to move forward. > > Thank you > > -andy > > *From: *John Hendrikx > *Date: *Saturday, September 14, 2024 at 09:41 > *To: *Andy Goryachev , > openjfx-dev at openjdk.org > *Subject: *[External] : Re: Proposal: Focus Traversal API > > Hi Andy, > > First let me say that when it comes to designing an API, you really > need to take the time to think the solution through.? The current > internal solution was probably kept internal for exactly that reason, > insufficient time to work out the kinks and look into alternatives. > > An API is almost impossible to change later, so the general rule is > that if you're not sure about an API, then its better to have no API.? > This is why I think it is important that we first look for what the > API should look like, then worry about how this can be fitted onto > JavaFX.? Making concessions related to the current implementation > before having a clear idea of how the API should preferably work is > not part of that.? You start making concessions only when it turns out > the preferred design would encounter unresolvable problems in the > current implementation. > > Since I think there is very little public API related to focus > traversal, nor is there any specification of how it currently works, I > think we have a lot of room to maneuver.? This is why I think we > should first reach a consensus on the API, then look how it can be > fitted on top of FX.? Sometimes a well thought out API also is a > natural fit, and may be easier to migrate to than you think. > > On 14/09/2024 00:17, Andy Goryachev wrote: > > Dear John, Everyone: > > Thank you for a thoughtful response!? Some of the ideas you > described definitely deserve further consideration.? If I were to > summarize: > > 1. move the focus traversal logic away from the components and > into the Scene > > 2. re-implement focus traversal through TraversalEvents rather > than responding directly to KeyEvents > > 3. (more) standard policies > > 4. using CSS > > (there is of course more topics in your response, but let me start > with the 4 above) > > #1 > > I generally like this idea.? In some sense it is already how > things work internally, but without the ability to customize that > (i.e. by introducing custom traversal keys, or removing existing > ones).? The downside is substantial: not only we'd need to > re-design the whole of the focus traversal, but also rework the > existing control's behaviors.? Did I mention the risk of > regression, given the absence of comprehensive behavioral tests? > > There's two things here. > > 1. There is no need to re-design the whole focus traversal.? The old > internal system can be gradually replaced (it works by directly > consuming KeyEvents after all). > > 2. Regression.? When nothing is specified, and the fact that controls > **ought** to work like other common controls in different UI toolkits, > is it a regression when focus traversal works the same as those other > platforms, even if it may be a regression from the point of view of > FX?? For example, a Spinner will currently react to any mouse key, > where as other common toolkits only react to the left mouse button.? > Is it a regression if FX is adjusted to also only react to the left > mouse button?? It's not specified anywhere. > > I think we have sufficient space to maneuver here as long as we are > not making focus traversal completely different from how it commonly > works in UI's. > > Can there be regressions versus the current (unspecified) > implementation?? Sure, there can be.? Is that necessarily bad?? That > depends.? If the new focus traversal works like it does on all other > toolkits, then no, it is more of a bug fix.? Did we break something > with the new implementation?? That's always possible, but will then be > fixed as soon as it is reported. > > #2 > > This may or may not be an integral part of #1. Potentially, it > allows for injection of events by the application code, as well as > simplifies creation of complex custom controls.? The latter > becomes possible with the original proposal, so net benefit is > limited to the first part, I think. > > I think TraversalEvents are quite central to making this an API that > will really stand the test of time.? It leverages the existing event > system, giving you all the power that comes with it.? You did not > answer my question about the TraversalEvents in your design.? Why are > the Events when they can't be triggered, filtered or?consumed? > > #3 > > One obvious possibility is to enable creation of a simple policy > based on a list of Nodes.? I must mention one use case that is > impossible to cover with pre-defined policy is one where > navigation depends on some state.? Such a policy must be > implemented programmatically.? I think one property should be > sufficient - I am strongly against adding two properties here. > > Programmatic escapes can always be achieved by responding directly to > a TraversalEvent.? I think however this should be a rare case, and > standard policies should really cover almost all use cases.? It may be > a gap that should be investigated, and the API adjusted for (usually > the "exceptions" are well worth looking into to see if with a tweak > they can't become "standard").? As for being "strongly against" having > two properties -- that's an odd stance to take without motivating it.? > It could also be rolled into "one" where the Policy is a record with > the two values, but I think we're getting ahead of ourselves here.? > First the API, then the implementation. > > I do think however there is great value in having the Logical and > Directional navigation split.? Often you'll only want to replace one > of these with a custom policy (or a different standard policy), so > that the other navigation method can be used to escape the control. > For example, a Toolbar could be tabbed in an out of (using Logical > navigation) while the Directional navigation is cyclic (and thus can't > be used to escape the control's context). > > #4 > > The idea of using CSS to specify traversal policy seems wrong to > me: the CSS defines the presentation aspects (styles) rather than > behavioral ones.? I know it is possible to set custom skins and > the corresponding behavior via CSS, and we know why (skins define > the appearance), but we should not go beyond that, in my opinion. > > I see no problem styling such properties.? They're FX properties, and > it would be very convenient to style them to globally alter how focus > works, instead of having to rely on, say, Builders or Factories for > controls where traversal policies can be applied.? There are also > already properties that don't only influence the look of controls.? > "-fx-skin" being the most obvious one, but there is also > "-fx-focus-traversable", "-fx-context-menu-enabled", > "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", > "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", > "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably > more.? Aside from "-fx-skin" none of these properties have a visual > impact, but instead alter behavior. > > Note: I'm not saying this needs to be there immediately.? I just want > to make sure we're not closing off this direction, as again, it would > be a huge hassle to do this programmatically.? In "code" the only > things I usually do on my controls are the following: > > - I define the container hierarchy (VBox, HBox, which children go where) > - I set a style name > - I set anything that unfortunately cannot be CSS styled (things like > ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that > are clearly "visual" but still can't be styled). > > All the rest I don't touch, or want to touch.? Having to select a > traversal policy for every control of type X I create is just > cumbersome and unnecessary.? There will be a call then to set this > "globally", and then there will be the question, do we make something > custom with many limitations because it doesn't fit our conceptions of > what (FX) CSS is for (ie, not?style, but only?*visual* style) or do we > just expose these properties as Styleable?leveraging an existing > powerful system with almost zero effort? > > -- > > There is one more aspect of the problem that I think we should > consider.? The current proposal does not change the implementation > in any material way, nor does it change the behavior, thus can be > done quickly.? The benefit everyone gets from it is ability to > trigger focus traversal and to control it via custom policies.? > Any other solution will require resources and the bandwidth we > currently don't have, which means the /probability/ of it being > added to FX is virtually zero.? Let me emphasize, I am not against > attempting to discuss or implement the best possible solution, but > we should be aware of the limitations of the reality we live in. > > "Quickly" and API's are incompatible with each other. There is nothing > worse than exposing an API quickly, which then becomes a burden on the > system -- I think the current CSS API is a prime example of where > "quickly" has gone wrong, costing us tremendous amounts of effort to > make even minor changes to it. > > I urge you to ignore the current implementation, think thoroughly how > (in an ideal world) you would want such an API to work (from a user > perspective, not from an implementor's perspective) and only then see > how this could be made to fit into JavaFX. > > This is exactly what I did.? I did not look at the implementation, > although I'm aware of some of it.? I looked at how I as a user of FX > am building applications, the struggles I have?with it currently, > (with controls for example "eating" KeyEvents), and how I would like > to be able to adjust focus traversal.? Do I want to respond to > "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"?? Do I > also need to respond to "KeyCode.NUM_PAD_LEFT"?? These things should > be abstracted, and preferably I should just be able to choose from > common navigation standards.? And when I do want to change such a > standard, in 99% of the cases that will be the case for all similar > controls in my application.? How do I do such things currently if I > want to change something for all controls in my application?? I use CSS. > > Also I think this can be implemented gradually.? Here's a potential plan: > > 1. Have Scene listen to unused KeyEvents and translate them to > TraversalEvents > > Benefit:?gives custom controls a way to respond to keyboard based > navigation in a platform agnostic way; this probably already removes > the biggest roadblock for custom controls... > > Public API: Limited to a new Event > > 2. Start converting existing controls to listen to TraversalEvent > instead of KeyEvent > > This hits a lot of controls, but should be relatively easy to do, and > it can be all kept internal for now.? It can be done in a few batches. > > Benefit: for each control converted, user can now programmatically > trigger focus changes, and by overriding things at Scene level can > completely change navigation keys > > Public API: none > > 3. Implement a number of standard policies internally (OPEN, CONFINED, > CYCLIC, IGNORED) > > Convert any controls that could use these as their default, removing > any custom logic if it happens to match one of the defaults. > > Benefit: less code to maintain and debug, gives us experience with > which policies make sense and where the gaps are > > Public API: none > > Order: It is possible to do this before 2, and so some of the control > conversions could just consist of removing their custom logic, and > selecting a standard policy. > > 4. Expose policy property/properties?on Parent > > Any controls that are not using a custom policy anymore (of type > IGNORED) can now be user adjusted.? We don't have to guarantee that > each policy makes sense for each control. Changing a default IGNORED > policy to a standard one will change the behavior (as intended) but it > need not be a "complete" behavior that users like.? This is not FX's > problem, and can be improved upon later. > > Benefit: users can now change policies on any existing control, even > ones with a custom policy; many of the controls may support a switch > between OPEN, CONFINED and CYCLIC out of the box. > > Public API: new properties on Parent > > 5. Perhaps expose some helpful tools to calculate the "next" Node for > a given traversal option. > > This can be done at any stage, and can be considered completely > separate.? It is IMHO a relatively low?priority need. > > Benefit: less work for control implementors (although they could just > "copy" said code) > > Public API: Maybe some methods in Node, or some kind of static helper. > > 6. CSS styleable properties > > If we really want to give power to our users, and impress them with a > flexible focus traversal API, then make these properties styleable. > > Benefit: allow users to pick any control, and set is policy globally > or within a subset of controls (ie. dialogs, popups, etc). > > Public API: Nothing in Java, but document as CSS properties > > --John > > Thank you, > > -andy > > *From: *openjfx-dev > on behalf of John Hendrikx > > *Date: *Wednesday, September 11, 2024 at 19:05 > *To: *openjfx-dev at openjdk.org > > *Subject: *Re: Proposal: Focus Traversal API > > Hi Andy / List, > > I've given this some thought first,?without looking too much at > the proposal. > > In my view, focus traversal should be implemented using events, > and FX should provide standard handling of these events controlled > with properties (potentially even CSS stylable for easy mass > changing of the default navigation policy). > > ##?KeyEvent and TraversalEvent separation > > I think the cleanest implementation would be to implement a > KeyEvent listener on Scene that takes any unused KeyEvents, checks > if they're considered navigation keys, and converts these keys to > a new type of event, the TraversalEvent. The TraversalEvent is > then fired at the original target. The TraversalEvent is > structured into Directional and Logical sub types, and has leaf > types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS.? Scene is the logical > place to handle this as without a Scene there is no focus owner, > and so there is no point in doing focus traversal. > > This separation of KeyEvents into TraversalEvents achieves the > following: > > - User can decide to act on **any** key, even navigation keys, > without the system interfering by consuming keys early, > unexpectedly or even consuming these keys without doing anything > (sometimes keys get consumed that don't actually change > focus...).? The navigation keys have many possible dual purposes, > and robbing the user of the opportunity to use them due to an > overzealous component interpreting them as traversal keys is very > annoying.? Dual purposes include for example cursor control in > TextField/TextArea, Scrollbars, etc.? The user should have the > same control here as these FX controls have. > > - Scene is interpreting the KeyEvents, and this interpretation is > now controllable.? If I want a Toolbar (or the whole application) > to react to WASD navigation keys, then installing a KeyEvent > handler at Scene level or at any intermediate Parent level that > converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect > this change easily. > > - The separation also allows to block Focus Traversal only, > without blocking the actual Keys involved.? If I want to stop a > Toolbar from reacting to LEFT/RIGHT, but I need those keys higher > up in the hierarchy, then I'm screwed.? With the separation, the > key events are unaffected, and I can block Toolbars from reacting > specifically to traversal events only. > > ## Traversal Policy Properties on Parent > > I think FX should provide several policies out of the box, based > on common navigation patterns.? The goal here is to have policies > in place that cover all use cases in current FX provided > controls.? This will provide a good base that will cover probably > all realistic work loads that custom controls may have. The goal > is not to support every esoteric form of navigation, instead an > escape hatch will be provided in the form of disabling the > standard navigation. > > In order to achieve this, I think Parent should get two new > properties, which control how it will react to Directional and > Logical navigation.? These will have default values that allow > navigation to flow from Node to Node within a Parent and from > Parent to its Parent when navigation options in a chosen direction > are exhausted within a Parent. Custom controls like Combo boxes, > Toolbars, Button groups, etc, can change the default provided by a > Parent (similar to how some controls change the mouse transparent > flag default). > > These two properties should cover all realistic needs, and IMHO > should be considered to be CSS stylable in the future to allow > easy changing of default policies of controls (ie. want all > Toolbars to react differently to navigation keys, then just style > the appropriate property for all toolbars in one go). > > Parent will use these properties to install an event handler that > reacts to TraversalEvents (not KeyEvents).? This handler can be > fully disabled, or overridden (using setOnTraversalEvent). > > - logicalTraversalPolicy > - directionalTraversalPolicy > > The properties can be set with a value from a TraversalPolicy > enum.? I would suggest the following options: > > - OPEN > > This policy should be the default policy for all Parents.? It will > act and consume a given TraversalEvent only when there is a > suitable target within its hierarchy.? If there is no suitable > target, or the target would remain unchanged, the event is NOT > consumed and left to bubble up, allowing its parent(s) to act on > it instead. > > - CONFINED > > This policy consumes all TraversalEvents, regardless of whether > there is something to navigate to or not.? This policy is suitable > for controls that have some kind of substructure that we don't > want to accidentally exit with either Directional or Logical > navigation.? In most cases, you only want to set one of the > properties to CONFINED as otherwise there would be no keyboard > supported way to exit your control.? This is a suitable policy for > say button groups, toolbars, comboboxes, etc. > > - CYCLIC > > Similar to CONFINED but instead of stopping navigation at the > controls logical boundaries, the navigation wraps around to the > logical start.? For example, when were positioned on the right > most button in a button group, pressing RIGHT again would navigate > to the left most button. > > - IGNORED > > This is similar to the mouseTransparent property, and basically > leaves the TraversalEvent to bubble up.? This policy allows you to > completely disable directional and/or logical navigation for a > control. Useful if you want to install your own handler (the > escape hatch) but still want to keep either the default > directional or logical navigation. > > Possible other options for this enum could include a version that > consumes all TraversalEvents (BLOCK) but I don't see a use for it > at the moment.? There may also be variants of CONFINED and CYCLIC > that make an exception for cases where there is only a single > choice available.? A ButtonGroup for example may want to react > differently depending on whether it has 0, 1 or more buttons.? > Whether these should be enshrined with a custom enum value, or > perhaps a flag, or just left up to a custom implementation is > something we'd need to decide still. > > ## Use Cases > > 1) User wants to change the behavior of a control from its default > to something else (ie. a Control that is CYCLIC can be changed to > OPEN or CONFINED) > > Just call the setters with the appropriate preferred policy.? This > could be done in CSS for maximum convenience to enable a global > change of all similar controls. > > 2) User wants to act on Traversal events that the standard policy > leaves to bubble up > > Just install a Traversal event handler either on the control or on > its parent (depending on their needs).? A potential action to an > unused Traversal event could be to close a Dialog/Toast popup, or > a custom behavior like selecting the first/last item or > next/previous row (ie. if I press "RIGHT" and there is no further > right item, a user could decide to have this select the first item > again in the current Row or the first item in the **next** Row). > > 3) User wants to do crazy custom navigation > > Set both policies to?IGNORED, then install your own event handler > (or use the setOnTraversalHandler to completely override the > handler).? Now react on the Traversal events, consuming them at > will and changing focus to whatever control you desire. > > 4) User wants to change what keys are considered navigation keys > > Install event handler on Scene (or any intermediate Parent) for > KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out > a corresponding Traversal event > > 5) User wants to use keys that are considered navigation keys for > their own purposes > > Just install a KeyEvent handler as usual, without having to worry > that Skins/Controls eat these events before you can get to them > > 6) User wants to stop a control from reacting to traversal events, > without filtering navigation keys completely > > With the separation of unconsumed KeyEvents into TraversalEvents, > a user can now block only the latter to achieve this goal without > having to blanket block certain KeyEvents. > > ----- > > About the Proposal: > > I think the Goals are fine as stated, although I think we differ > on what the Traversal events signify. > > I think CSS support should be considered a possible future goal.? > The proposal should therefore take into account that we may want > to offer this in the future. > > Motivation looks okay. > > > The focus traversal is provided by the FocusTraversal class > which offers static methods for traversing focus in various > directions, determined by the TraversalDirection enum. > > I think these methods don't need to be exposed with a good > selection of standard TraversalPolicy options.? After all, there > are only so many ways that you can do a sensible navigation action > without confusing the user, and therefore I think these policy > options will cover 99% of the use cases already.? For the left > over 1% we could **consider** providing these focus traversal > functions as a separate public API, but I would have them return > the Node they would suggest, and leave the final decision to call > requestFocus up to the caller.? Initially however I think there is > already more than enough power for custom implementations to > listen to Traversal events and do their own custom navigation.? If > it is not similar to one of the standard navigation options, the > traverseUp/Down functions won't be of much use then anyway. > > About your typical example: > > ??? Node from = ... > ??? switch (((KeyEvent)event).getCode()) { > ??? case UP: > ??????? FocusTraversal.traverse(from, TraversalDirection.UP, > TraversalMethod.KEY); > ??????? event.consume(); > ??????? break; > ??? case DOWN: > ??????? // or use the convenience method > ??????? FocusTraversal.traverseDown(from); > ??????? event.consume(); > ??????? break; > ??? } > > I think this is not a good way to deal with events. > > 1) The event is consumed regardless of the outcome of traverse.? > What if focus did not change?? Should the event be consumed? > > 2) This is consuming KeyEvents directly, robbing the user of the > opportunity to act on keys considered "special" by FX. > > 3) This code is not only consuming KeyEvents directly, but also > deciding what keys are navigation keys. > > So I think this example?code should be different. However, first I > expect that in most cases, configuring a different traversal > policy on your Parent subclass will already be sufficient in > almost all cases (especially if we look at FX current controls and > see if the suggested policies would cover those use cases).? So > this code will almost never be needed.? However, in the event that > you need something even more specific, you may consider handling > Traversal events directly.? In which case the code should IMHO > look something like this: > > ??? Node from = ... > > ??? Node result = switch(traversalEvent.getEventType()) { > ?? ?? case TraversalEvent.UP -> FocusTraversals.findUp(from); > ?? ?? case TraversalEvent.DOWN -> FocusTraversals.findDown(from); > ? ? ? // etc > ?? } > > ??? if (result != null) { > ???????? result.requestFocus(); > ???????? traversalEvent.consume(); > ??? } > > Note that the above code leaves the final decision to call > requestFocus up to the caller.? It also allows the caller to > distinguish between the case where there is no suitable Node in > the indicated direction and act accordingly. > > This allows it to?NOT consume the event if it prefers its Parent > to handle it (if the control doesn't want CYCLIC or CONFINED style > navigation).? It also allows it to further scrutinize the > suggested Node, and if it decides it does not like it (due to some > property or CSS style or whatever) it may follow up with another > findXXX call or some other option to pick the Node it wants.? It > also allows (in the case of no Node being found) to pick its own > preferred Node in those cases.? In other words, it is just far > more flexible. > > I'm not sure yet where to place these static helper methods (if we > decide to expose them at all initially), or even if they should be > static.? Given that its first parameter is always a Node, a > non-static location for them could simply be on Node itself, in > which case the calling convention would become "Node result? = > from.findTraversableUp()" (suggested name only) > > > Focus traversals generate a new type of event, encapsulated by > the class TraversalEvent which extends javafx.event.Event, using > the event type TraversalEvent.NODE_TRAVERSED. > > What is the point of this event?? If you want to know that focus > changed, you can add a listener to Scene.focusOwnerProperty.? What > does it mean if I filter this event?? What if I consume it?? I > don't think this should be an event at all, unless implemented as > I suggested above, where consuming/filtering/bubbling can be used > to control how controls will react to navigation events. > > --John > > On 03/09/2024 21:33, Andy Goryachev wrote: > > Dear fellow developers: > > I'd like to propose the public focus traversal API: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > > Draft PR: > > https://github.com/openjdk/jfx/pull/1555 > > > Your comments and suggestions will be warmly accepted and > appreciated. > > Thank you > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Sep 18 07:20:13 2024 From: duke at openjdk.org (duke) Date: Wed, 18 Sep 2024 07:20:13 GMT Subject: RFR: 8211247: Open-source simple test programs for FX / SWT interop In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 14:29:11 GMT, Jayathirth D V wrote: > This PR is for open-sourcing HelloFXCanvas test app. > JBS : https://bugs.openjdk.org/browse/JDK-8211247 > It is an SWT app with SWT button and an FXCanvas with animated rectangle. > This is used on our integration testing. > > This test is now moved to apps/toys, please refer to apps/toys/HelloFXCanvas/README.txt on how to run this toy. > > Also this toy hangs on exit in macOS and it crashes on Wayland in Ubuntu 24.04, for which separate bugs will be raised. @jayathirthrao Your change (at version 9576a0e8d36dc026ceb8d46fe2996517634a10b0) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1571#issuecomment-2357690010 From mhanl at openjdk.org Wed Sep 18 07:53:13 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 18 Sep 2024 07:53:13 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v10] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 13:48:50 GMT, Jay Bhaskar wrote: >> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > remove instance variables in parametrized test looks good now ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1567#pullrequestreview-2311903054 From jdv at openjdk.org Wed Sep 18 10:51:18 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 18 Sep 2024 10:51:18 GMT Subject: Integrated: 8211247: Open-source simple test programs for FX / SWT interop In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 14:29:11 GMT, Jayathirth D V wrote: > This PR is for open-sourcing HelloFXCanvas test app. > JBS : https://bugs.openjdk.org/browse/JDK-8211247 > It is an SWT app with SWT button and an FXCanvas with animated rectangle. > This is used on our integration testing. > > This test is now moved to apps/toys, please refer to apps/toys/HelloFXCanvas/README.txt on how to run this toy. > > Also this toy hangs on exit in macOS and it crashes on Wayland in Ubuntu 24.04, for which separate bugs will be raised. This pull request has now been integrated. Changeset: f8a20056 Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/f8a20056f4b19b45d311b96126b0a5fcfbe96923 Stats: 1266 lines in 9 files changed: 1263 ins; 0 del; 3 mod 8211247: Open-source simple test programs for FX / SWT interop Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1571 From kcr at openjdk.org Wed Sep 18 11:12:29 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Sep 2024 11:12:29 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: <8eyB8oGrHxeuoVlur3o5xBNURbuf7DYO3M-ZV2o-7E8=.b45b4ef8-6191-4e38-8ad6-e062b6df7fd0@github.com> On Wed, 18 Sep 2024 03:50:17 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 16 additional commits since the last revision: >> >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 12, 9274 - 185 = 9089 >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 11, 9242 tests, 185 ignored >> - part 10 >> - part 9 cell >> - part 8 >> - part 7 >> - part 6 >> - ... and 6 more: https://git.openjdk.org/jfx/compare/f9b93d88...b5270280 > > modules/javafx.controls/src/test/java/test/javafx/scene/chart/NumberAxisTest.java line 261: > >> 259: @Test >> 260: public void testCloseValues() { >> 261: assertTimeout(Duration.ofMillis(1000), () -> { > > Could use the [Timeout annotation](https://junit.org/junit5/docs/5.5.1/api/org/junit/jupiter/api/Timeout.html) as : `@Timeout(1)` or `@Timeout(1000 ms)` Yes, please. I made a similar comment on Draft PR #1569 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1764861784 From kcr at openjdk.org Wed Sep 18 12:25:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Sep 2024 12:25:22 GMT Subject: RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 18:45:45 GMT, Hima Bindu Meda wrote: > Updated additional webkit-619.1 fixes from webkitgtk-2.44.4. Build is successful on all platforms.No issues seen All my testing looks good. The code changes look good with one question that I left. modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/HistoryItemClientJava.cpp line 1: > 1: #include "HistoryItemClientJava.h" Where did this file come from? I don't see any changes related to HistoryItemClient in the 2.44.4 release of WebKitGTK? Presuming we need this file, it will need a proper copyright header. modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/HistoryItemClientJava.h line 1: > 1: #pragma once Presuming we need this file, it will need a proper copyright header. ------------- PR Review: https://git.openjdk.org/jfx/pull/1570#pullrequestreview-2312524694 PR Review Comment: https://git.openjdk.org/jfx/pull/1570#discussion_r1764957413 PR Review Comment: https://git.openjdk.org/jfx/pull/1570#discussion_r1764957887 From mhanl at openjdk.org Wed Sep 18 13:25:18 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 18 Sep 2024 13:25:18 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v2] In-Reply-To: <8eyB8oGrHxeuoVlur3o5xBNURbuf7DYO3M-ZV2o-7E8=.b45b4ef8-6191-4e38-8ad6-e062b6df7fd0@github.com> References: <8eyB8oGrHxeuoVlur3o5xBNURbuf7DYO3M-ZV2o-7E8=.b45b4ef8-6191-4e38-8ad6-e062b6df7fd0@github.com> Message-ID: On Wed, 18 Sep 2024 11:09:29 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/chart/NumberAxisTest.java line 261: >> >>> 259: @Test >>> 260: public void testCloseValues() { >>> 261: assertTimeout(Duration.ofMillis(1000), () -> { >> >> Could use the [Timeout annotation](https://junit.org/junit5/docs/5.5.1/api/org/junit/jupiter/api/Timeout.html) as : `@Timeout(1)` or `@Timeout(1000 ms)` > > Yes, please. I made a similar comment on Draft PR #1569 Agree, would be good to be consistent, especially now, where we anyway convert everything to JUnit 5 and have the chance to be consistent. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1765050711 From jdv at openjdk.org Wed Sep 18 14:05:32 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 18 Sep 2024 14:05:32 GMT Subject: RFR: 8211234: Open-source simple test programs for FX / Swing interop [v2] In-Reply-To: References: Message-ID: > This PR is for open-sourcing 2 closed toys EmbeddedSwing and HelloWorld. > JBS : https://bugs.openjdk.org/browse/JDK-8211234 > > 1)EmbeddedSwing - a simple FX test app with a SwingNode containing a Swing application > > 2)HelloWorld contains 2 test apps : > > - HelloJFXPanel - a simple Swing test app with a JButton and a JFXPanel containing an animated rectangle > > - HelloJFXPanel2 - a simple Swing test app with a JButton and a JFXPanel containing a JavaFX Button and ComboBox (with Tooltips) > > These new test apps are added under apps/toys/ directory. Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Resolve conflicts using latest upstream change - 8211234: Open-source simple test programs for FX / Swing interop ------------- Changes: https://git.openjdk.org/jfx/pull/1572/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1572&range=01 Stats: 1293 lines in 18 files changed: 1272 ins; 2 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/1572.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1572/head:pull/1572 PR: https://git.openjdk.org/jfx/pull/1572 From kcr at openjdk.org Wed Sep 18 14:05:32 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Sep 2024 14:05:32 GMT Subject: RFR: 8211234: Open-source simple test programs for FX / Swing interop [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 14:02:20 GMT, Jayathirth D V wrote: >> This PR is for open-sourcing 2 closed toys EmbeddedSwing and HelloWorld. >> JBS : https://bugs.openjdk.org/browse/JDK-8211234 >> >> 1)EmbeddedSwing - a simple FX test app with a SwingNode containing a Swing application >> >> 2)HelloWorld contains 2 test apps : >> >> - HelloJFXPanel - a simple Swing test app with a JButton and a JFXPanel containing an animated rectangle >> >> - HelloJFXPanel2 - a simple Swing test app with a JButton and a JFXPanel containing a JavaFX Button and ComboBox (with Tooltips) >> >> These new test apps are added under apps/toys/ directory. > > Jayathirth D V has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Resolve conflicts using latest upstream change > - 8211234: Open-source simple test programs for FX / Swing interop Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1572#pullrequestreview-2312798993 From kcr at openjdk.org Wed Sep 18 14:05:32 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Sep 2024 14:05:32 GMT Subject: RFR: 8211234: Open-source simple test programs for FX / Swing interop In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 15:33:06 GMT, Jayathirth D V wrote: > This PR is for open-sourcing 2 closed toys EmbeddedSwing and HelloWorld. > JBS : https://bugs.openjdk.org/browse/JDK-8211234 > > 1)EmbeddedSwing - a simple FX test app with a SwingNode containing a Swing application > > 2)HelloWorld contains 2 test apps : > > - HelloJFXPanel - a simple Swing test app with a JButton and a JFXPanel containing an animated rectangle > > - HelloJFXPanel2 - a simple Swing test app with a JButton and a JFXPanel containing a JavaFX Button and ComboBox (with Tooltips) > > These new test apps are added under apps/toys/ directory. I suspect that this might get a merge conflict when Skara notices it. I'll poke it. Ah, never mind. I see that you already resolved the conflict. I'll re-review then. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1572#issuecomment-2358553572 PR Comment: https://git.openjdk.org/jfx/pull/1572#issuecomment-2358554933 From jdv at openjdk.org Wed Sep 18 14:05:32 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 18 Sep 2024 14:05:32 GMT Subject: RFR: 8211234: Open-source simple test programs for FX / Swing interop In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 14:00:24 GMT, Kevin Rushforth wrote: > Ah, never mind. I see that you already resolved the conflict. I'll re-review then. Yes Kevin, i was pushing the changes one after another because i was also suspecting merge conflict in apps/toys/build.xml ------------- PR Comment: https://git.openjdk.org/jfx/pull/1572#issuecomment-2358559533 From jdv at openjdk.org Wed Sep 18 14:12:14 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Wed, 18 Sep 2024 14:12:14 GMT Subject: Integrated: 8211234: Open-source simple test programs for FX / Swing interop In-Reply-To: References: Message-ID: <5mXlA4cDmI3sqh4L2MsYKW1c7DCJbKDp1zErJt-uVaU=.8b616b95-b807-4e56-9f0b-c0f7613265b0@github.com> On Tue, 17 Sep 2024 15:33:06 GMT, Jayathirth D V wrote: > This PR is for open-sourcing 2 closed toys EmbeddedSwing and HelloWorld. > JBS : https://bugs.openjdk.org/browse/JDK-8211234 > > 1)EmbeddedSwing - a simple FX test app with a SwingNode containing a Swing application > > 2)HelloWorld contains 2 test apps : > > - HelloJFXPanel - a simple Swing test app with a JButton and a JFXPanel containing an animated rectangle > > - HelloJFXPanel2 - a simple Swing test app with a JButton and a JFXPanel containing a JavaFX Button and ComboBox (with Tooltips) > > These new test apps are added under apps/toys/ directory. This pull request has now been integrated. Changeset: 6d1dd293 Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/6d1dd293d690f34dc87e86edc6ec2490f6d48967 Stats: 1293 lines in 18 files changed: 1272 ins; 2 del; 19 mod 8211234: Open-source simple test programs for FX / Swing interop Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1572 From andy.goryachev at oracle.com Wed Sep 18 15:13:03 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 18 Sep 2024 15:13:03 +0000 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: Oh, sorry, I did not mean to ignore your comments. I should have mentioned we are having a bi-annual "test sprint" and work exclusively on the test suite. You made a lot of good comments that require some thought and careful consideration, for which I simply had no spare CPU cycles last week or this week. Sorry, will definitely respond in detail early next week. -andy From: John Hendrikx Date: Tuesday, September 17, 2024 at 23:05 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: Re: [External] : Re: Proposal: Focus Traversal API Andy, As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. --John On 18/09/2024 01:09, Andy Goryachev wrote: Dear John: You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. Thank you -andy From: John Hendrikx Date: Saturday, September 14, 2024 at 09:41 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Proposal: Focus Traversal API Hi Andy, First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. On 14/09/2024 00:17, Andy Goryachev wrote: Dear John, Everyone: Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: 1. move the focus traversal logic away from the components and into the Scene 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents 3. (more) standard policies 4. using CSS (there is of course more topics in your response, but let me start with the 4 above) #1 I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? There's two things here. 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. #2 This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? #3 One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). #4 The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: - I define the container hierarchy (VBox, HBox, which children go where) - I set a style name - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? -- There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. Also I think this can be implemented gradually. Here's a potential plan: 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... Public API: Limited to a new Event 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys Public API: none 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are Public API: none Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. 4. Expose policy property/properties on Parent Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. Public API: new properties on Parent 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. Benefit: less work for control implementors (although they could just "copy" said code) Public API: Maybe some methods in Node, or some kind of static helper. 6. CSS styleable properties If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). Public API: Nothing in Java, but document as CSS properties --John Thank you, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, September 11, 2024 at 19:05 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Focus Traversal API Hi Andy / List, I've given this some thought first, without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ## KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: - OPEN This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: Node from = ... switch (((KeyEvent)event).getCode()) { case UP: FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); event.consume(); break; case DOWN: // or use the convenience method FocusTraversal.traverseDown(from); event.consume(); break; } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: Node from = ... Node result = switch(traversalEvent.getEventType()) { case TraversalEvent.UP -> FocusTraversals.findUp(from); case TraversalEvent.DOWN -> FocusTraversals.findDown(from); // etc } if (result != null) { result.requestFocus(); traversalEvent.consume(); } Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkostyra at openjdk.org Wed Sep 18 15:24:53 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 18 Sep 2024 15:24:53 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 Message-ID: This PR converts all tests in `modules/javafx.graphics` to use JUnit5. ## Details Trivial changes resolved by first four commits: - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) - Message Strings in `assert*` calls moved to the end to follow 5's argument order - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations - Some test formatting unification - keeping annotations on a separate line from method definition Non-trivial changes: - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: - `DirtyRegionTestBase` - `CssMethodsTestBase` - `ObjectMethodsTestBase` - `OnInvalidateMethodsTestBase` - `PropertiesTestBase` - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` - Other classes used `@BeforeEach` annotation which accessed test parameters, that one had to be done separately At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. ## Results Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | | ------------ | ------ | ------ | | Test count | 23272 | 23275 | | Failures | 0 | 0 | | Ignored | 99 | 102 | | Successful % | 100% | 100% | The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than the whole class, so: Popup_parentWindow_Test. initializationError becomes Popup_parentWindow_Test. testBasicAccess(Configuration) Popup_parentWindow_Test. testBinding(Configuration) Popup_parentWindow_Test. testGetBean(Configuration) Popup_parentWindow_Test. testGetName(Configuration) Outside of that, the ignore list matches between both runs. I did not notice any regressions or other differences in test execution. ------------- Commit messages: - Use @Timeout annotation instead of assertTimeout - Convert remaining non-trivial tests to JUnit5 - Convert graphics tests to JUnit5 - part 4/4 - Convert graphics tests to JUnit5 - part 3/4 - Convert graphics tests to JUnit5 - part 2/4 - Convert graphics tests to JUnit5 - part 1/4 Changes: https://git.openjdk.org/jfx/pull/1566/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1566&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339512 Stats: 14465 lines in 410 files changed: 4658 ins; 2102 del; 7705 mod Patch: https://git.openjdk.org/jfx/pull/1566.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1566/head:pull/1566 PR: https://git.openjdk.org/jfx/pull/1566 From angorya at openjdk.org Wed Sep 18 15:25:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Sep 2024 15:25:17 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: <3mCn0xWaPoBGEIwpL258wr1biV7my0DlCYvFQ6TauMA=.73fd116d-ee29-4264-b959-cdf0661836db@github.com> On Sun, 15 Sep 2024 13:06:41 GMT, Marius Hanl 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 16 additional commits since the last revision: >> >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 12, 9274 - 185 = 9089 >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 11, 9242 tests, 185 ignored >> - part 10 >> - part 9 cell >> - part 8 >> - part 7 >> - part 6 >> - ... and 6 more: https://git.openjdk.org/jfx/compare/da047848...b5270280 > > modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/MouseEventFirerTest.java line 203: > >> 201: // ------------- parameterized in not/alternative mouseEvent creation >> 202: >> 203: public static Collection data() { > > Minor: Could also be simplified with the argument stream this was fixed in one of the subsequent commits. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1765271810 From lkostyra at openjdk.org Wed Sep 18 15:25:47 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 18 Sep 2024 15:25:47 GMT Subject: RFR: 8339508: RenderPerf Test Application [v2] In-Reply-To: References: Message-ID: > This PR migrates RenderPerf performance test application from jfx-sandbox metal branch: https://github.com/openjdk/jfx-sandbox/tree/metal/tests/performance/animation/RenderPerfTest/src/renderperf > > RenderPerf is a performance test application which draws provided number of "particles" (JFX nodes) on the screen and animates them. After some time (default 10 seconds of testing + warmup) the test automatically closes and reports FPS values. Test was developed as part of Metal backend for performance testing and we decided to integrate it with mainline for any potential further development and fixes. > > Command line options for the test: > - `-n` - number of particles to draw, defaults to 1000 > - `-t` - name of test to run, defaults to running all tests in random order. Can provide multiple tests, ex. `-t Rectangle Image` > - `-d` - test duration in seconds, defaults to 10. Can be set to 0, which means the test will run infinitely long and end only when user manually closes the stage, mostly useful for stability testing. > > Some tests use `duke.png` image provided with this PR. This is an openly available Duke Wave image taken from https://wiki.openjdk.org/display/duke/Gallery and rescaled for test purposes. > > PR consists of two commits: > - Base version of RenderPerfTest developed by @karthikpandelu > - My commit adding `-d` flag and implementing plenty of other fixes as part of [JDK-8331570](https://bugs.openjdk.org/browse/JDK-8331570) Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Update copyright year to 2024 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1568/files - new: https://git.openjdk.org/jfx/pull/1568/files/b8f34829..731b8801 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1568&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1568&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1568.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1568/head:pull/1568 PR: https://git.openjdk.org/jfx/pull/1568 From angorya at openjdk.org Wed Sep 18 15:29:14 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Sep 2024 15:29:14 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v2] In-Reply-To: References: <8eyB8oGrHxeuoVlur3o5xBNURbuf7DYO3M-ZV2o-7E8=.b45b4ef8-6191-4e38-8ad6-e062b6df7fd0@github.com> Message-ID: On Wed, 18 Sep 2024 13:22:45 GMT, Marius Hanl wrote: >> Yes, please. I made a similar comment on Draft PR #1569 > > Agree, would be good to be consistent, especially now, where we anyway convert everything to JUnit 5 and have the chance to be consistent. yep, for some reason I incorrectly decided that Timeout was not applicable. will change to Timeout. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1765277494 From angorya at openjdk.org Wed Sep 18 15:36:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Sep 2024 15:36:53 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: > Converting control module tests to junit5. > > The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ## JUnit5 Migration Notes > > Most of the changes are trivial, except for the following: > > 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) > 2. parameterized tests: junit5 allows for parameterizing individual tests > 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) > 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes > 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` > > ### Parameterized Class-Level Tests > > junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) > > The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. > > To summarize: > - remove `@Before` from the setup method > - call the setup method from each parameterized method (adding parameters and replacing `@Test` with > > @ParameterizedTest > @MethodSource("parameters") > > where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: > > private static Stream parameters() { > return Stream.of( > Arguments.of("a", 1), > Arguments.of("foo", 3) > ); > } > > > ### Migration Tricks > > Here are the steps that might speed up the process: > > 1. remove all the junit4 imports > 2. paste the following junit5 imports (below) > 3. fix the errors > 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) > 7. after all is done, verify that there is no more junit4 names by running the command mentioned below > > junit5 imports (in no particular order): > > import org.junit.jupiter.api.AfterEach; > import org.junit.jupiter.api.BeforeEach; > import org.junit.jupiter.api.Test; > import org.junit.jupiter.api.Disabled; > import org.junit.jupiter.params.ParameterizedTest; > imp... 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 18 additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - review comments - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - part 12, 9274 - 185 = 9089 - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - part 11, 9242 tests, 185 ignored - part 10 - part 9 cell - part 8 - ... and 8 more: https://git.openjdk.org/jfx/compare/7a57d583...55b33b2c ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1561/files - new: https://git.openjdk.org/jfx/pull/1561/files/b5270280..55b33b2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1561&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1561&range=01-02 Stats: 240 lines in 32 files changed: 64 ins; 28 del; 148 mod Patch: https://git.openjdk.org/jfx/pull/1561.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1561/head:pull/1561 PR: https://git.openjdk.org/jfx/pull/1561 From arapte at openjdk.org Wed Sep 18 16:11:10 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 18 Sep 2024 16:11:10 GMT Subject: RFR: 8339508: RenderPerf Test Application [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 15:25:47 GMT, Lukasz Kostyra wrote: >> This PR migrates RenderPerf performance test application from jfx-sandbox metal branch: https://github.com/openjdk/jfx-sandbox/tree/metal/tests/performance/animation/RenderPerfTest/src/renderperf >> >> RenderPerf is a performance test application which draws provided number of "particles" (JFX nodes) on the screen and animates them. After some time (default 10 seconds of testing + warmup) the test automatically closes and reports FPS values. Test was developed as part of Metal backend for performance testing and we decided to integrate it with mainline for any potential further development and fixes. >> >> Command line options for the test: >> - `-n` - number of particles to draw, defaults to 1000 >> - `-t` - name of test to run, defaults to running all tests in random order. Can provide multiple tests, ex. `-t Rectangle Image` >> - `-d` - test duration in seconds, defaults to 10. Can be set to 0, which means the test will run infinitely long and end only when user manually closes the stage, mostly useful for stability testing. >> >> Some tests use `duke.png` image provided with this PR. This is an openly available Duke Wave image taken from https://wiki.openjdk.org/display/duke/Gallery and rescaled for test purposes. >> >> PR consists of two commits: >> - Base version of RenderPerfTest developed by @karthikpandelu >> - My commit adding `-d` flag and implementing plenty of other fixes as part of [JDK-8331570](https://bugs.openjdk.org/browse/JDK-8331570) > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2024 LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1568#pullrequestreview-2313173167 From martin at martinfox.com Wed Sep 18 18:49:31 2024 From: martin at martinfox.com (Martin Fox) Date: Wed, 18 Sep 2024 11:49:31 -0700 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: John, Sorry I didn?t respond to this thread earlier. I?ve been looking at the code and bug database trying to work backward to a problem statement. The bug reports cited in the PR are light on details so I?m trying to come up with a more concrete set of use cases to consider. Currently I?m failing to see the benefit of a traversal event model. > - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). > It doesn?t really matter whether the control is capturing the key event and invoking the traversal engine directly or firing off a TraversalEvent. The problem is that the control is processing the key event in the first place. You?re talking about something that happens before traversal is even initiated. It?s unfortunate that the code snippet in the proposal shows a control doing a direct mapping from KeyCodes to traversal calls. That?s not how the current system is intended to work. There?s already a dispatcher at the Scene level that processes KeyEvents and invokes the traversal machinery so controls should just let the traversal keys bubble up. There are exceptions to this throughout the code which I would like to get a better handle on since I can?t tell if they?re bugs or truly necessary exceptions. Once the system has determined that it?s time for traversal it needs to map from a KeyEvent to a direction and type. I can see where providing a centralized API for doing this could be of benefit but I?m not sure that has anything to do with this PR or the concept of TraversalEvents. This is also a decision made before traversal is initiated. You give some examples of customizing traversal in various ways. From what I can tell all of them can be accomplished using this PR with maybe one exception that I?ll get to when I respond to Andy?s proposal. In other cases I can?t tell if a TraversalEvent would provide a cleaner implementation because I don?t understand how they would work. For example, one could imagine a system where a TraversalEvent is fired by the Scene and expected to bubble back up to the Scene which will then utilize the existing centralized engines to actually perform the traversal. But one could also imagine a system where the Scene fires a TraversalEvent and the nodes act on them directly as it bubbles up. I?m not sure what you have in mind. It would be nice to see some examples of how a TraversalEvent would move through the system in various scenarios particularly when traversing laterally. Martin > On Sep 17, 2024, at 11:05?PM, John Hendrikx wrote: > > Andy, > > As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. > > --John > > On 18/09/2024 01:09, Andy Goryachev wrote: >> Dear John: >> >> You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: >> >> 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. >> >> 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. >> >> I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. >> >> Thank you >> -andy >> >> >> From: John Hendrikx >> Date: Saturday, September 14, 2024 at 09:41 >> To: Andy Goryachev , openjfx-dev at openjdk.org >> Subject: [External] : Re: Proposal: Focus Traversal API >> >> Hi Andy, >> >> First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. >> >> An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. >> >> Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. >> >> On 14/09/2024 00:17, Andy Goryachev wrote: >> Dear John, Everyone: >> >> Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: >> >> 1. move the focus traversal logic away from the components and into the Scene >> 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents >> 3. (more) standard policies >> 4. using CSS >> >> (there is of course more topics in your response, but let me start with the 4 above) >> >> #1 >> >> I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? >> There's two things here. >> >> 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). >> >> 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. >> >> I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. >> >> Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. >> >> >> #2 >> >> This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. >> I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? >> >> >> #3 >> >> One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. >> Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. >> >> I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). >> >> >> #4 >> >> The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. >> I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. >> >> Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: >> >> - I define the container hierarchy (VBox, HBox, which children go where) >> - I set a style name >> - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). >> >> All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? >> >> -- >> >> There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. >> "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. >> >> I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. >> >> This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. >> >> Also I think this can be implemented gradually. Here's a potential plan: >> >> 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents >> >> Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... >> >> Public API: Limited to a new Event >> >> 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent >> >> This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. >> >> Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys >> >> Public API: none >> >> 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) >> >> Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. >> >> Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are >> >> Public API: none >> >> Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. >> >> 4. Expose policy property/properties on Parent >> >> Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. >> >> Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. >> >> Public API: new properties on Parent >> 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. >> >> This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. >> >> Benefit: less work for control implementors (although they could just "copy" said code) >> >> Public API: Maybe some methods in Node, or some kind of static helper. >> >> 6. CSS styleable properties >> >> If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. >> >> Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). >> >> Public API: Nothing in Java, but document as CSS properties >> >> --John >> >> >> Thank you, >> -andy >> >> >> >> >> From: openjfx-dev on behalf of John Hendrikx >> Date: Wednesday, September 11, 2024 at 19:05 >> To: openjfx-dev at openjdk.org >> Subject: Re: Proposal: Focus Traversal API >> >> Hi Andy / List, >> >> I've given this some thought first, without looking too much at the proposal. >> >> In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). >> >> ## KeyEvent and TraversalEvent separation >> >> I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. >> >> This separation of KeyEvents into TraversalEvents achieves the following: >> >> - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. >> >> - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. >> >> - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. >> >> ## Traversal Policy Properties on Parent >> >> I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. >> >> In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). >> >> These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). >> >> Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). >> >> - logicalTraversalPolicy >> - directionalTraversalPolicy >> >> The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: >> >> - OPEN >> >> This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. >> >> - CONFINED >> >> This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. >> >> - CYCLIC >> >> Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. >> >> - IGNORED >> >> This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. >> >> Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. >> >> ## Use Cases >> >> 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) >> Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. >> >> 2) User wants to act on Traversal events that the standard policy leaves to bubble up >> >> Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). >> >> 3) User wants to do crazy custom navigation >> >> Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. >> >> 4) User wants to change what keys are considered navigation keys >> >> Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event >> >> 5) User wants to use keys that are considered navigation keys for their own purposes >> >> Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them >> >> 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely >> >> With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. >> >> ----- >> >> About the Proposal: >> >> I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. >> >> I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. >> >> Motivation looks okay. >> >> > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. >> >> I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. >> >> About your typical example: >> >> Node from = ... >> switch (((KeyEvent)event).getCode()) { >> case UP: >> FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); >> event.consume(); >> break; >> case DOWN: >> // or use the convenience method >> FocusTraversal.traverseDown(from); >> event.consume(); >> break; >> } >> >> I think this is not a good way to deal with events. >> >> 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? >> >> 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. >> >> 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. >> >> So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: >> >> Node from = ... >> >> Node result = switch(traversalEvent.getEventType()) { >> case TraversalEvent.UP -> FocusTraversals.findUp(from); >> case TraversalEvent.DOWN -> FocusTraversals.findDown(from); >> // etc >> } >> >> if (result != null) { >> result.requestFocus(); >> traversalEvent.consume(); >> } >> >> Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. >> >> This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. >> >> I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) >> >> > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. >> >> What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. >> >> --John >> >> >> >> >> >> On 03/09/2024 21:33, Andy Goryachev wrote: >> >> Dear fellow developers: >> >> I'd like to propose the public focus traversal API: >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md >> >> Draft PR: >> >> https://github.com/openjdk/jfx/pull/1555 >> >> Your comments and suggestions will be warmly accepted and appreciated. >> >> Thank you >> >> -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Wed Sep 18 20:30:01 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Sep 2024 20:30:01 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 Message-ID: Converting system tests to junit5. Please see migration notes: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md ### Notes: I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) QPathTest > executionError FAILED org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) at app//test.util.Util.runAndWait(Util.java:156) at app//test.util.Util.runAndWait(Util.java:127) at app//test.util.Util.shutdown(Util.java:365) at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) This test might fail intermittently (?) on linux only: SetSceneScalingTest > testShowAndSetScene() FAILED org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) ------------- Commit messages: - fixes 4 - fixes 3 - fixes 2 - fixes 1 - part 12 last - fixes - part 11 scene - part 10 swing - part 9 monocle - Merge remote-tracking branch 'origin/master' into 8339510.junit5.system - ... and 9 more: https://git.openjdk.org/jfx/compare/5993c09e...96cd1972 Changes: https://git.openjdk.org/jfx/pull/1569/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339510 Stats: 5070 lines in 276 files changed: 916 ins; 948 del; 3206 mod Patch: https://git.openjdk.org/jfx/pull/1569.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1569/head:pull/1569 PR: https://git.openjdk.org/jfx/pull/1569 From kcr at openjdk.org Wed Sep 18 20:30:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Sep 2024 20:30:05 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: References: Message-ID: <4xIHgDIwu6ozFMMKoQUGSQW43VkqJr1JcSuqS-2Jo2M=.4f68d03b-8f9c-41c5-aca9-08a48ceda5c9@github.com> On Mon, 16 Sep 2024 17:57:07 GMT, Andy Goryachev wrote: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) I spot checked many of the classes, and most of the changes look reasonable. One question, though: Why did you replace the per-test timeout with an in-method annotation in many places (especially in the early classes I looked at)? There is a direct replacement in JUnit 5 for the per-test timeout, which seems a more straightforward change. I also think an explicit timeout on the test (or class, if all `@Test` methods have the same timeout) will work more consistently with my in-progress fix to add a global timeout. Testing recommendation: do a test run with `gradle -PUNSTABLE_TEST=true` so that all the tests that aren't disabled are run. tests/system/src/test/java/test/com/sun/javafx/application/ConcurrentStartupTest.java line 46: > 44: @Test > 45: public void testStartupReturnBeforeRunnableComplete() { > 46: assertTimeout(Duration.ofMillis(15000), () -> { Why not use an `@Timeout` annotation on the method? That would have been the natural change. tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunch1Test.java line 42: > 40: @Test > 41: public void testLaunchThenLaunchInFX() throws Exception { > 42: assertTimeout(Duration.ofMillis(15000), () -> { Same comment as previous. Why not add an `@Timeout` annotation? tests/system/src/test/java/test/util/Util.java line 68: > 66: public static void throwError(Throwable e) { > 67: fail(e); > 68: } This is not an equivalent change. In the former code, if `testError` was a RuntimeException it was thrown directly and not wrapped. I recommend reverting this change, and then replacing only the two blocks that wrap the throwable in an AssertionError with `fail(testError)`. ------------- PR Review: https://git.openjdk.org/jfx/pull/1569#pullrequestreview-2311357616 PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2357243613 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1764218765 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1764227387 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1764234743 From angorya at openjdk.org Wed Sep 18 20:30:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Sep 2024 20:30:07 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: <4xIHgDIwu6ozFMMKoQUGSQW43VkqJr1JcSuqS-2Jo2M=.4f68d03b-8f9c-41c5-aca9-08a48ceda5c9@github.com> References: <4xIHgDIwu6ozFMMKoQUGSQW43VkqJr1JcSuqS-2Jo2M=.4f68d03b-8f9c-41c5-aca9-08a48ceda5c9@github.com> Message-ID: On Wed, 18 Sep 2024 00:20:39 GMT, Kevin Rushforth wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > Testing recommendation: do a test run with `gradle -PUNSTABLE_TEST=true` so that all the tests that aren't disabled are run. @kevinrushforth @lukostyra @arapte please review jenkins run: https://java.se.oracle.com/jenkins/rejfx/job/jfx-submit-headful/230/ all green, except for linux, where one test fails consistently (https://bugs.openjdk.org/browse/JDK-8340403), and one seems to be intermittent, as I have not seen it failing during the previous run, and I don't think my changes contributed to the failure. > tests/system/src/test/java/test/com/sun/javafx/application/ConcurrentStartupTest.java line 46: > >> 44: @Test >> 45: public void testStartupReturnBeforeRunnableComplete() { >> 46: assertTimeout(Duration.ofMillis(15000), () -> { > > Why not use an `@Timeout` annotation on the method? That would have been the natural change. my mistake. switched to the Timeout annotation. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2359314178 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765288156 From angorya at openjdk.org Wed Sep 18 20:30:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Sep 2024 20:30:09 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: References: <4xIHgDIwu6ozFMMKoQUGSQW43VkqJr1JcSuqS-2Jo2M=.4f68d03b-8f9c-41c5-aca9-08a48ceda5c9@github.com> Message-ID: On Wed, 18 Sep 2024 15:31:40 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/com/sun/javafx/application/ConcurrentStartupTest.java line 46: >> >>> 44: @Test >>> 45: public void testStartupReturnBeforeRunnableComplete() { >>> 46: assertTimeout(Duration.ofMillis(15000), () -> { >> >> Why not use an `@Timeout` annotation on the method? That would have been the natural change. > > my mistake. switched to the Timeout annotation. fixed ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765652815 From angorya at openjdk.org Wed Sep 18 21:06:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Sep 2024 21:06:41 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: <4xIHgDIwu6ozFMMKoQUGSQW43VkqJr1JcSuqS-2Jo2M=.4f68d03b-8f9c-41c5-aca9-08a48ceda5c9@github.com> References: <4xIHgDIwu6ozFMMKoQUGSQW43VkqJr1JcSuqS-2Jo2M=.4f68d03b-8f9c-41c5-aca9-08a48ceda5c9@github.com> Message-ID: On Wed, 18 Sep 2024 00:20:39 GMT, Kevin Rushforth wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > Testing recommendation: do a test run with `gradle -PUNSTABLE_TEST=true` so that all the tests that aren't disabled are run. @kevinrushforth @lukostyra @arapte please review ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2359401006 From angorya at openjdk.org Wed Sep 18 21:20:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Sep 2024 21:20:45 GMT Subject: RFR: 8339515: [TestBug] Convert web tests to JUnit 5 [v10] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 13:48:50 GMT, Jay Bhaskar wrote: >> Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > remove instance variables in parametrized test - query for old imports produces 0 hits (good) - left some minor comments, one (assertArrayEquals) might need a code change modules/javafx.web/src/test/java/test/com/sun/webkit/network/CookieTest.java line 581: > 579: assertEquals("/foo", CookieShim.defaultPath(uri("http://hostname/foo/bar?"))); > 580: assertEquals("/foo", CookieShim.defaultPath(uri("http://hostname/foo/bar?query"))); > 581: assertEquals("/foo", CookieShim.defaultPath(uri("http://hostname/foo/bar?query=push"))); minor: just wanted to say these formatting changes are probably unnecessary, and there is an added value of being able to set a breakpoint on the CookieShim method that was lost. having said that, the changes are ok. modules/javafx.web/src/test/java/test/javafx/scene/web/FileReaderTest.java line 246: > 244: String message = String.format("File at %s: Expected length %d but got %d", > 245: filePath, expectedLength, actualLength); > 246: assertEquals(expectedLength, actualLength, message); I think all this new code can be replaced by `assertArrayEquals` modules/javafx.web/src/test/java/test/javafx/scene/web/JavaScriptBridgeTest.java line 693: > 691: final JSObject doc = (JSObject) executeScript("document"); > 692: loadContent("

    "); > 693: assertThrows(NullPointerException.class, () -> { I think this is not an equivalent change: before, the tests expected NPE to come from any statement within the test body, after, it only expects from line 695 I don't know where the NPE actually comes from (probably from execute, so in theory the test might still be correct) (this comment applies to multiple places) modules/javafx.web/src/test/java/test/javafx/scene/web/MiscellaneousTest.java line 155: > 153: // Try accessing the resultObject created in JavaFX Application Thread > 154: // from someother thread. It should throw an exception. > 155: assertThrows(IllegalStateException.class, () -> { on second thought, I think this and the previous changes, even though not technically equivalent, are perfectly fine, in the spirit of the test. ------------- PR Review: https://git.openjdk.org/jfx/pull/1567#pullrequestreview-2313724822 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1765677624 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1765701013 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1765707526 PR Review Comment: https://git.openjdk.org/jfx/pull/1567#discussion_r1765722359 From angorya at openjdk.org Wed Sep 18 22:56:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Sep 2024 22:56:39 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... first batch of comments. will continue tomorrow from ObjectMethodsTestBase.java modules/javafx.graphics/src/test/java/test/com/sun/javafx/font/PrismFontFactoryTest.java line 65: > 63: public void tearDown() { > 64: } > 65: this is good. modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/DirtyRegionClipTest.java line 66: > 64: // We will populate this list with the parameters with which we will test. > 65: // Each Object[] within the params is composed of a Creator and a Polluter. > 66: Stream params = Stream.empty(); I think junit5 also accepts a `List` modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java line 76: > 74: return Stream.concat(stream, Stream.of(arg)); > 75: } > 76: same comment: `List` might also work (here and possibly elsewhere, I don't want to add duplicate comments) modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java line 333: > 331: Math.min(expected.getMaxY() + 1, dirtyRegion.getMaxY())); > 332: // Now make the check, and print useful error information in case it fails. > 333: assertEquals(expected, dirtyRegion); should probably avoid dropping creator/polluter from output modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java line 431: > 429: private void assertOnlyTheseNodesWereAskedToAccumulateDirtyRegions(NGNode start, Set nodes) { > 430: assertEquals( > 431: "creator=" + creator + ", polluter=" + polluter, same comment here (and possibly elsewhere) one thing you could do is to retain instance variables, just set them in the setup method - this should be safe, I don't think junit will invoke test methods for the same instance from multiple threads. modules/javafx.graphics/src/test/java/test/com/sun/javafx/test/CssMethodsTestBase.java line 113: > 111: } > 112: > 113: public static Arguments config(final Configuration configuration) { I think this can be simplified: use Configuration directly, no need to wrap it into Arguments. But this code will work too. ------------- PR Review: https://git.openjdk.org/jfx/pull/1566#pullrequestreview-2313918810 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1765796331 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1765836676 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1765841780 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1765844768 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1765849330 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1765854608 From kcr at openjdk.org Wed Sep 18 23:31:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Sep 2024 23:31:47 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 17:57:07 GMT, Andy Goryachev wrote: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) The code changes look good with a few comments. I ran a full test including unstable tests. I see a few failures that you will want to look at (beyond what I would expect for the unstable Monocle tests). I'll add a comment with more detail. tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 139: > 137: // Should throw IllegalStateException > 138: tmpScene.snapshot(p -> { > 139: throw new RuntimeException("Should never get here"); Suggestion: Use `fail`, rather than changing the Error into a RuntimeException. tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 169: > 167: // Should throw IllegalStateException > 168: tmpNode.snapshot(p -> { > 169: throw new RuntimeException("Should never get here"); Use `fail` instead? tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 265: > 263: // Should not get here > 264: latch.countDown(); > 265: throw new RuntimeException("Should never get here"); Use `fail` instead? tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 387: > 385: // Should not get here > 386: latch.countDown(); > 387: throw new RuntimeException("Should never get here"); Use `fail` instead? tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java line 182: > 180: public void testSnapshotEmptyNodeImmNoParams(boolean live, boolean useImage) { > 181: setupEach(live, useImage); > 182: doTestSnapshotEmptyNodeDefer(live, useImage, null); Question about the pattern: did you consider having the setupEach method store the params in instance variables (the ones you removed)? Then you wouldn't have needed to change any of the other methods to pass them to those methods. Just a thought that occurred to me as I was looking at this. What you have is fine. tests/system/src/test/java/test/javafx/scene/UIRenderSnapToPixelTest.java line 76: > 74: Assertions.assertEquals(0, ((sp.snappedBottomInset() * scale) + epsilon) % 1, 0.0001, "Bottom inset not snapped to pixel"); > 75: Assertions.assertEquals(0, ((sp.snappedLeftInset() * scale) + epsilon) % 1, 0.0001, "Left inset not snapped to pixel"); > 76: Assertions.assertEquals(0, ((sp.snappedRightInset() * scale) + epsilon) % 1, 0.0001, "Right inset not snapped to pixel"); Minor: these lines are geting a bit long. Maybe use static imports? tests/system/src/test/java/test/javafx/scene/shape/meshmanagercacheleaktest/MeshManagerCacheLeakTest.java line 44: > 42: * Unit test for verifying leak with cache of TriangleMesh in PredefinedMeshManager. > 43: */ > 44: @Timeout(value=15000, unit=TimeUnit.MILLISECONDS) One of the tests had a 20 second timeout, so this could make that test less stable. I recommend changing this to 20 sec. tests/system/src/test/java/test/robot/javafx/embed/swing/NonFocusableJFXPanelTest.java line 51: > 49: import static org.junit.jupiter.api.Assertions.assertNotNull; > 50: import static org.junit.jupiter.api.Assertions.assertNull; > 51: import static org.junit.jupiter.api.Assertions.assertSame; I promised myself I wasn't going to look at the imports, but... Does Eclipse really mix static and non-static imports? And are any of the static imports actually used? I suspect not in both cases, so you might just need to have Eclipse fix up your imports. tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodePlatformExitCrashTest.java line 39: > 37: > 38: @Test > 39: @Disabled("JDK-8190329") Unrelated to your PR...well this is embarrassing! I just fixed the FX clone of JDK-8190329 a couple weeks ago, and forgot to look to see if there was an existing test. I'll file a follow-up bug for this. tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 61: > 59: import static org.junit.jupiter.api.Assertions.assertFalse; > 60: import static org.junit.jupiter.api.Assertions.assertNotNull; > 61: import static org.junit.jupiter.api.Assertions.assertNull; Unused imports? tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 249: > 247: // Timeout for potential hang on XWayland, see JDK-8335468. > 248: // the same timeout will apply to the rest of the tests > 249: // @Test(timeout = 15000) I would remove this commented out line, since it is a JUnit 4 holdover. Also, would it be better to apply the `@Timeout` annotation to just this method? Either is fine with me. tests/system/src/test/java/test/robot/javafx/web/TooltipFXTest.java line 50: > 48: import test.util.memory.JMemoryBuddy; > 49: > 50: @Timeout(value=15000, unit=TimeUnit.MILLISECONDS) This should be 20 seconds to match the test method you moved it from. ------------- PR Review: https://git.openjdk.org/jfx/pull/1569#pullrequestreview-2313831535 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765758123 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765760215 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765760327 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765760553 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765766941 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765770244 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765797326 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765861443 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765864042 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765866196 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765867552 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765869762 From kcr at openjdk.org Wed Sep 18 23:31:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Sep 2024 23:31:47 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: References: <4xIHgDIwu6ozFMMKoQUGSQW43VkqJr1JcSuqS-2Jo2M=.4f68d03b-8f9c-41c5-aca9-08a48ceda5c9@github.com> Message-ID: On Wed, 18 Sep 2024 20:04:47 GMT, Andy Goryachev wrote: >> my mistake. switched to the Timeout annotation. > > fixed Thanks for fixing this. Btw, I see a few now-used imports of `org.junit.jupiter.api.Assertions.assertTimeout`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1765741410 From kcr at openjdk.org Wed Sep 18 23:34:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Sep 2024 23:34:38 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 17:57:07 GMT, Andy Goryachev wrote: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) You may have already seen this in your testing. When I run with `-PUNSTABLE_TEST=true` I get many failures -- more than I would expect. Here are two examples: InputDevicePropertyTest > testTouch(TestTouchDevice) > [1] SingleTouchDevice1 FAILED java.lang.IllegalStateException: Toolkit not initialized repeated for each of the parameters and each parameterized test method. So either that test has a preexisting problem, or there is an initialization problem related to the parametrized test change. RotateTest > testRotateLeftBigSteps(TestTouchDevice) > [1] EGalaxMultiTouchDevice1 FAILED java.lang.NullPointerException: Cannot invoke "test.robot.com.sun.glass.ui.monocle.input.devices.TestTouchDevice.getPressedPoints()" because "this.device" is null at test.robot.com.sun.glass.ui.monocle.RotateTest.releaseAll(RotateTest.java:75) repeated for all parameters. This one looks closely related to the parameterized test change. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2359624794 From jbhaskar at openjdk.org Thu Sep 19 00:58:45 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 19 Sep 2024 00:58:45 GMT Subject: Integrated: 8339515: [TestBug] Convert web tests to JUnit 5 In-Reply-To: References: Message-ID: <-HX6onUWXrV52WeeaS6bWEOFkGqlKmSowC55hk2vVjU=.87986b4e-789c-4b1f-ba6d-8797a868b05a@github.com> On Sun, 15 Sep 2024 12:31:03 GMT, Jay Bhaskar wrote: > Successfully converted web tests from JUnit 4 to JUnit 5, ensuring all tests are fully compliant with the JUnit 5 framework. This pull request has now been integrated. Changeset: e81b6766 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/e81b676629f281e526f2e37af2b5a82b6c28bc6e Stats: 1173 lines in 46 files changed: 117 ins; 142 del; 914 mod 8339515: [TestBug] Convert web tests to JUnit 5 Reviewed-by: mhanl, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1567 From nlisker at gmail.com Thu Sep 19 01:10:31 2024 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 19 Sep 2024 04:10:31 +0300 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: Finally getting to this. To add to what Michael said about the development process, there are many large ongoing efforts in various stages (interest gathering, proposals, discussions, PRs...) that require a lot of investment from the maintainers. From the top of my head: various CSS changes + reimplementation idea, Rich Text control, Behavior/Input/Skin decomposition, Focus traversal policies, listeners reimplementation and a few others. People work in parallel on whichever of these topics they want. Usually there is a quickish response (a few days tops) that amounts to "makes sense" or "doesn't make sense", and then the discussion and research starts. Colored Vertices is definitely a "makes sense", but *how* to do the API for a backwards-compatible library is not trivial. I'll start by answering your questions and then give some thoughts on the API and the larger 3D picture. ### Q&A *1) Eg: I either want an explanation of the workflow for Metal. How I will > be including vertex colors (a feature which hasn't officially been merged > yet!!) in Metal, or will I wait until vertex colors are officially merged > before adding support to Metal? I'm fine with either, I just want the > process laid out for me.* The details about Metal will have to wait until Kevin or one of the engineers that work on it will give the answers. This feature is not hindered by Metal not being done, it just means that when Metal is sufficiently done, it will need to implement the additional API here. > *2) Where can I get contact info for those who are working on Metal > support? Looking for a lead or someone prominent.* Here, but it can take some time, especially with very long discussions like this one. > 3) Can I get some clarification on expectations for contribution? The feature, from *my* assessment, gained enough public support to show that it's relevant (I, you, Michael, Risto and the original JBS issue author). I don't think Kevin objects to the idea either. In your proposal you also say "I can point out various JavaFX projects which... explicitly said they'd like vertex color support", so while I don't know who they are, it could strengthen your case if required. The proposal and draft PR are in a good state. Now you need to wait to get feedback, which is what I have been looking at on and off since the weekend. The API is the critical part here and I suspect this is where contention will come from (myself included, see below). Don't worry about JBS tickets right now. It's part of the formal process and they can be changed at any time when needed. You will also need a CSR (a JBS issue for detailing the API changes), which you should wait with anyway until we know what the API is. * -> 3a) How long does it generally take to get responses on low priority > feature proposals? I have no reference for what to temper my expectations > against, which would help me a lot. Should I expect it to take a week > before Kevin weighs in? Two weeks? One month? 6 months? One year? I've seen > projects with response times covering the whole spectrum, and I just don't > know where to set my expectations for when it is appropriate to follow-up > on an email which hasn't gotten a reply. * Depends on the current load, which is currently high (see my introduction :) ). Give it another week. > * -> 3b) Every single other recent active PR besides mine has had a review > comment from at least one other person, including ones created after mine. > How should I interpret this besides me having done something wrong? At what > point should I ask for a follow-up and for people to review it if I don't > hear back from anyone?* Probably because these PRs have had their discussion finished already, or are not new features that require discussions. Regular maintenance like bug fixes is faster. There is no FIFO/LIFO queue. *4) How long should I expect before my OCA signature is reviewed? I > submitted it around 2 weeks ago at this point, and I don't think it's been > reviewed yet, which is significantly longer than the website stated it > would take.* This is not up to OpenJFX. Usually it takes up to 2 weeks. In any case, it needs to be completed by the time of PR integration, so it's far from a blocker. *5) **Why does the Direct3D 3D pipeline appear to use fixed vertex buffer > definitions in the D3D calls, as opposed to making a more modern vertex > buffer definition?* I don't know. This was done over 15 years ago. Possibly because it's easier (the pipeline does the work for you). If changing to the dynamic way offers enough benefits and someone wants to take that work on, I would assume they could. > *6) Why was your PR for #1281 not labelled as a draft PR or WIP? If I > follow the contribution guidelines, I think it should be labelled as a > draft? Hoping for some clarification.* Because it was ready to be reviewed. It does not have any new API and it was mostly alignment of D3D with ES2. *7) Do you mind sending out a reply to the original thread so I am able to > reply to it instead of violating the contribution guidelines? Thanks!* OK > *8) Where am I currently in the contribution guide? What is the next > steps? What is expected from me?* See 3. *9) What is some reasonable criteria for me to use.* See my first paragraph. There are no strict timings. I would say about a week with no response, or after someone says "I'll get to it on ___" but doesn't, is reasonable. ### Feedback on the API I'm not yet convinced that new vertex formats are the way to go. The reason is the telescopic expansion we will face if we want to introduce another per-vertex data. I don't know what addition it could be because I haven't gone over all the source material I want to, but it's enough that there's 1 more "foo" feature and now the vertex format grows to 8 variants(!). And the complexity of yes/no normals, yes/no colors, yes/no foo in terms of how the arrays are treated is going to be too large. Unless I'm convinced that there will be no more such additions, I would think about another way of doing this. I found this 3D library (that I've not heard of before) that has many vertex format combinations [0]. Subclassing falls into a reciprocal problem. Suppose we define a ColoredTriangleMesh where the current vertex formats act the same way, but the color data is required (otherwise don't use this subclass). Now if we have a "foo" vertex property, what do we subclass? If we subclass TriangleMesh, it means that we can't have both a Colored and a Foo'd TriangleMesh. If we subclass ColoredTriangleMesh, we force all FooTriangleMesh to also be colored. And then we can ask why not invert the inheritance. So instead of having too much data in one class, we have too little. Sometimes these types of problems are solved with a builder pattern, though I don't know if there is a suitable parallel here. As for aligning with the current class design, I'm not sure that it's a good design to begin with. Having data (normals and face smoothing groups) that is only relevant depending on another parameter (vertex format) isn't known to be good design nowadays. This dual mode class reminds me of Scanner [1]. I wouldn't be surprised if the designers of the class thought that this is fine as long as the triangle mesh doesn't get more attributes later, and we might be repeating sins of the past. I'll need to play around with some local prototypes to see if I can come up with something more appetizing. ### On the topic of 3D in JavaFX As someone who has done a lot of work in this area, I would be one of the first proponents of developing it further. As Risto Vaher said in this thread, it could be a huge boon for JavaFX if modernized. I don't mean that it should be a competitor to a bonafide gaming engine with immersive graphics (usually requiring volumetric lighting or ray tracing), but there are many other genres that aren't *that* graphically demanding that JavaFX could certainly be used for with proper updates. Scientific applications also have a decent need for 3D visualizations that JavaFX could serve, these tend to require more in the way of performance than fanciness; think many-particle systems, anatomical modeling etc. Oracle has been investing in creating a Metal pipeline seeing as OpenGL is being deprecated in MacOS. It's a large investment. I've laid out foundations in #1281 for common missing texture features like sampling/filtering, wrapping, and mipmaps. It also needs to be done carefully, though #1281 is all internal so it can afford some misses. There are other common missing features, like stenciling techniques such as shape outlining (usually used for highlight on hover) and basic shadows; other primitives such as points and lines [2] that are used in particle effects; HDR lighting and so on. If contributors want to take these on, I think that would help bring 3D to a more prominent state. Discussion on this topic should be done separately. - Nir [0] https://cesium.com/learn/cesiumjs/ref-doc/VertexFormat.html [1] https://stuartmarks.wordpress.com/2020/04/14/scanner-is-a-weird-but-useful-beast/ [2] https://bugs.openjdk.org/browse/JDK-8316398 On Fri, Sep 13, 2024 at 11:40?AM Knee Snap wrote: > Gottttcha, thank you Michael, that really helps a lot. > > I read the contribution guide and I definitely took away the wrong thing. > I expected a very bearaucratic process, so I've largely interpreted the > conversations this far with that mindset. It makes a lot more sense if I > consider the previous conversations as a democratic process. > > The 3D system being niche therefore getting less attention makes sense. I > hope some of these changes can make it become less niche since I think a > handful of missing features will make a very large impact on its > usability/how appealing it is to different projects. Unfortunately that's > pretty hard to measure, but I hope that can be made up for by showing how > the rest of the 3D world support these features without fail. That won't > make up for a lack of overwhelming enthusiasm, but I'm hopeful that because > my planned proposals all have very mature specifications for how they work > across the broader 3D world with consistent operations across pretty much > all applications (except JavaFX) that it counts for something. Perhaps I > should start following other conversations more closely to get a better > feel on how these discussions tend to go. > > The bottom line is that your message has helped me reconceive how I should > be thinking about this and I feel a lot more confident in my ability to be > a helpful contributor from that. > > Thank you (and everyone else) for being so understanding, contributing to > an open source project so mature/stable/widely used is a new experience for > me I must say, so I really do appreciate helping me acclimate like this. > It's nice to not need to accompdate business pressures/goals and just make > decisions based on what provides the most utility to yourself and others. > > On Thu, Sep 12, 2024, 9:23?PM Michael Strau? > wrote: > >> Just a comment about the culture of the OpenJFX project, which you >> seem to be struggling with: >> >> From my experience, this project is usually quite democratic in its >> processes. The features and enhancements that successfully make it >> into JFX start with a discussion on the mailing list. This is where >> you gather buy-in from other developers (if no one is interested in >> your proposed enhancement, you're in a tough spot). Don't worry too >> much about formal processes, it's about community support at this >> stage. Get other people to be excited about your enhancement, and >> hopefully some will find the time to look at the design and your >> implementation. Some proposals build up inertia and move forward, >> others end up dying due to a lack of interest. >> >> 3D graphics in JavaFX is a bit of a niche feature (and vertex colors >> is even more niche), which is probably why the response to your >> proposal is a bit slow. That being said, I'll take a closer look at >> your proposal during the weekend. >> >> >> >> On Fri, Sep 13, 2024 at 4:59?AM Knee Snap wrote: >> > >> > Thanks Nir! No worries about being busy, my concern was when I didn't >> get replies to my questions about what I should be doing and procedural >> questions. But, it seems maybe I wasn't super clear about my questions >> since you aren't sure what they were. >> > I also went through many days waiting for responses about expectations >> all while he was replying quickly to other emails, seemingly ignoring mine. >> I'm not suggesting he's done anything wrong, I can imagine perfectly good >> reasons for not having replied, but my questions were related to the >> contribution guidelines and expectations. So I've felt like I've been going >> foward without clear expectations of both myself and contributors, and like >> I wasn't even guaranteed a response at all. The only reference I had for >> how long I should expect to wait was based on the other emails I saw, which >> had fast replies. I'm hoping to clarify my responsibilities and >> expectations, and what I should expect from contributors, since there's a >> lot of stuff to get familiar with in the contribution guide, and it's my >> first time contributing. Due to that, it felt like those questions went >> mostly ignored and it wasn't a matter of being busy, as other emails were >> getting quick replies, though perhaps I didn't phrase them clearly. Hoping >> to now clear up my confusions about responsibilities. Your email has helped >> reassure me that I was not getting ignored, but instead just had a lower >> priority or something else that could cause it to take longer to get a >> reply. >> > >> > Overall, I'd like to give some insight into what it has felt like for >> me to contribute to JavaFX for my first time. The contribution guide is >> good, but it hasn't been enough. >> > This isn't here to point blame or to criticize, but instead give some >> perspective into my experience here and why this has been such a >> frustrating experience. Perhaps this will help improve the contribution >> experience for newcomers like me going forward keeping this in mind, but >> ideally it'll help set the stage for why I am so confused and help you guys >> resolve my confusions. >> > -> The contribution guide misled me in many ways here, and there are >> many questions I still do not have an answer to. >> > -> To start off, it said to include a feature proposal, and it gave >> suggestions for various things to include. >> > -> So, I wrote a long feature proposal email and sent it off. For a >> week I had a discussion with a contributor where we hashed out different >> design choices, I felt like we had appropriately discussed everything which >> had been discussed adequately, and was ready to get my feature proposal >> approved by Kevin. >> > -> Everything was going great until one week in when Kevin replied and >> said he "would need to be convinced that multiple applications would >> benefit from such a feature, and that your proposed solution -- as >> documented and exposed by the public API -- is the best way to go." >> > -> He also asked if I had read the contribution guide, implying he >> didn't think what I had previously sent wasn't me 1:1 following the >> contribution guide. >> > -> I still don't understand why he sent that, I believe I presented >> exactly what the contribution guide wanted. There were a handful of things >> that got missed, but each were discussed in the email thread. >> > -> Did he not read the proposal and assume I did it wrong? Did he read >> it and think it wasn't convincing? Did he want a new proposal which >> included the things which had been discussed in the email thread? >> > -> So, with this confusion I asked for clarification as well as other >> questions relating to Metal like who was working on it, if I could have a >> contact for them, etc. >> > -> Never got a reply! Okay, so what the heck am I supposed to do here? >> Kevin asked for new a feature proposal, and I guess for some inexplicable >> reason this one wasn't good enough? It doesn't seem like he even realized >> this was a feature proposal, but either way, he asked for a new one, so >> I'll make a new one. >> > -> After looking at other feature proposals, I retooled my proposal >> and come up with something I was happy with, which I felt went above/beyond >> what was necessary. I've even prototyped an implementation which works that >> I can use to get a screenshot for the proposal, and to ensure my opinions >> of the design didn't change even after seeing it in practice. >> > -> During this time Kevin even helped me sort out an issue building >> JavaFX, so here I am thinking that I've been given the green light to >> present a final feature proposal with all of my changes, and Kevin will >> review it. >> > -> So, after finalizing a new proposal, I'm feeling good. I've >> expanded the proposal significantly, and it's now in a Git repository, >> which is what other contributors have been doing. >> > -> I'd like to give everyone a chance to review the updated proposal, >> who knows maybe there could be something I missed. Then, I'll pass it off >> to Kevin. >> > -> There's some discussion and Kevin even chimes in at one point. >> After a few days when there's no more discussion, I send out an email >> saying I'm reading to pass it off to Kevin for review. >> > -> Then, I don't get a reply. After a little bit, I start to get very >> concerned since I see him actively replying to other emails, and he's still >> never touched the original email I sent asking him for clarification, and >> follow-up questions. >> > -> At this point it's been almost 3 weeks since his confusing email, >> and I still have no clarification, and I've spent quite a lot of effort on >> this. The questions from before have come back. Did he even read my initial >> feature proposal? What if all this time he had just not read the original >> one? I've got 3 weeks since an email which is still waiting for a reply >> from him and I've just not heard anything. Not even an indication he plans >> to reply but is busy. I have no idea what's normal/what I should expect, >> but I can't even ask for clarification on that. >> > >> > So, at this point I've lost track. I have no idea where I am in the >> contribution process, none of my questions have been answered, and the only >> outcome I see happening right now is that this proposal is lost & forgotten. >> > I don't know what else on the guide I can do, nor does it feel like >> Kevin is bothering to answer important questions, let alone review it. >> > I completely understand the slowness, it's an open source project after >> all, no less a very mature one which tries to avoid all changes to public >> APIs. My frustration has mainly been that I believe I've been asking >> questions that take little effort to reply to, but are getting ignored >> while I see him actively replying to other threads. Perhaps my emails are >> too long and contain so much detail that the questions don't immediately >> pop out, and thus they get missed. But at this point it feels more like I'm >> getting ignored for an unknown reason. >> > If I had some sort of confirmation that it's normal for low-priority >> emails to sit a bit, but that Kevin WILL eventually get to it, this would >> go a LONG way. >> > >> > But from this I've learned that I need to be extremely explicit with my >> questions. So here are the questions I'd like answered (Some of these I >> hadn't asked earlier, others have gotten lost): >> > 1) Eg: I either want an explanation of the workflow for Metal. How I >> will be including vertex colors (a feature which hasn't officially been >> merged yet!!) in Metal, or will I wait until vertex colors are officially >> merged before adding support to Metal? I'm fine with either, I just want >> the process laid out for me. >> > -> I know Metal support is getting done by Oracle, but I think you >> guys can still provide input to this question. (I will also be asking them, >> if I can get contact info for them) >> > -> The Metal Pipeline doesn't strike me as being very close to being >> finished, so it feels like vertex colors can be merged before them. If that >> is the case, I'd like to have vertex colors merged without Metal support, >> then at that point I can add vertex color support to Metal, as this is the >> clearest path that I see to avoiding conflicts between 3 different >> repositories. >> > -> I see this as a very conservative approach though, and it's my >> proposal because I'm not familiar with JavaFX contribution workflow yet. >> I'd like to hear feedback from others on how they suggest I handle this. >> > 2) Where can I get contact info for those who are working on Metal >> support? Looking for a lead or someone prominent. >> > -> I mentioned several questions regarding Metal support, but I think >> the best people to answer them will be the people actually working on the >> Metal support. So a contact should be enough. >> > 3) Can I get some clarification on expectations for contribution? >> > -> From the contribution guide, my understanding is that the current >> thing I'm waiting on is for design approval (on the feature proposal) from >> Kevin. >> > -> But, I think I'm OK to seek out feedback on my PR as well, which >> I've recently realized already has a JBS Bug ID (or I think that's what it >> is? It's got an entry on at least one of the multiple web portals I've seen >> which track issues.) >> > -> 3a) How long does it generally take to get responses on low >> priority feature proposals? I have no reference for what to temper my >> expectations against, which would help me a lot. Should I expect it to take >> a week before Kevin weighs in? Two weeks? One month? 6 months? One year? >> I've seen projects with response times covering the whole spectrum, and I >> just don't know where to set my expectations for when it is appropriate to >> follow-up on an email which hasn't gotten a reply. >> > -> 3b) Every single other recent active PR besides mine has had a >> review comment from at least one other person, including ones created after >> mine. How should I interpret this besides me having done something wrong? >> At what point should I ask for a follow-up and for people to review it if I >> don't hear back from anyone? >> > 4) How long should I expect before my OCA signature is reviewed? I >> submitted it around 2 weeks ago at this point, and I don't think it's been >> reviewed yet, which is significantly longer than the website stated it >> would take. >> > -> We're also beyond the timeframe that the JFX repository said it >> would take. >> > -> Also, nobody has commented on my PR to run the expected commands >> whereas other PRs uploaded later have ~25 comments. Why is this? Is it due >> to low priority? Is it due to the 3D rendering system having fewer people >> working on it? >> > 5) Why does the Direct3D 3D pipeline appear to use fixed vertex buffer >> definitions in the D3D calls, as opposed to making a more modern vertex >> buffer definition? >> > -> The 2D pipeline uses the more modern vertex buffer definitions, but >> the 3D pipeline uses an FVF definition, which means many non-texCoord >> values are marked as texCoords in the shaders. (I don't know if that's >> necessary, but it seems weird to me). >> > -> My best guess for this is there was some kind of compatibility >> consideration, but I haven't been able to find any information on it. Does >> anyone (maybe you) know why it's done as an FVF declaration instead of a >> vertex declaration? >> > 6) Why was your PR for #1281 not labelled as a draft PR or WIP? If I >> follow the contribution guidelines, I think it should be labelled as a >> draft? Hoping for some clarification. >> > 7) Do you mind sending out a reply to the original thread so I am able >> to reply to it instead of violating the contribution guidelines? Thanks! >> > -> What I was hoping for PR #1281 was that since I joined the mailing >> list recently, while I can read the previous emails in the archive, I have >> no way to reply to pre-existing threads, as they're not in my inbox. I'd >> have to start a new email thread which the contributing guidelines say >> explicitly not to do. >> > 8) Where am I currently in the contribution guide? What is the next >> steps? What is expected from me? >> > 9) What is some reasonable criteria for me to use. >> > -> 9a) If I send out a proposal for design discussion, how long should >> I wait from the last email before sending it to Kevin >> > -> 9b) If I send out a feature proposal to Kevin for approval, how >> long should I wait before following up with Kevin if I don't hear back? >> > -> 9c) If I send out a PR/Draft PR, how long after receiving no >> feedback should I wait before following up? >> > >> > Thanks again! I really appreciate JavaFX contributors and I want to >> make it clear that I'm not taking any of this for granted. I just am very >> confused and feel like the documentation has left me in a situation where >> I'm just utterly confused and don't know what's going on, and haven't been >> getting my questions answered. >> > In retrospect, I definitely didn't make these questions anywhere near >> clear enough, so I can understand why they were missed. So ideally this >> email can serve as both a way for me to clear up my confusion, but also to >> improve the experience for future contributors who can be spun around by >> having a mismatch between their expectations from the contribution guide >> and the demonstrated behavior of contributors up to the project lead Kevin. >> I want to be fully clear again that I'm not trying to argue or start a war, >> just neutrally explain my perspective, and express the desire to work with >> everyone to get everything sorted. >> > I look forward to your feedback when you have a chance to review the PR. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Thu Sep 19 08:56:42 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 19 Sep 2024 08:56:42 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 17:57:07 GMT, Andy Goryachev wrote: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) - I also see the NPE issue with RotateTest java.lang.NullPointerException: Cannot invoke "test.robot.com.sun.glass.ui.monocle.input.devices.TestTouchDevice.getPressedPoints()" because "this.device" is null at test.robot.com.sun.glass.ui.monocle.RotateTest.releaseAll(RotateTest.java:75) - Additionally number of tests is also different - with this PR: 144 tests completed, 144 failed - without this PR: 162 tests completed, 12 failed, 18 skipped - Executed on mac machine, Command: `gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test -PUNSTABLE_TEST=true --tests test.robot.com.sun.glass.ui.monocle.RotateTest ` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2360407673 From arapte at openjdk.org Thu Sep 19 09:03:43 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 19 Sep 2024 09:03:43 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: References: Message-ID: <9W0YNhxZbij1ovDg3s78FozANTaK_EOgZh1eZTf1QoY=.878227b9-a38b-44e2-b4ad-0e2f09ef55ee@github.com> On Mon, 16 Sep 2024 17:57:07 GMT, Andy Goryachev wrote: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) Here is a patch to remove unused imports. I could identify 5 such files: [rm-unused-import.diff.zip](https://github.com/user-attachments/files/17056359/rm-unused-import.diff.zip) I tested that the tests get compiled successfully. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2360423454 From lkostyra at openjdk.org Thu Sep 19 09:32:41 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 19 Sep 2024 09:32:41 GMT Subject: RFR: 8328828: Monkey Tester Application Part 4 [v3] In-Reply-To: References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: On Mon, 16 Sep 2024 15:18:33 GMT, Andy Goryachev wrote: >> Further additions to the MonkeyTester application: >> >> - tree/table view column property sheets ? >> - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? >> - properties... context menu ? >> - context menu: table columns, toolbar items ? >> - control.context menu option >> - property monitor tool ? >> - accessibility logging ? >> >> - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) >> - Page -> Snapped Split Panes menu option for the control container >> >> This PR simply syncs up with the dev repository >> https://github.com/andy-goryachev-oracle/MonkeyTest > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8328828.monkey > - review comments > - Merge remote-tracking branch 'origin/master' into 8328828.monkey > - whitespace > - 8328828: Monkey Tester Application Part 4 LGTM ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1560#pullrequestreview-2314970347 From lkostyra at openjdk.org Thu Sep 19 09:36:45 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 19 Sep 2024 09:36:45 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 22:40:20 GMT, Andy Goryachev wrote: >> This PR converts all tests in `modules/javafx.graphics` to use JUnit5. >> >> ## Details >> >> Trivial changes resolved by first four commits: >> - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) >> - Message Strings in `assert*` calls moved to the end to follow 5's argument order >> - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations >> - Some test formatting unification - keeping annotations on a separate line from method definition >> - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. >> >> Non-trivial changes: >> - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: >> - `DirtyRegionTestBase` >> - `CssMethodsTestBase` >> - `ObjectMethodsTestBase` >> - `OnInvalidateMethodsTestBase` >> - `PropertiesTestBase` >> - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized >> - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` >> - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 >> >> At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. >> >> As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. >> >> ## Results >> >> Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: >> >> | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | >> | ------------ | ------ | ------ | >> | Test count | 23272 | 23275 | >> | Failures | 0 | 0 | >> | Ignored | 99 | 102 | >> | Successful % | 100% | 100% | >> >> The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion... > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java line 76: > >> 74: return Stream.concat(stream, Stream.of(arg)); >> 75: } >> 76: > > same comment: `List` might also work > (here and possibly elsewhere, I don't want to add duplicate comments) There will be plenty of uses of that all throughout this change, I wasn't 100% sure what JUnit5 expects or allows so I used the same `Stream` return type for parameter methods across all tests. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1766506669 From jdv at openjdk.org Thu Sep 19 11:04:42 2024 From: jdv at openjdk.org (Jayathirth D V) Date: Thu, 19 Sep 2024 11:04:42 GMT Subject: RFR: 8339508: RenderPerf Test Application [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 15:25:47 GMT, Lukasz Kostyra wrote: >> This PR migrates RenderPerf performance test application from jfx-sandbox metal branch: https://github.com/openjdk/jfx-sandbox/tree/metal/tests/performance/animation/RenderPerfTest/src/renderperf >> >> RenderPerf is a performance test application which draws provided number of "particles" (JFX nodes) on the screen and animates them. After some time (default 10 seconds of testing + warmup) the test automatically closes and reports FPS values. Test was developed as part of Metal backend for performance testing and we decided to integrate it with mainline for any potential further development and fixes. >> >> Command line options for the test: >> - `-n` - number of particles to draw, defaults to 1000 >> - `-t` - name of test to run, defaults to running all tests in random order. Can provide multiple tests, ex. `-t Rectangle Image` >> - `-d` - test duration in seconds, defaults to 10. Can be set to 0, which means the test will run infinitely long and end only when user manually closes the stage, mostly useful for stability testing. >> >> Some tests use `duke.png` image provided with this PR. This is an openly available Duke Wave image taken from https://wiki.openjdk.org/display/duke/Gallery and rescaled for test purposes. >> >> PR consists of two commits: >> - Base version of RenderPerfTest developed by @karthikpandelu >> - My commit adding `-d` flag and implementing plenty of other fixes as part of [JDK-8331570](https://bugs.openjdk.org/browse/JDK-8331570) > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year to 2024 I did basic testing with different options and everything works fine. Its good that we are open-sourcing this rendering performance test. LGTM. ------------- Marked as reviewed by jdv (Author). PR Review: https://git.openjdk.org/jfx/pull/1568#pullrequestreview-2315194679 From kcr at openjdk.org Thu Sep 19 11:09:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 19 Sep 2024 11:09:43 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 23:10:40 GMT, Kevin Rushforth wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodePlatformExitCrashTest.java line 39: > >> 37: >> 38: @Test >> 39: @Disabled("JDK-8190329") > > Unrelated to your PR...well this is embarrassing! I just fixed the FX clone of JDK-8190329 a couple weeks ago, and forgot to look to see if there was an existing test. I'll file a follow-up bug for this. I filed [JDK-8340442](https://bugs.openjdk.org/browse/JDK-8340442). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1766638928 From mhanl at openjdk.org Thu Sep 19 11:48:40 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 19 Sep 2024 11:48:40 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 09:34:20 GMT, Lukasz Kostyra wrote: >> modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/DirtyRegionTestBase.java line 76: >> >>> 74: return Stream.concat(stream, Stream.of(arg)); >>> 75: } >>> 76: >> >> same comment: `List` might also work >> (here and possibly elsewhere, I don't want to add duplicate comments) > > There will be plenty of uses of that all throughout this change, I wasn't 100% sure what JUnit5 expects or allows so I used the same `Stream` return type for parameter methods across all tests. This is fine and I think Stream is what you will in most documentations as well, so good IMO. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1766687081 From lkostyra at openjdk.org Thu Sep 19 14:09:49 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 19 Sep 2024 14:09:49 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: <9bAzy4lHLe44jsTvkQHLnN2IonakEca7NYQI97jmQx4=.1afa965d-518f-4cda-9129-2b9894a43ba6@github.com> On Wed, 18 Sep 2024 15:36:53 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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 18 additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - part 9 cell > - part 8 > - ... and 8 more: https://git.openjdk.org/jfx/compare/de179048...55b33b2c Went through about 2/3rd of your changes, will continue tomorrow starting from `javafx/scene/control/TreeViewKeyInputTest.java`. In the meantime, a couple comments. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlSkinTest.java line 41: > 39: import javafx.scene.control.Skin; > 40: import javafx.scene.control.Tooltip; > 41: import org.junit.jupiter.api.Assumptions; [Minor] Why not `import static org.junit.jupiter.api.Assumptions.assumeTrue`? We're directly importing `Assertions` this way anyway. modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlTooltipTest.java line 48: > 46: import static org.junit.jupiter.api.Assertions.assertTimeout; > 47: import static org.junit.jupiter.api.Assertions.assertNotEquals; > 48: import org.junit.jupiter.api.Assumptions; Why not `import static org.junit.jupiter.api.Assumptions.assumeTrue`? We're directly importing `Assertions` this way anyway. modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 517: > 515: } > 516: > 517: // @Test public void selectedTextWorksWhenSelectionIsBound() { This test was removed. Shouldn't we keep even commented tests around? modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 591: > 589: } > 590: > 591: // @Test public void selectionCanBeBound() { As above, removed test that was commented out modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 608: > 606: } > 607: > 608: // @Test public void selectionChangeEventsHappenWhenBound() { As above modules/javafx.controls/src/test/java/test/javafx/scene/control/ToolbarTest.java line 49: > 47: import static org.junit.jupiter.api.Assertions.assertTimeout; > 48: import static org.junit.jupiter.api.Assertions.assertNotEquals; > 49: import org.junit.jupiter.api.Assumptions; Similar situation with `Assumptions` as earlier modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 136: > 134: import static org.junit.jupiter.api.Assertions.assertTimeout; > 135: import static org.junit.jupiter.api.Assertions.assertNotEquals; > 136: import org.junit.jupiter.api.Assumptions; Similar `Assumptions` question/situation ------------- PR Review: https://git.openjdk.org/jfx/pull/1561#pullrequestreview-2315390189 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1766744540 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1766745066 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1766816642 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1766818612 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1766818902 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1766823201 PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1766834349 From john.hendrikx at gmail.com Thu Sep 19 14:17:18 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 19 Sep 2024 16:17:18 +0200 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: <4b9071be-a3a8-4be8-ba88-2e5119789810@gmail.com> My apologies then, I was a bit impatient.? Good luck with the test sprint then! --John On 18/09/2024 17:13, Andy Goryachev wrote: > > Oh, sorry, I did not mean to ignore your comments. ?I should have > mentioned we are having a bi-annual "test sprint" and work exclusively > on the test suite.? You made a lot of good comments that require some > thought and careful consideration, for which I simply had no spare CPU > cycles last week or this week.? Sorry, will definitely respond in > detail early next week. > > -andy > > *From: *John Hendrikx > *Date: *Tuesday, September 17, 2024 at 23:05 > *To: *Andy Goryachev , > openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: Proposal: Focus Traversal API > > Andy, > > As you're not responding to any of the suggestions or any of my > questions, but are only re-iterating points that I believe are not > going to be a benefit to the long term viability of FX, I see no point > in continuing the discussion further. > > --John > > On 18/09/2024 01:09, Andy Goryachev wrote: > > Dear John: > > You do bring a lot of good points, no doubt.? And I do agree with > a lot of the suggestion, but I still want to emphasize two points: > > 1. The backward compatibility should not be dismissed that > easily.? There is a number of existing applications out there and > we do not want to break them.? Whether the behavior is specified > or not is irrelevant, we do not want to cause mayhem from the > customers and developers alike whose keyboard navigation suddenly > changed. > > 2. I question the cost benefit analysis of the redesign idea.? > While I agree with you that it might help with some unusual cases, > the overall benefit is rather limited.? The benefit of the > proposed solution is, in my opinion, far greater: it allows for > custom traversal policies (a feature that has been requested > multiple times) and enables focus traversal from custom > components, something of a lesser value, but still important.? > Exposing the existing APIs is a relatively cheap solution that > will give us two features at nearly zero cost.? On the other hand, > I doubt that our team, or yourself, are willing commit substantial > development effort to redesign the thing to use events.? Which > brings me to the choice I mentioned earlier: realistically, we > have a choice of providing two requested features soon, or never. > > I would also encourage other members of the development community > to voice their opinion on the subject, perhaps there is something > else we can do to move forward. > > Thank you > > -andy > > *From: *John Hendrikx > > *Date: *Saturday, September 14, 2024 at 09:41 > *To: *Andy Goryachev > , openjfx-dev at openjdk.org > > *Subject: *[External] : Re: Proposal: Focus Traversal API > > Hi Andy, > > First let me say that when it comes to designing an API, you > really need to take the time to think the solution through.? The > current internal solution was probably kept internal for exactly > that reason, insufficient time to work out the kinks and look into > alternatives. > > An API is almost impossible to change later, so the general rule > is that if you're not sure about an API, then its better to have > no API. This is why I think it is important that we first look for > what the API should look like, then worry about how this can be > fitted onto JavaFX.? Making concessions related to the current > implementation before having a clear idea of how the API should > preferably work is not part of that.? You start making concessions > only when it turns out the preferred design would encounter > unresolvable problems in the current implementation. > > Since I think there is very little public API related to focus > traversal, nor is there any specification of how it currently > works, I think we have a lot of room to maneuver.? This is why I > think we should first reach a consensus on the API, then look how > it can be fitted on top of FX.? Sometimes a well thought out API > also is a natural fit, and may be easier to migrate to than you think. > > On 14/09/2024 00:17, Andy Goryachev wrote: > > Dear John, Everyone: > > Thank you for a thoughtful response!? Some of the ideas you > described definitely deserve further consideration.? If I were > to summarize: > > 1. move the focus traversal logic away from the components and > into the Scene > > 2. re-implement focus traversal through TraversalEvents rather > than responding directly to KeyEvents > > 3. (more) standard policies > > 4. using CSS > > (there is of course more topics in your response, but let me > start with the 4 above) > > #1 > > I generally like this idea.? In some sense it is already how > things work internally, but without the ability to customize > that (i.e. by introducing custom traversal keys, or removing > existing ones).? The downside is substantial: not only we'd > need to re-design the whole of the focus traversal, but also > rework the existing control's behaviors.? Did I mention the > risk of regression, given the absence of comprehensive > behavioral tests? > > There's two things here. > > 1. There is no need to re-design the whole focus traversal.? The > old internal system can be gradually replaced (it works by > directly consuming KeyEvents after all). > > 2. Regression.? When nothing is specified, and the fact that > controls **ought** to work like other common controls in different > UI toolkits, is it a regression when focus traversal works the > same as those other platforms, even if it may be a regression from > the point of view of FX?? For example, a Spinner will currently > react to any mouse key, where as other common toolkits only react > to the left mouse button.? Is it a regression if FX is adjusted to > also only react to the left mouse button?? It's not specified > anywhere. > > I think we have sufficient space to maneuver here as long as we > are not making focus traversal completely different from how it > commonly works in UI's. > > Can there be regressions versus the current (unspecified) > implementation?? Sure, there can be.? Is that necessarily bad?? > That depends.? If the new focus traversal works like it does on > all other toolkits, then no, it is more of a bug fix.? Did we > break something with the new implementation?? That's always > possible, but will then be fixed as soon as it is reported. > > #2 > > This may or may not be an integral part of #1.? Potentially, > it allows for injection of events by the application code, as > well as simplifies creation of complex custom controls.? The > latter becomes possible with the original proposal, so net > benefit is limited to the first part, I think. > > I think TraversalEvents are quite central to making this an API > that will really stand the test of time.? It leverages the > existing event system, giving you all the power that comes with > it. You did not answer my question about the TraversalEvents in > your design.? Why are the Events when they can't be triggered, > filtered or?consumed? > > #3 > > One obvious possibility is to enable creation of a simple > policy based on a list of Nodes.? I must mention one use case > that is impossible to cover with pre-defined policy is one > where navigation depends on some state.? Such a policy must be > implemented programmatically.? I think one property should be > sufficient - I am strongly against adding two properties here. > > Programmatic escapes can always be achieved by responding directly > to a TraversalEvent.? I think however this should be a rare case, > and standard policies should really cover almost all use cases.? > It may be a gap that should be investigated, and the API adjusted > for (usually the "exceptions" are well worth looking into to see > if with a tweak they can't become "standard").? As for being > "strongly against" having two properties -- that's an odd stance > to take without motivating it.? It could also be rolled into "one" > where the Policy is a record with the two values, but I think > we're getting ahead of ourselves here. First the API, then the > implementation. > > I do think however there is great value in having the Logical and > Directional navigation split.? Often you'll only want to replace > one of these with a custom policy (or a different standard > policy), so that the other navigation method can be used to escape > the control.? For example, a Toolbar could be tabbed in an out of > (using Logical navigation) while the Directional navigation is > cyclic (and thus can't be used to escape the control's context). > > #4 > > The idea of using CSS to specify traversal policy seems wrong > to me: the CSS defines the presentation aspects (styles) > rather than behavioral ones.? I know it is possible to set > custom skins and the corresponding behavior via CSS, and we > know why (skins define the appearance), but we should not go > beyond that, in my opinion. > > I see no problem styling such properties. They're FX properties, > and it would be very convenient to style them to globally alter > how focus works, instead of having to rely on, say, Builders or > Factories for controls where traversal policies can be applied.? > There are also already properties that don't only influence the > look of controls.? "-fx-skin" being the most obvious one, but > there is also "-fx-focus-traversable", "-fx-context-menu-enabled", > "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", > "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", > "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and > probably more.? Aside from "-fx-skin" none of these properties > have a visual impact, but instead alter behavior. > > Note: I'm not saying this needs to be there immediately.? I just > want to make sure we're not closing off this direction, as again, > it would be a huge hassle to do this programmatically.? In "code" > the only things I usually do on my controls are the following: > > - I define the container hierarchy (VBox, HBox, which children go > where) > - I set a style name > - I set anything that unfortunately cannot be CSS styled (things > like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, > things that are clearly "visual" but still can't be styled). > > All the rest I don't touch, or want to touch.? Having to select a > traversal policy for every control of type X I create is just > cumbersome and unnecessary.? There will be a call then to set this > "globally", and then there will be the question, do we make > something custom with many limitations because it doesn't fit our > conceptions of what (FX) CSS is for (ie, not?style, but > only?*visual* style) or do we just expose these properties as > Styleable?leveraging an existing powerful system with almost zero > effort? > > -- > > There is one more aspect of the problem that I think we should > consider.? The current proposal does not change the > implementation in any material way, nor does it change the > behavior, thus can be done quickly.? The benefit everyone gets > from it is ability to trigger focus traversal and to control > it via custom policies.? Any other solution will require > resources and the bandwidth we currently don't have, which > means the /probability/ of it being added to FX is virtually > zero.? Let me emphasize, I am not against attempting to > discuss or implement the best possible solution, but we should > be aware of the limitations of the reality we live in. > > "Quickly" and API's are incompatible with each other.? There is > nothing worse than exposing an API quickly, which then becomes a > burden on the system -- I think the current CSS API is a prime > example of where "quickly" has gone wrong, costing us tremendous > amounts of effort to make even minor changes to it. > > I urge you to ignore the current implementation, think thoroughly > how (in an ideal world) you would want such an API to work (from a > user perspective, not from an implementor's perspective) and only > then see how this could be made to fit into JavaFX. > > This is exactly what I did.? I did not look at the implementation, > although I'm aware of some of it.? I looked at how I as a user of > FX am building applications, the struggles I have?with it > currently, (with controls for example "eating" KeyEvents), and how > I would like to be able to adjust focus traversal.? Do I want to > respond to "KeyCode.LEFT" or do I want to respond to > "TraversalEvent.LEFT"?? Do I also need to respond to > "KeyCode.NUM_PAD_LEFT"?? These things should be abstracted, and > preferably I should just be able to choose from common navigation > standards.? And when I do want to change such a standard, in 99% > of the cases that will be the case for all similar controls in my > application.? How do I do such things currently if I want to > change something for all controls in my application?? I use CSS. > > Also I think this can be implemented gradually.? Here's a > potential plan: > > 1. Have Scene listen to unused KeyEvents and translate them to > TraversalEvents > > Benefit:?gives custom controls a way to respond to keyboard based > navigation in a platform agnostic way; this probably already > removes the biggest roadblock for custom controls... > > Public API: Limited to a new Event > > 2. Start converting existing controls to listen to TraversalEvent > instead of KeyEvent > > This hits a lot of controls, but should be relatively easy to do, > and it can be all kept internal for now.? It can be done in a few > batches. > > Benefit: for each control converted, user can now programmatically > trigger focus changes, and by overriding things at Scene level can > completely change navigation keys > > Public API: none > > 3. Implement a number of standard policies internally (OPEN, > CONFINED, CYCLIC, IGNORED) > > Convert any controls that could use these as their default, > removing any custom logic if it happens to match one of the defaults. > > Benefit: less code to maintain and debug, gives us experience with > which policies make sense and where the gaps are > > Public API: none > > Order: It is possible to do this before 2, and so some of the > control conversions could just consist of removing their custom > logic, and selecting a standard policy. > > 4. Expose policy property/properties?on Parent > > Any controls that are not using a custom policy anymore (of type > IGNORED) can now be user adjusted.? We don't have to guarantee > that each policy makes sense for each control. Changing a default > IGNORED policy to a standard one will change the behavior (as > intended) but it need not be a "complete" behavior that users > like.? This is not FX's problem, and can be improved upon later. > > Benefit: users can now change policies on any existing control, > even ones with a custom policy; many of the controls may support a > switch between OPEN, CONFINED and CYCLIC out of the box. > > Public API: new properties on Parent > > 5. Perhaps expose some helpful tools to calculate the "next" Node > for a given traversal option. > > This can be done at any stage, and can be considered completely > separate.? It is IMHO a relatively low?priority need. > > Benefit: less work for control implementors (although they could > just "copy" said code) > > Public API: Maybe some methods in Node, or some kind of static helper. > > 6. CSS styleable properties > > If we really want to give power to our users, and impress them > with a flexible focus traversal API, then make these properties > styleable. > > Benefit: allow users to pick any control, and set is policy > globally or within a subset of controls (ie. dialogs, popups, etc). > > Public API: Nothing in Java, but document as CSS properties > > --John > > Thank you, > > -andy > > *From: *openjfx-dev > on behalf of John > Hendrikx > > *Date: *Wednesday, September 11, 2024 at 19:05 > *To: *openjfx-dev at openjdk.org > > *Subject: *Re: Proposal: Focus Traversal API > > Hi Andy / List, > > I've given this some thought first,?without looking too much > at the proposal. > > In my view, focus traversal should be implemented using > events, and FX should provide standard handling of these > events controlled with properties (potentially even CSS > stylable for easy mass changing of the default navigation policy). > > ##?KeyEvent and TraversalEvent separation > > I think the cleanest implementation would be to implement a > KeyEvent listener on Scene that takes any unused KeyEvents, > checks if they're considered navigation keys, and converts > these keys to a new type of event, the TraversalEvent. The > TraversalEvent is then fired at the original target. The > TraversalEvent is structured into Directional and Logical sub > types, and has leaf types UP/DOWN/LEFT/RIGHT and > NEXT/PREVIOUS.? Scene is the logical place to handle this as > without a Scene there is no focus owner, and so there is no > point in doing focus traversal. > > This separation of KeyEvents into TraversalEvents achieves the > following: > > - User can decide to act on **any** key, even navigation keys, > without the system interfering by consuming keys early, > unexpectedly or even consuming these keys without doing > anything (sometimes keys get consumed that don't actually > change focus...).? The navigation keys have many possible dual > purposes, and robbing the user of the opportunity to use them > due to an overzealous component interpreting them as traversal > keys is very annoying. Dual purposes include for example > cursor control in TextField/TextArea, Scrollbars, etc.? The > user should have the same control here as these FX controls have. > > - Scene is interpreting the KeyEvents, and this interpretation > is now controllable.? If I want a Toolbar (or the whole > application) to react to WASD navigation keys, then installing > a KeyEvent handler at Scene level or at any intermediate > Parent level that converts WASD to UP/LEFT/DOWN/RIGHT > Traversal events would affect this change easily. > > - The separation also allows to block Focus Traversal only, > without blocking the actual Keys involved. If I want to stop a > Toolbar from reacting to LEFT/RIGHT, but I need those keys > higher up in the hierarchy, then I'm screwed.? With the > separation, the key events are unaffected, and I can block > Toolbars from reacting specifically to traversal events only. > > ## Traversal Policy Properties on Parent > > I think FX should provide several policies out of the box, > based on common navigation patterns.? The goal here is to have > policies in place that cover all use cases in current FX > provided controls.? This will provide a good base that will > cover probably all realistic work loads that custom controls > may have. The goal is not to support every esoteric form of > navigation, instead an escape hatch will be provided in the > form of disabling the standard navigation. > > In order to achieve this, I think Parent should get two new > properties, which control how it will react to Directional and > Logical navigation.? These will have default values that allow > navigation to flow from Node to Node within a Parent and from > Parent to its Parent when navigation options in a chosen > direction are exhausted within a Parent.? Custom controls like > Combo boxes, Toolbars, Button groups, etc, can change the > default provided by a Parent (similar to how some controls > change the mouse transparent flag default). > > These two properties should cover all realistic needs, and > IMHO should be considered to be CSS stylable in the future to > allow easy changing of default policies of controls (ie. want > all Toolbars to react differently to navigation keys, then > just style the appropriate property for all toolbars in one go). > > Parent will use these properties to install an event handler > that reacts to TraversalEvents (not KeyEvents). This handler > can be fully disabled, or overridden (using setOnTraversalEvent). > > - logicalTraversalPolicy > - directionalTraversalPolicy > > The properties can be set with a value from a TraversalPolicy > enum. I would suggest the following options: > > - OPEN > > This policy should be the default policy for all Parents.? It > will act and consume a given TraversalEvent only when there is > a suitable target within its hierarchy.? If there is no > suitable target, or the target would remain unchanged, the > event is NOT consumed and left to bubble up, allowing its > parent(s) to act on it instead. > > - CONFINED > > This policy consumes all TraversalEvents, regardless of > whether there is something to navigate to or not.? This policy > is suitable for controls that have some kind of substructure > that we don't want to accidentally exit with either > Directional or Logical navigation.? In most cases, you only > want to set one of the properties to CONFINED as otherwise > there would be no keyboard supported way to exit your > control.? This is a suitable policy for say button groups, > toolbars, comboboxes, etc. > > - CYCLIC > > Similar to CONFINED but instead of stopping navigation at the > controls logical boundaries, the navigation wraps around to > the logical start. For example, when were positioned on the > right most button in a button group, pressing RIGHT again > would navigate to the left most button. > > - IGNORED > > This is similar to the mouseTransparent property, and > basically leaves the TraversalEvent to bubble up.? This policy > allows you to completely disable directional and/or logical > navigation for a control.? Useful if you want to install your > own handler (the escape hatch) but still want to keep either > the default directional or logical navigation. > > Possible other options for this enum could include a version > that consumes all TraversalEvents (BLOCK) but I don't see a > use for it at the moment.? There may also be variants of > CONFINED and CYCLIC that make an exception for cases where > there is only a single choice available.? A ButtonGroup for > example may want to react differently depending on whether it > has 0, 1 or more buttons.? Whether these should be enshrined > with a custom enum value, or perhaps a flag, or just left up > to a custom implementation is something we'd need to decide still. > > ## Use Cases > > 1) User wants to change the behavior of a control from its > default to something else (ie. a Control that is CYCLIC can be > changed to OPEN or CONFINED) > > Just call the setters with the appropriate preferred policy.? > This could be done in CSS for maximum convenience to enable a > global change of all similar controls. > > 2) User wants to act on Traversal events that the standard > policy leaves to bubble up > > Just install a Traversal event handler either on the control > or on its parent (depending on their needs).? A potential > action to an unused Traversal event could be to close a > Dialog/Toast popup, or a custom behavior like selecting the > first/last item or next/previous row (ie. if I press "RIGHT" > and there is no further right item, a user could decide to > have this select the first item again in the current Row or > the first item in the **next** Row). > > 3) User wants to do crazy custom navigation > > Set both policies to?IGNORED, then install your own event > handler (or use the setOnTraversalHandler to completely > override the handler). Now react on the Traversal events, > consuming them at will and changing focus to whatever control > you desire. > > 4) User wants to change what keys are considered navigation keys > > Install event handler on Scene (or any intermediate Parent) > for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and > sent out a corresponding Traversal event > > 5) User wants to use keys that are considered navigation keys > for their own purposes > > Just install a KeyEvent handler as usual, without having to > worry that Skins/Controls eat these events before you can get > to them > > 6) User wants to stop a control from reacting to traversal > events, without filtering navigation keys completely > > With the separation of unconsumed KeyEvents into > TraversalEvents, a user can now block only the latter to > achieve this goal without having to blanket block certain > KeyEvents. > > ----- > > About the Proposal: > > I think the Goals are fine as stated, although I think we > differ on what the Traversal events signify. > > I think CSS support should be considered a possible future > goal. The proposal should therefore take into account that we > may want to offer this in the future. > > Motivation looks okay. > > > The focus traversal is provided by the FocusTraversal class > which offers static methods for traversing focus in various > directions, determined by the TraversalDirection enum. > > I think these methods don't need to be exposed with a good > selection of standard TraversalPolicy options. After all, > there are only so many ways that you can do a sensible > navigation action without confusing the user, and therefore I > think these policy options will cover 99% of the use cases > already.? For the left over 1% we could **consider** providing > these focus traversal functions as a separate public API, but > I would have them return the Node they would suggest, and > leave the final decision to call requestFocus up to the > caller. Initially however I think there is already more than > enough power for custom implementations to listen to Traversal > events and do their own custom navigation.? If it is not > similar to one of the standard navigation options, the > traverseUp/Down functions won't be of much use then anyway. > > About your typical example: > > ??? Node from = ... > ??? switch (((KeyEvent)event).getCode()) { > ??? case UP: > FocusTraversal.traverse(from, TraversalDirection.UP, > TraversalMethod.KEY); > ??????? event.consume(); > ??????? break; > ??? case DOWN: > ??????? // or use the convenience method > FocusTraversal.traverseDown(from); > ??????? event.consume(); > ??????? break; > ??? } > > I think this is not a good way to deal with events. > > 1) The event is consumed regardless of the outcome of > traverse.? What if focus did not change?? Should the event be > consumed? > > 2) This is consuming KeyEvents directly, robbing the user of > the opportunity to act on keys considered "special" by FX. > > 3) This code is not only consuming KeyEvents directly, but > also deciding what keys are navigation keys. > > So I think this example?code should be different. However, > first I expect that in most cases, configuring a different > traversal policy on your Parent subclass will already be > sufficient in almost all cases (especially if we look at FX > current controls and see if the suggested policies would cover > those use cases).? So this code will almost never be needed.? > However, in the event that you need something even more > specific, you may consider handling Traversal events directly. > In which case the code should IMHO look something like this: > > ??? Node from = ... > > ??? Node result = switch(traversalEvent.getEventType()) { > ?? ?? case TraversalEvent.UP -> FocusTraversals.findUp(from); > ?? ?? case TraversalEvent.DOWN -> FocusTraversals.findDown(from); > ? ? ? // etc > ?? } > > ??? if (result != null) { > ???????? result.requestFocus(); > ???????? traversalEvent.consume(); > ??? } > > Note that the above code leaves the final decision to call > requestFocus up to the caller.? It also allows the caller to > distinguish between the case where there is no suitable Node > in the indicated direction and act accordingly. > > This allows it to?NOT consume the event if it prefers its > Parent to handle it (if the control doesn't want CYCLIC or > CONFINED style navigation).? It also allows it to further > scrutinize the suggested Node, and if it decides it does not > like it (due to some property or CSS style or whatever) it may > follow up with another findXXX call or some other option to > pick the Node it wants.? It also allows (in the case of no > Node being found) to pick its own preferred Node in those > cases. In other words, it is just far more flexible. > > I'm not sure yet where to place these static helper methods > (if we decide to expose them at all initially), or even if > they should be static.? Given that its first parameter is > always a Node, a non-static location for them could simply be > on Node itself, in which case the calling convention would > become "Node result? = from.findTraversableUp()" (suggested > name only) > > > Focus traversals generate a new type of event, encapsulated > by the class TraversalEvent which extends javafx.event.Event, > using the event type TraversalEvent.NODE_TRAVERSED. > > What is the point of this event? If you want to know that > focus changed, you can add a listener to > Scene.focusOwnerProperty.? What does it mean if I filter this > event? What if I consume it?? I don't think this should be an > event at all, unless implemented as I suggested above, where > consuming/filtering/bubbling can be used to control how > controls will react to navigation events. > > --John > > On 03/09/2024 21:33, Andy Goryachev wrote: > > Dear fellow developers: > > I'd like to propose the public focus traversal API: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > > Draft PR: > > https://github.com/openjdk/jfx/pull/1555 > > > Your comments and suggestions will be warmly accepted and > appreciated. > > Thank you > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Thu Sep 19 15:38:14 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 19 Sep 2024 17:38:14 +0200 Subject: How navigation currently works in FX, and an enhancement proposal Message-ID: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> I've been looking into how exactly navigation keys are being used in FX, and who is responsible for handling them: - Controls can choose to install navigational keys directly in their input map (using FocusTraversalInputMap::getFocusTraversalMappings) - Controls can choose to do nothing and leave navigation keys to bubble up to Scene, at which point Scene will act on any unconsumed navigation keys (in the same was as the traversal mappings would) Scene basically is capable of almost all navigation you could possibly want out of the box.? Any control that does not install navigation keys, and leaves said keys to bubble up gets navigation for **free**.? This is almost all controls in JavaFX, and it makes sense as Controls should not care about navigation, they should only care about key presses that affect them directly.? Navigation should be a concern somewhere higher up in the hierarchy. So why do some controls install their own navigation keys? There are two answers: 1. For some controls, navigation is conditional. A Spinner only allows directional navigation for the left/right keys, or up/down keys depending on its orientation. 2. There is an unfortunate choice in ScrollPane that consumes directional keys for scrolling purposes, and so if such keys were left to bubble up, they would not end up at Scene.? Any control supporting directional navigation therefore must **specifically** install these bindings directly, even though navigation is not their concern (a Button cares about being pressed, not about activating unrelated controls nearby). The ScrollPane eating directional keys is an odd choice. In order for it to do so one of the following must be true: - A control inside it has focus that should act on directional navigation, but forgot to install navigation bindings (a custom control).? Such a control would work perfectly when not part of a ScrollPane (as Scene would then handle directional navigation), but break when placed inside it.? Note that all JavaFX controls do this "properly".? I couldn't find any?controls that would leave directional keys to bubble up for a ScrollPane to consume. - The ScrollPane itself has focus; this can only happen when directly selected with the mouse (or focus traversable is set to true) and no specific control inside the pane was selected.? The ScrollPane receives the ":focused" style, clearly indicating that it is the target for keyboard events to the user. In short, ScrollPane is making navigation?a lot more complex within FX than it needs to be.? Especially custom controls that do not have access (currently) to install navigational bindings will suffer from this, and will have to resort to their own navigation implementation for directional keys when placed inside a ScrollPane. # Proposal I think ScrollPane violates what I think should be a fundamental rule.? Keys should only be consumed by what the user perceives as the focused control (ie. the one outlined with a highlighted border), with the only exceptions being short cuts (from a menu) or mnemonics.? Containers such controls happen to be placed in should NOT consume key events -- the container is not the control with the focus, and so would confuse the user.??Only ScrollPane is violating this currently.? Note that if the ScrollPane has focus itself (and it has the :focused highlight) then it is perfectly fine and expected for it to consume keys as much as it wants. This is why I think we should modify ScrollPane to not consume the directional keys, unless it specifically has the focus.? All other controls can then remove their navigational bindings and leave them to bubble up to Scene, cleaning up their behaviors so they can focus on other?concerns.? Custom controls would no longer need to install navigational bindings either, and would not need to worry about being placed inside a ScrollPane and having their directional navigation broken. Optional, but recommended, controls like Spinner should only act on the directional keys intended for them, and leave the ones they can't use to bubble up.? So a vertical spinner would consume up/down for changing the spinner value, but would leave left/right untouched for Scene to handle.? Controls that install a full set of navigational keys (like Button, ListView and TitledPane) don't need to do so anymore. I think I will file a ticket for this soon, but I'm curious what others think of this analysis. Note that by solving this problem, the need to make navigation functionality available to custom controls severely diminishes as one can simple leave the KeyEvents responsible for standard navigation to bubble up (recommended as this may be different for each platform). --John From angorya at openjdk.org Thu Sep 19 15:57:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 15:57:44 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: <1YBGokdOaqqqMUiYThmTWEWNPx7IiZhtyyesc08BwN8=.f066d1d3-b8f5-4be8-a829-c472633b5265@github.com> On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... next batch. will continue with Node_effectiveOrientation_Test.java modules/javafx.graphics/src/test/java/test/javafx/concurrent/ScheduledServiceTest.java line 95: > 93: } > 94: > 95: @Override public void setup(TestServiceFactory factory) { could have inserted a newline after the annotation... modules/javafx.graphics/src/test/java/test/javafx/concurrent/ServiceLifecycleTest.java line 2107: > 2105: } > 2106: > 2107: private void assertThrowsException(Class exceptionClass, final ServiceTestExecution c) throws Throwable { minor: maybe `Class exceptionClass` ? modules/javafx.graphics/src/test/java/test/javafx/concurrent/ServiceTestBase.java line 31: > 29: import java.util.concurrent.Executor; > 30: import javafx.concurrent.Service; > 31: //import org.junit.jupiter.api.BeforeEach; NOTE: revert once parametrized classes are added minor: this line is probably unnecessary modules/javafx.graphics/src/test/java/test/javafx/concurrent/ServiceTestBase.java line 65: > 63: // NOTE: This should be reverted once parametrized class tests are added to JUnit5 > 64: // For now, tests call this manually > 65: // @BeforeEach I wonder if we should log a JBS ticket to fix parameterized tests by reverting `@BeforeEach`, and then simply refer to it? This way, once junit supports that, we can easily grep the code. (I've used a different comment for same purpose) What do you think? ------------- PR Review: https://git.openjdk.org/jfx/pull/1566#pullrequestreview-2315838830 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767007023 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767029812 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767031814 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767036118 From angorya at openjdk.org Thu Sep 19 15:57:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 15:57:44 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: <1YBGokdOaqqqMUiYThmTWEWNPx7IiZhtyyesc08BwN8=.f066d1d3-b8f5-4be8-a829-c472633b5265@github.com> References: <1YBGokdOaqqqMUiYThmTWEWNPx7IiZhtyyesc08BwN8=.f066d1d3-b8f5-4be8-a829-c472633b5265@github.com> Message-ID: On Thu, 19 Sep 2024 15:06:07 GMT, Andy Goryachev wrote: >> This PR converts all tests in `modules/javafx.graphics` to use JUnit5. >> >> ## Details >> >> Trivial changes resolved by first four commits: >> - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) >> - Message Strings in `assert*` calls moved to the end to follow 5's argument order >> - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations >> - Some test formatting unification - keeping annotations on a separate line from method definition >> - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. >> >> Non-trivial changes: >> - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: >> - `DirtyRegionTestBase` >> - `CssMethodsTestBase` >> - `ObjectMethodsTestBase` >> - `OnInvalidateMethodsTestBase` >> - `PropertiesTestBase` >> - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized >> - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` >> - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 >> >> At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. >> >> As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. >> >> ## Results >> >> Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: >> >> | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | >> | ------------ | ------ | ------ | >> | Test count | 23272 | 23275 | >> | Failures | 0 | 0 | >> | Ignored | 99 | 102 | >> | Successful % | 100% | 100% | >> >> The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion... > > modules/javafx.graphics/src/test/java/test/javafx/concurrent/ScheduledServiceTest.java line 95: > >> 93: } >> 94: >> 95: @Override public void setup(TestServiceFactory factory) { > > could have inserted a newline after the annotation... this particular test is not parameterized, so you could use `@BeforeEach` to setup the factory. Same for the `ServiceLifecycleTest`. it won't work for `ServiceExceptionTest` because it is parameterized. but this code is ok too. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767016263 From jbhaskar at openjdk.org Thu Sep 19 16:19:20 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 19 Sep 2024 16:19:20 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 Message-ID: Successfully converted Non-parametrized base tests to JUnit 5 ------------- Commit messages: - 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 - 8339515: [TestBug] Convert web tests to JUnit 5 Changes: https://git.openjdk.org/jfx/pull/1576/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1576&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339511 Stats: 3550 lines in 215 files changed: 902 ins; 190 del; 2458 mod Patch: https://git.openjdk.org/jfx/pull/1576.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1576/head:pull/1576 PR: https://git.openjdk.org/jfx/pull/1576 From jbhaskar at openjdk.org Thu Sep 19 16:27:26 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Thu, 19 Sep 2024 16:27:26 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: > Successfully converted Non-parametrized base tests to JUnit 5 Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Revert "8339515: [TestBug] Convert web tests to JUnit 5" This reverts commit 86f73271142049a2c0162d987aee6bd0fcb2f82a. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1576/files - new: https://git.openjdk.org/jfx/pull/1576/files/a43cdbdd..fada1b16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1576&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1576&range=00-01 Stats: 1185 lines in 44 files changed: 134 ins; 127 del; 924 mod Patch: https://git.openjdk.org/jfx/pull/1576.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1576/head:pull/1576 PR: https://git.openjdk.org/jfx/pull/1576 From hmeda at openjdk.org Thu Sep 19 17:34:56 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 19 Sep 2024 17:34:56 GMT Subject: RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 [v2] In-Reply-To: References: Message-ID: > Updated additional webkit-619.1 fixes from webkitgtk-2.44.4. Build is successful on all platforms.No issues seen Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Update copyright ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1570/files - new: https://git.openjdk.org/jfx/pull/1570/files/2170f347..b62cf532 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1570&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1570&range=00-01 Stats: 50 lines in 2 files changed: 50 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1570.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1570/head:pull/1570 PR: https://git.openjdk.org/jfx/pull/1570 From hmeda at openjdk.org Thu Sep 19 17:34:56 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 19 Sep 2024 17:34:56 GMT Subject: RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 12:22:08 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright > > modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/HistoryItemClientJava.cpp line 1: > >> 1: #include "HistoryItemClientJava.h" > > Where did this file come from? I don't see any changes related to HistoryItemClient in the 2.44.4 release of WebKitGTK? > > Presuming we need this file, it will need a proper copyright header. This file has been added in order to adapt to the changes to the interface added as part of webkit commit def02cb5c4c24ed8a05e4e5075eb6ec95216ef80 in HistoryItem.h. Added the copyright header. > modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/HistoryItemClientJava.h line 1: > >> 1: #pragma once > > Presuming we need this file, it will need a proper copyright header. Updated the copyright ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1570#discussion_r1767328674 PR Review Comment: https://git.openjdk.org/jfx/pull/1570#discussion_r1767329292 From angorya at openjdk.org Thu Sep 19 17:55:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 17:55:45 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... on the other hand, @kevinrushforth mention that it is unlikely we would spend more time on parameterized tests, so please ignore my comment about JBS ticket. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1566#issuecomment-2361830687 From kcr at openjdk.org Thu Sep 19 18:29:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 19 Sep 2024 18:29:49 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting Message-ID: This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. ### Testing instructions I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. ------------- Commit messages: - 8340405: JavaFX shutdown hook can hang preventing app from exiting Changes: https://git.openjdk.org/jfx/pull/1574/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1574&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340405 Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1574.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1574/head:pull/1574 PR: https://git.openjdk.org/jfx/pull/1574 From kcr at openjdk.org Thu Sep 19 18:29:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 19 Sep 2024 18:29:49 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: <28DpCn1DARuWPcE-nb52DbH7_Ya1sniELnB6PTuDaKY=.c725f46a-241d-475d-b4a9-2d389084a6e4@github.com> On Thu, 19 Sep 2024 14:03:45 GMT, Kevin Rushforth wrote: > This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. > > The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. > > This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. > > I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. > > ### Testing instructions > > I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. Reviewer: @arapte and either @lukostyra or @andy-goryachev-oracle This should be a safe fix, but I would like a second reviewer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1574#issuecomment-2361153795 From cjgunzel at gmail.com Thu Sep 19 18:30:02 2024 From: cjgunzel at gmail.com (Chuck Davis) Date: Thu, 19 Sep 2024 11:30:02 -0700 Subject: How navigation currently works in FX, and an enhancement proposal In-Reply-To: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> References: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> Message-ID: Focus traversal in JavaFX is one of the two things I miss most about Swing. With Swing we could access the policy and move to the next or previous object programmatically -- a feature that is sadly lacking in FX. For those of us old enough to remember the good old days of character interfaces, hitting the enter key was the way to move to the next input field. I still maintain that feature but I've had to write all the code myself and for each field it has to be hard coded -- a real nuisance and totally unnecessary if we could access the TraversalPolicy and call next() or previous() like we did in Swing. For example, place characters in a TextField and hit the enter key to trigger an event. Execute the method to process the verification, conversion, formatting and then TraversalPolicy.next() places focus on the next input field -- good old efficient input and finger action. No unnecessary and inefficient hand movements. My $.02 on this whole discussion in this and associated threads regarding addressing the FX TraversalPolicy. On Thu, Sep 19, 2024 at 8:39?AM John Hendrikx wrote: > I've been looking into how exactly navigation keys are being used in FX, > and who is responsible for handling them: > > - Controls can choose to install navigational keys directly in their > input map (using FocusTraversalInputMap::getFocusTraversalMappings) > - Controls can choose to do nothing and leave navigation keys to bubble > up to Scene, at which point Scene will act on any unconsumed navigation > keys (in the same was as the traversal mappings would) > > Scene basically is capable of almost all navigation you could possibly > want out of the box. Any control that does not install navigation keys, > and leaves said keys to bubble up gets navigation for **free**. This is > almost all controls in JavaFX, and it makes sense as Controls should not > care about navigation, they should only care about key presses that > affect them directly. Navigation should be a concern somewhere higher > up in the hierarchy. > > So why do some controls install their own navigation keys? > > There are two answers: > > 1. For some controls, navigation is conditional. A Spinner only allows > directional navigation for the left/right keys, or up/down keys > depending on its orientation. > 2. There is an unfortunate choice in ScrollPane that consumes > directional keys for scrolling purposes, and so if such keys were left > to bubble up, they would not end up at Scene. Any control supporting > directional navigation therefore must **specifically** install these > bindings directly, even though navigation is not their concern (a Button > cares about being pressed, not about activating unrelated controls nearby). > > The ScrollPane eating directional keys is an odd choice. In order for it > to do so one of the following must be true: > > - A control inside it has focus that should act on directional > navigation, but forgot to install navigation bindings (a custom > control). Such a control would work perfectly when not part of a > ScrollPane (as Scene would then handle directional navigation), but > break when placed inside it. Note that all JavaFX controls do this > "properly". I couldn't find any controls that would leave directional > keys to bubble up for a ScrollPane to consume. > > - The ScrollPane itself has focus; this can only happen when directly > selected with the mouse (or focus traversable is set to true) and no > specific control inside the pane was selected. The ScrollPane receives > the ":focused" style, clearly indicating that it is the target for > keyboard events to the user. > > In short, ScrollPane is making navigation a lot more complex within FX > than it needs to be. Especially custom controls that do not have access > (currently) to install navigational bindings will suffer from this, and > will have to resort to their own navigation implementation for > directional keys when placed inside a ScrollPane. > > # Proposal > > I think ScrollPane violates what I think should be a fundamental rule. > Keys should only be consumed by what the user perceives as the focused > control (ie. the one outlined with a highlighted border), with the only > exceptions being short cuts (from a menu) or mnemonics. Containers such > controls happen to be placed in should NOT consume key events -- the > container is not the control with the focus, and so would confuse the > user. Only ScrollPane is violating this currently. Note that if the > ScrollPane has focus itself (and it has the :focused highlight) then it > is perfectly fine and expected for it to consume keys as much as it wants. > > This is why I think we should modify ScrollPane to not consume the > directional keys, unless it specifically has the focus. All other > controls can then remove their navigational bindings and leave them to > bubble up to Scene, cleaning up their behaviors so they can focus on > other concerns. Custom controls would no longer need to install > navigational bindings either, and would not need to worry about being > placed inside a ScrollPane and having their directional navigation broken. > > Optional, but recommended, controls like Spinner should only act on the > directional keys intended for them, and leave the ones they can't use to > bubble up. So a vertical spinner would consume up/down for changing the > spinner value, but would leave left/right untouched for Scene to > handle. Controls that install a full set of navigational keys (like > Button, ListView and TitledPane) don't need to do so anymore. > > I think I will file a ticket for this soon, but I'm curious what others > think of this analysis. > > Note that by solving this problem, the need to make navigation > functionality available to custom controls severely diminishes as one > can simple leave the KeyEvents responsible for standard navigation to > bubble up (recommended as this may be different for each platform). > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Sep 19 18:30:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 19 Sep 2024 18:30:52 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely Message-ID: This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. ### Testing instructions I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. The default timeout values for test and lifecycle methods can be modified using a gradle property: * `JUNIT_TEST_TIMEOUT` : default = 120s * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test ------------- Commit messages: - Fix typo (extra spaces) in system property name - 8328629: JUnit test without a timeout value can hang indefinitely Changes: https://git.openjdk.org/jfx/pull/1575/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328629 Stats: 108 lines in 29 files changed: 81 ins; 2 del; 25 mod Patch: https://git.openjdk.org/jfx/pull/1575.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1575/head:pull/1575 PR: https://git.openjdk.org/jfx/pull/1575 From kcr at openjdk.org Thu Sep 19 18:30:53 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 19 Sep 2024 18:30:53 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 14:15:23 GMT, Kevin Rushforth wrote: > This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). > > JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). > > While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. > > ### Testing instructions > > I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. > > The default timeout values for test and lifecycle methods can be modified using a gradle property: > > * `JUNIT_TEST_TIMEOUT` : default = 120s > * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s > > For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: > > > gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test Reviewer: @arapte or @andy-goryachev-oracle modules/javafx.controls/src/test/java/test/javafx/scene/control/AlertTest.java line 96: > 94: } catch (InterruptedException e) { > 95: // fail(e); > 96: throw new AssertionError(e); I left the commented out "fail(e)" as a possibly better alternative once these tests are updated to JUnit 5, which is under review at PR #1569. Depending on the timing of integrating that PR and this one, I will either merge in master (I've already done a test merge and there are no merge conflicts) and update these calls to use "fail" or file a follow-on bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1575#issuecomment-2361155717 PR Review Comment: https://git.openjdk.org/jfx/pull/1575#discussion_r1766935521 From john.hendrikx at gmail.com Thu Sep 19 18:48:12 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 19 Sep 2024 20:48:12 +0200 Subject: How navigation currently works in FX, and an enhancement proposal In-Reply-To: References: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> Message-ID: <5be75966-ca82-4ea8-aa57-3e746bdabc55@gmail.com> This should certainly also become possible at some point.? There already is internal API to find the next/previous or left/right Node, it is more a question how to expose this as an API at this point. For this specific case, you'd probably want to change focus in an ActionEvent, or possibly a KeyEvent handler that looks for ENTER. Then in the handler you'd probably just want to ask Scene to move focus to the logical next Node.? When in an event handler, that could be something like: ????? oneOfMyNodes.getScene().focusNext(); or: ????? oneOfMyNodes.getScene().focus(Direction.NEXT); From what I can see, these methods would be trivial to add to Scene, as all the traversal methods are already present there.? I also think that it would be the correct place to have them, as there is no focus without a Scene and Scene already has the focusOwner property. Currently this all is already possible for the user, but you'd need to build your own util that finds the next Node (there are some simple rules for this, like finding the current child index in the parent, going up the stack of parents when on the last child, etc... I think I may have it somewhere in a utility already :)) --John On 19/09/2024 20:30, Chuck Davis wrote: > Focus traversal in JavaFX is one of the two things I miss most about > Swing.? With Swing we could access the policy and move to the next or > previous object programmatically -- a feature that is sadly lacking in > FX.? For those of us old enough to remember the good old days of > character interfaces, hitting the enter key was the way to move to the > next input field.? I still maintain that feature but I've had to write > all the code myself and for each field it has to be hard coded -- a > real nuisance and totally unnecessary if we could access the > TraversalPolicy and call next() or previous() like we did in Swing. > > For example, place characters in a TextField and hit the enter key to > trigger an event.? Execute the method to process the verification, > conversion, formatting and then TraversalPolicy.next() places focus on > the next input field -- good old efficient input and finger action.? > No unnecessary and inefficient hand movements. > > My $.02 on this whole discussion in this and associated threads > regarding addressing the FX TraversalPolicy. > > On Thu, Sep 19, 2024 at 8:39?AM John Hendrikx > wrote: > > I've been looking into how exactly navigation keys are being used > in FX, > and who is responsible for handling them: > > - Controls can choose to install navigational keys directly in their > input map (using FocusTraversalInputMap::getFocusTraversalMappings) > - Controls can choose to do nothing and leave navigation keys to > bubble > up to Scene, at which point Scene will act on any unconsumed > navigation > keys (in the same was as the traversal mappings would) > > Scene basically is capable of almost all navigation you could > possibly > want out of the box.? Any control that does not install navigation > keys, > and leaves said keys to bubble up gets navigation for **free**.? > This is > almost all controls in JavaFX, and it makes sense as Controls > should not > care about navigation, they should only care about key presses that > affect them directly.? Navigation should be a concern somewhere > higher > up in the hierarchy. > > So why do some controls install their own navigation keys? > > There are two answers: > > 1. For some controls, navigation is conditional. A Spinner only > allows > directional navigation for the left/right keys, or up/down keys > depending on its orientation. > 2. There is an unfortunate choice in ScrollPane that consumes > directional keys for scrolling purposes, and so if such keys were > left > to bubble up, they would not end up at Scene.? Any control supporting > directional navigation therefore must **specifically** install these > bindings directly, even though navigation is not their concern (a > Button > cares about being pressed, not about activating unrelated controls > nearby). > > The ScrollPane eating directional keys is an odd choice. In order > for it > to do so one of the following must be true: > > - A control inside it has focus that should act on directional > navigation, but forgot to install navigation bindings (a custom > control).? Such a control would work perfectly when not part of a > ScrollPane (as Scene would then handle directional navigation), but > break when placed inside it.? Note that all JavaFX controls do this > "properly".? I couldn't find any?controls that would leave > directional > keys to bubble up for a ScrollPane to consume. > > - The ScrollPane itself has focus; this can only happen when directly > selected with the mouse (or focus traversable is set to true) and no > specific control inside the pane was selected.? The ScrollPane > receives > the ":focused" style, clearly indicating that it is the target for > keyboard events to the user. > > In short, ScrollPane is making navigation?a lot more complex > within FX > than it needs to be.? Especially custom controls that do not have > access > (currently) to install navigational bindings will suffer from > this, and > will have to resort to their own navigation implementation for > directional keys when placed inside a ScrollPane. > > # Proposal > > I think ScrollPane violates what I think should be a fundamental > rule. > Keys should only be consumed by what the user perceives as the > focused > control (ie. the one outlined with a highlighted border), with the > only > exceptions being short cuts (from a menu) or mnemonics. Containers > such > controls happen to be placed in should NOT consume key events -- the > container is not the control with the focus, and so would confuse the > user.??Only ScrollPane is violating this currently.? Note that if the > ScrollPane has focus itself (and it has the :focused highlight) > then it > is perfectly fine and expected for it to consume keys as much as > it wants. > > This is why I think we should modify ScrollPane to not consume the > directional keys, unless it specifically has the focus.? All other > controls can then remove their navigational bindings and leave > them to > bubble up to Scene, cleaning up their behaviors so they can focus on > other?concerns.? Custom controls would no longer need to install > navigational bindings either, and would not need to worry about being > placed inside a ScrollPane and having their directional navigation > broken. > > Optional, but recommended, controls like Spinner should only act > on the > directional keys intended for them, and leave the ones they can't > use to > bubble up.? So a vertical spinner would consume up/down for > changing the > spinner value, but would leave left/right untouched for Scene to > handle.? Controls that install a full set of navigational keys (like > Button, ListView and TitledPane) don't need to do so anymore. > > I think I will file a ticket for this soon, but I'm curious what > others > think of this analysis. > > Note that by solving this problem, the need to make navigation > functionality available to custom controls severely diminishes as one > can simple leave the KeyEvents responsible for standard navigation to > bubble up (recommended as this may be different for each platform). > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Sep 19 18:59:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 18:59:42 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: <2_-n02d2RwePxlgbMkhAUcLNvKQW88iaHrDzFqpZFy4=.77d35239-8d40-4000-bac6-74f8842175aa@github.com> On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... modules/javafx.graphics/src/test/java/test/javafx/scene/TreeShowingPropertyTest.java line 68: > 66: }; > 67: > 68: return Arrays.asList(new Object[][] { { supplier1 }, { supplier2 } }); the change may not be fully equivalent: the use of `Supplier` defers the moment of creation until each test is started. it is very likely that the parameters() method is called once for each test, creating all the instances before any of the tests cases are executed. this still might be ok because a) the tests are headless b) the nodes are not inserted into the scene graph c) instances are not reused anywhere modules/javafx.graphics/src/test/java/test/javafx/scene/effect/BoxBlur_properties_Test.java line 44: > 42: public final class BoxBlur_properties_Test extends PropertiesTestBase { > 43: > 44: public static Stream data() { you _could_ return the `List` directly modules/javafx.graphics/src/test/java/test/javafx/scene/effect/EffectInputTest.java line 71: > 69: } > 70: } > 71: return stream; (here and elsewhere, you could return the List directly) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767383945 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767389182 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767392303 From angorya at openjdk.org Thu Sep 19 19:15:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 19:15:52 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java line 47: > 45: HBox hbox; > 46: > 47: @BeforeEach public void setUp() { minor: newline? modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionCSSTest.java line 685: > 683: } > 684: > 685: @Test minor: indent ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767459128 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767459882 From angorya at openjdk.org Thu Sep 19 19:24:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 19:24:42 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: <8366oZ6d6o8JmUVXn9M46j1_yFvQnLH6lOqoUQNT_tc=.d0452e93-e1dd-4d45-98d7-c2184448f96a@github.com> On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... modules/javafx.graphics/src/test/java/test/javafx/scene/transform/AffineOperationsTest.java line 1929: > 1927: List arguments = TransformOperationsTest.getParams().toList(); > 1928: for (Arguments arg : arguments) { > 1929: Object[] arr = arg.get(); that's why it would be easier to return List from `getParams()` I might suggest to fix this in this class, and undo the unwrapping, but this code will definitely work. up to you. modules/javafx.graphics/src/test/java/test/javafx/scene/transform/AffineOperationsTest.java line 2781: > 2779: @ParameterizedTest > 2780: @MethodSource("getParams") > 2781: public void nonInvertibleExceptionShoudCancelAtomicOperation(Affine affine) { this is one humongous test!!! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767484281 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767488237 From angorya at openjdk.org Thu Sep 19 19:32:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 19:32:40 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... modules/javafx.graphics/src/test/java/test/javafx/scene/transform/TransformOperationsTest.java line 2944: > 2942: boolean isInvertible, > 2943: Class inverseType) { > 2944: assertCol2D(t, is2d, MatrixType.MT_2D_2x3, 0, null, false, false, false); the trick with assigning instance fields might have helped here. I discovered this too late myself, and now it's probably too late anyway... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767496314 From cjgunzel at gmail.com Thu Sep 19 19:49:21 2024 From: cjgunzel at gmail.com (Chuck Davis) Date: Thu, 19 Sep 2024 12:49:21 -0700 Subject: How navigation currently works in FX, and an enhancement proposal In-Reply-To: <5be75966-ca82-4ea8-aa57-3e746bdabc55@gmail.com> References: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> <5be75966-ca82-4ea8-aa57-3e746bdabc55@gmail.com> Message-ID: That is exactly what FX needs per your examples. On Thu, Sep 19, 2024 at 11:48?AM John Hendrikx wrote: > oneOfMyNodes.getScene().focusNext(); > > or: > > oneOfMyNodes.getScene().focus(Direction.NEXT); > And why should every developer have to do their own utilities to accomplish something so basic -- Swing got it right. > I think I may have it somewhere in a utility already :)) > > --John > And with inflation kicking in it's now my $.04 !! ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Sep 19 20:00:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 20:00:42 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... modules/javafx.graphics/src/test/java/test/javafx/stage/WindowTest.java line 222: > 220: > 221: @Test > 222: public void testSizeToSceneBeforeEachShowing() { this looks like unrelated change: - why was the name changed? - why change this method and not testSizeToSceneAfterShowing? modules/javafx.graphics/src/test/jslc/com/sun/scenario/effect/compiler/lexer/TypeTest.java line 35: > 33: > 34: @Test > 35: public void floatScalar() { for other reviewers: I think this cleanup is good. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767520305 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1767522869 From angorya at openjdk.org Thu Sep 19 21:06:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 21:06:44 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: <_oL1HHwOrDmD2g__AF7Wfawqhe0y8gIwrc-HgIglq4c=.e1c2cf9f-45e3-4d90-a2ae-2b8d1ceb3597@github.com> On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... I looked at each line - this is one monumental piece of work, good job @lukostyra ! Areas that I checked explicitly: - before -> beforeEach, etc. - expected -> assertThrows, if same exception - parameterized tests I did not actually run the tests. I left some minor comments, but overall this is good even as is. Will re-approve if you decide to make fixes. should we set a minimum of two reviewers? please do not integrate just yet. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1566#pullrequestreview-2316744667 PR Comment: https://git.openjdk.org/jfx/pull/1566#issuecomment-2362194729 From angorya at openjdk.org Thu Sep 19 21:09:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 21:09:47 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: <9bAzy4lHLe44jsTvkQHLnN2IonakEca7NYQI97jmQx4=.1afa965d-518f-4cda-9129-2b9894a43ba6@github.com> References: <9bAzy4lHLe44jsTvkQHLnN2IonakEca7NYQI97jmQx4=.1afa965d-518f-4cda-9129-2b9894a43ba6@github.com> Message-ID: On Thu, 19 Sep 2024 13:16:21 GMT, Lukasz Kostyra 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 18 additional commits since the last revision: >> >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 12, 9274 - 185 = 9089 >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 11, 9242 tests, 185 ignored >> - part 10 >> - part 9 cell >> - part 8 >> - ... and 8 more: https://git.openjdk.org/jfx/compare/0594f014...55b33b2c > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 517: > >> 515: } >> 516: >> 517: // @Test public void selectedTextWorksWhenSelectionIsBound() { > > This test was removed. Shouldn't we keep even commented tests around? out of scope, for this PR ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1767597282 From angorya at openjdk.org Thu Sep 19 21:19:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 21:19:22 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: unused imports ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1569/files - new: https://git.openjdk.org/jfx/pull/1569/files/96cd1972..25426093 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=00-01 Stats: 139 lines in 6 files changed: 10 ins; 121 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1569.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1569/head:pull/1569 PR: https://git.openjdk.org/jfx/pull/1569 From angorya at openjdk.org Thu Sep 19 21:31:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 21:31:41 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 21:42:08 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> unused imports > > tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 139: > >> 137: // Should throw IllegalStateException >> 138: tmpScene.snapshot(p -> { >> 139: throw new RuntimeException("Should never get here"); > > Suggestion: Use `fail`, rather than changing the Error into a RuntimeException. won't compile with `fail()`. any exception should be fine. > tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 169: > >> 167: // Should throw IllegalStateException >> 168: tmpNode.snapshot(p -> { >> 169: throw new RuntimeException("Should never get here"); > > Use `fail` instead? won't compile. > tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 265: > >> 263: // Should not get here >> 264: latch.countDown(); >> 265: throw new RuntimeException("Should never get here"); > > Use `fail` instead? won't compile here either > tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 387: > >> 385: // Should not get here >> 386: latch.countDown(); >> 387: throw new RuntimeException("Should never get here"); > > Use `fail` instead? ditto > tests/system/src/test/java/test/javafx/scene/Snapshot2Test.java line 182: > >> 180: public void testSnapshotEmptyNodeImmNoParams(boolean live, boolean useImage) { >> 181: setupEach(live, useImage); >> 182: doTestSnapshotEmptyNodeDefer(live, useImage, null); > > Question about the pattern: did you consider having the setupEach method store the params in instance variables (the ones you removed)? Then you wouldn't have needed to change any of the other methods to pass them to those methods. > > Just a thought that occurred to me as I was looking at this. What you have is fine. yeah, I realized the same thing, a bit too late. some of the later tests do use the instance variables. thank you for suggestion though! cc: @lukostyra ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1767614057 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1767616578 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1767617021 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1767617531 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1767618872 From angorya at openjdk.org Thu Sep 19 21:34:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 21:34:43 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 21:51:33 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> unused imports > > tests/system/src/test/java/test/javafx/scene/UIRenderSnapToPixelTest.java line 76: > >> 74: Assertions.assertEquals(0, ((sp.snappedBottomInset() * scale) + epsilon) % 1, 0.0001, "Bottom inset not snapped to pixel"); >> 75: Assertions.assertEquals(0, ((sp.snappedLeftInset() * scale) + epsilon) % 1, 0.0001, "Left inset not snapped to pixel"); >> 76: Assertions.assertEquals(0, ((sp.snappedRightInset() * scale) + epsilon) % 1, 0.0001, "Right inset not snapped to pixel"); > > Minor: these lines are geting a bit long. Maybe use static imports? still too long, but I do prefer having the class qualifier over static import (though static imports make more sense in the tests). I think tests is one area where we can relax the maximum line length rule (we already violate it in many places anyway) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1767622092 From angorya at openjdk.org Thu Sep 19 21:38:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 21:38:42 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 23:05:31 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> unused imports > > tests/system/src/test/java/test/robot/javafx/embed/swing/NonFocusableJFXPanelTest.java line 51: > >> 49: import static org.junit.jupiter.api.Assertions.assertNotNull; >> 50: import static org.junit.jupiter.api.Assertions.assertNull; >> 51: import static org.junit.jupiter.api.Assertions.assertSame; > > I promised myself I wasn't going to look at the imports, but... Does Eclipse really mix static and non-static imports? And are any of the static imports actually used? I suspect not in both cases, so you might just need to have Eclipse fix up your imports. comment refers to an earlier version which has been fixed since then. to answer Eclipse question, the imports are sorted like this: static come first, then I think it's in alphabetical order. and yes, don't look at the imports :-) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1767627777 From angorya at openjdk.org Thu Sep 19 21:41:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 21:41:40 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 23:17:01 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> unused imports > > tests/system/src/test/java/test/robot/javafx/scene/SRGBTest.java line 249: > >> 247: // Timeout for potential hang on XWayland, see JDK-8335468. >> 248: // the same timeout will apply to the rest of the tests >> 249: // @Test(timeout = 15000) > > I would remove this commented out line, since it is a JUnit 4 holdover. Also, would it be better to apply the `@Timeout` annotation to just this method? Either is fine with me. good point ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1767632791 From angorya at openjdk.org Thu Sep 19 21:44:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 21:44:40 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: <9W0YNhxZbij1ovDg3s78FozANTaK_EOgZh1eZTf1QoY=.878227b9-a38b-44e2-b4ad-0e2f09ef55ee@github.com> References: <9W0YNhxZbij1ovDg3s78FozANTaK_EOgZh1eZTf1QoY=.878227b9-a38b-44e2-b4ad-0e2f09ef55ee@github.com> Message-ID: On Thu, 19 Sep 2024 09:01:13 GMT, Ambarish Rapte wrote: > Here is a patch to remove unused imports. there were more. I don't have this warning enabled in Eclipse because, if enabled, I see 410+ such warnings. but thank you for noticing - I did forget to optimize imports in a few places. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2362252780 From angorya at openjdk.org Thu Sep 19 22:04:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 22:04:57 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1569/files - new: https://git.openjdk.org/jfx/pull/1569/files/25426093..d09dfb6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=01-02 Stats: 31 lines in 9 files changed: 8 ins; 16 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1569.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1569/head:pull/1569 PR: https://git.openjdk.org/jfx/pull/1569 From angorya at openjdk.org Thu Sep 19 22:37:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 22:37:00 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: <47HMAEvg732rYOiAhtV7do9qwbQcC91TkhdjcNCyIOM=.ae429e36-b675-4164-bdc4-0dfaaf8eaedc@github.com> > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: rotate test ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1569/files - new: https://git.openjdk.org/jfx/pull/1569/files/d09dfb6a..7349f483 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1569.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1569/head:pull/1569 PR: https://git.openjdk.org/jfx/pull/1569 From angorya at openjdk.org Thu Sep 19 22:41:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 22:41:42 GMT Subject: Integrated: 8328828: Monkey Tester Application Part 4 In-Reply-To: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> References: <84kTjebwGt5U8FITIYX_BkDTzxZFk5x02IYZeOrRAAw=.1b6bd693-b46e-46c2-9516-3234c6dd45fc@github.com> Message-ID: On Mon, 9 Sep 2024 19:36:29 GMT, Andy Goryachev wrote: > Further additions to the MonkeyTester application: > > - tree/table view column property sheets ? > - new pages: button, checkbox, hyperlink, menu bar, radio button, toggle button, canvas, split menu button, dnd ? > - properties... context menu ? > - context menu: table columns, toolbar items ? > - control.context menu option > - property monitor tool ? > - accessibility logging ? > > - editable combobox for double values with pre-set list (e.g. Region: min/max width etc.) > - Page -> Snapped Split Panes menu option for the control container > > This PR simply syncs up with the dev repository > https://github.com/andy-goryachev-oracle/MonkeyTest This pull request has now been integrated. Changeset: 9386ee9d Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/9386ee9d18b9f2bf3128f45b2a6f5c0969fc605b Stats: 4337 lines in 82 files changed: 3599 ins; 430 del; 308 mod 8328828: Monkey Tester Application Part 4 Reviewed-by: arapte, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1560 From kcr at openjdk.org Thu Sep 19 22:53:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 19 Sep 2024 22:53:46 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 16:27:26 GMT, Jay Bhaskar wrote: >> Successfully converted Non-parametrized base tests to JUnit 5 > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Revert "8339515: [TestBug] Convert web tests to JUnit 5" > > This reverts commit 86f73271142049a2c0162d987aee6bd0fcb2f82a. I left a few (mostly minor) comments, a few suggestions, and three problems that must be fixed: 1. You removed a total of 9 tests in three files: Before: 5538 tests (0 failures, 28 ignored) After: 5529 tests (0 failures, 28 ignored) 2. Three of the files that you converted still have some JUnit 4 imports 3. You missed converting the `expected=` parameter in the `@Test` annotation to a `convertThrows` in `VetoableObservableListTest.java`. modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ContentBindingMapTest.java line 104: > 102: Bindings.bindContent(op2, op2); > 103: } > 104: Why did you remove these test methods? They should be restored. modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ContentBindingSetTest.java line 99: > 97: public void testBind_X_Self() { > 98: Bindings.bindContent(op2, op2); > 99: } These test methods should be restored. modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java line 49: > 47: import static org.junit.jupiter.api.Assertions.assertThrows; > 48: > 49: import static org.junit.Assert.*; This file still has a JUnit 4 import. modules/javafx.base/src/test/java/test/com/sun/javafx/binding/SelectBindingTest.java line 388: > 386: public void createWithRootNull() { > 387: assertThrows(NullPointerException.class, () -> { > 388: Bindings.selectString(null, "next", "name"); Did you mean to remove the assignment? Since this is the last statement in the test method (and it will throw anyway), it doesn't really matter, but it also doesn't seem necessary to have made the change. modules/javafx.base/src/test/java/test/com/sun/javafx/binding/StringFormatterTest.java line 195: > 193: assertEquals( > 194: "" + double0 + double1 + float0 + float1 + long0 + long1 + int0 + int1 + boolean0 + boolean1 + string0 + > 195: string1 + date0 + date1, s.get()); This looks identical (I hope) except the reformatting, which appears to be unneeded. I recommend reverting the unchanged lines here and below. modules/javafx.base/src/test/java/test/com/sun/javafx/binding/StringFormatterTest.java line 317: > 315: } > 316: > 317: public class BindingsTest { Why did you add an inner class here? It is unnecessary, and without an extra annotation, it prevents the 3 tests that are inside it from running. Please revert. modules/javafx.base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java line 47: > 45: import static org.junit.Assert.assertEquals; > 46: import static org.junit.Assert.assertFalse; > 47: import static org.junit.Assert.assertTrue; This file still has JUnit 4 imports. modules/javafx.base/src/test/java/test/javafx/beans/property/adapter/ReadOnlyJavaBeanPropertyTestBase.java line 70: > 68: this.property = extractProperty(null); > 69: } > 70: catch (NoSuchMethodException e) { Minor: the previous formatting -- `} catch (NoSuchMethodException e) {` -- matches our code style guidelines, and is preferred. modules/javafx.base/src/test/java/test/javafx/binding/expression/AbstractNumberExpressionTest.java line 53: > 51: import javafx.beans.value.ObservableNumberValue; > 52: import test.javafx.binding.DependencyUtils; > 53: import javafx.collections.FXCollections; This file still has JUnit 4 imports. modules/javafx.base/src/test/java/test/javafx/collections/ModifiableObservableListBaseTest.java line 207: > 205: new ArrayList<>(List.of("a", "b", "c")), > 206: new ArrayList<>(List.of("a", "b"))) > 207: .subList(0, 2); There are only whitespace changes in this file, since it was already converted to JUnit 5. I recommend to revert your changes. modules/javafx.base/src/test/java/test/javafx/collections/VetoableObservableListTest.java line 93: > 91: > 92: @Test > 93: @Disabled You need to replace the annotation with an `assertThrows` call in the method. Otherwise, if the test ever gets re-enabled it will not do what we expect. This same comment applies to several other methods in this class. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1576#pullrequestreview-2316745565 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767594945 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767597056 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767650479 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767599801 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767602205 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767609190 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767650863 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767626096 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767651424 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767676037 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767677538 From angorya at openjdk.org Thu Sep 19 23:13:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 23:13:39 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely In-Reply-To: References: Message-ID: <0J6K18Z-pmpzDUdCNkVl9hOlm-CQ5Vpe5zTwmIpjU8o=.c708e4fb-08c9-4d95-a908-693b9f9d82ad@github.com> On Thu, 19 Sep 2024 14:15:23 GMT, Kevin Rushforth wrote: > This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). > > JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). > > While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. > > ### Testing instructions > > I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. > > The default timeout values for test and lifecycle methods can be modified using a gradle property: > > * `JUNIT_TEST_TIMEOUT` : default = 120s > * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s > > For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: > > > gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test looks good. I think it's better to wait until #1569 is integrated. tests/system/src/test/java/test/robot/javafx/scene/control/behavior/BehaviorRobotTestBase.java line 329: > 327: protected void sleep(int ms) { > 328: try { > 329: // KCR: this should be sleep(ms) not a hard-coded 1 good thing it's never called, but it is my fault. this method was later replaced with `waitForIdle` I can make this change as part of #1569 ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1575#pullrequestreview-2316886239 PR Review Comment: https://git.openjdk.org/jfx/pull/1575#discussion_r1767691417 From angorya at openjdk.org Thu Sep 19 23:20:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Sep 2024 23:20:38 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 14:03:45 GMT, Kevin Rushforth wrote: > This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. > > The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. > > This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. > > I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. > > ### Testing instructions > > I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 263: > 261: @Override public void run() { > 262: // Run dispose in a background thread and wait for up to > 263: // 5 seconds for it to finish. If it doesn't, then throw an is 5 seconds a good timeout value? could it be shorter? is it possible for the normal shutdown on a real system take more than 5 seconds? modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 276: > 274: try { > 275: if (!disposeLatch.await(5, TimeUnit.SECONDS)) { > 276: throw new InternalError("dispose timed out"); could this happen on a real system? if so, should the message be more clear and user-friendly? also, if it can be encountered in the field, it might be better to declare a constant and add a javadoc to it explaining what it is. what do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1574#discussion_r1767694260 PR Review Comment: https://git.openjdk.org/jfx/pull/1574#discussion_r1767695208 From jbhaskar at openjdk.org Fri Sep 20 02:21:26 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 20 Sep 2024 02:21:26 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: > Successfully converted Non-parametrized base tests to JUnit 5 Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Modification as per review ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1576/files - new: https://git.openjdk.org/jfx/pull/1576/files/fada1b16..2dc7148f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1576&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1576&range=01-02 Stats: 86 lines in 7 files changed: 23 ins; 18 del; 45 mod Patch: https://git.openjdk.org/jfx/pull/1576.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1576/head:pull/1576 PR: https://git.openjdk.org/jfx/pull/1576 From jbhaskar at openjdk.org Fri Sep 20 02:30:43 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 20 Sep 2024 02:30:43 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 21:04:06 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Modification as per review > > modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ContentBindingMapTest.java line 104: > >> 102: assertEquals(map2, op1); >> 103: assertEquals(map2, op2); >> 104: > > Why did you remove these test methods? They should be restored. missed it, now updated ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1767833226 From jbhaskar at openjdk.org Fri Sep 20 02:36:34 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 20 Sep 2024 02:36:34 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: > Successfully converted Non-parametrized base tests to JUnit 5 Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: one missing , formating ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1576/files - new: https://git.openjdk.org/jfx/pull/1576/files/2dc7148f..0d221c8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1576&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1576&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1576.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1576/head:pull/1576 PR: https://git.openjdk.org/jfx/pull/1576 From arapte at openjdk.org Fri Sep 20 06:12:41 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 20 Sep 2024 06:12:41 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: <5MVlKlH4BHwgDtB-vVebbgBSvpp2SDDnlNy95QxSrfs=.37a0623b-acff-45a0-92b8-f7eee4444111@github.com> On Thu, 19 Sep 2024 14:03:45 GMT, Kevin Rushforth wrote: > This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. > > The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. > > This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. > > I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. > > ### Testing instructions > > I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1574#pullrequestreview-2317349850 From arapte at openjdk.org Fri Sep 20 06:12:42 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 20 Sep 2024 06:12:42 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: <-T8euq10pGb6y0mGSzpG5iFTgyDwkkYBmcDLqZissKM=.04b4e716-cb4f-48e5-9f5e-afc058e05982@github.com> On Thu, 19 Sep 2024 23:17:31 GMT, Andy Goryachev wrote: >> This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. >> >> The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. >> >> This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. >> >> I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. >> >> ### Testing instructions >> >> I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 276: > >> 274: try { >> 275: if (!disposeLatch.await(5, TimeUnit.SECONDS)) { >> 276: throw new InternalError("dispose timed out"); > > could this happen on a real system? if so, should the message be more clear and user-friendly? > > also, if it can be encountered in the field, it might be better to declare a constant and add a javadoc to it explaining what it is. > > what do you think? I think javadoc and a property might be an overkill at this moment. The root problem is the deadlock and is very intermittent, and it hinders with the jenkins jobs. The change seems good means to avoid such situations where process keep running unchecked for hours. And if in case the frequency of issue increases or we could find a definite way of reproducing the issue, then we should try to fix the deadlock. Approving, I shall re-approve if updated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1574#discussion_r1768038274 From jvos at openjdk.org Fri Sep 20 06:22:44 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 20 Sep 2024 06:22:44 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 14:03:45 GMT, Kevin Rushforth wrote: > This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. > > The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. > > This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. > > I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. > > ### Testing instructions > > I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. I'll review this too. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1574#issuecomment-2362917666 From arapte at openjdk.org Fri Sep 20 06:24:44 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 20 Sep 2024 06:24:44 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 14:15:23 GMT, Kevin Rushforth wrote: > This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). > > JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). > > While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. > > ### Testing instructions > > I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. > > The default timeout values for test and lifecycle methods can be modified using a gradle property: > > * `JUNIT_TEST_TIMEOUT` : default = 120s > * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s > > For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: > > > gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1575#pullrequestreview-2317365374 From lkostyra at openjdk.org Fri Sep 20 06:55:42 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 06:55:42 GMT Subject: Integrated: 8339508: RenderPerf Test Application In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 09:10:08 GMT, Lukasz Kostyra wrote: > This PR migrates RenderPerf performance test application from jfx-sandbox metal branch: https://github.com/openjdk/jfx-sandbox/tree/metal/tests/performance/animation/RenderPerfTest/src/renderperf > > RenderPerf is a performance test application which draws provided number of "particles" (JFX nodes) on the screen and animates them. After some time (default 10 seconds of testing + warmup) the test automatically closes and reports FPS values. Test was developed as part of Metal backend for performance testing and we decided to integrate it with mainline for any potential further development and fixes. > > Command line options for the test: > - `-n` - number of particles to draw, defaults to 1000 > - `-t` - name of test to run, defaults to running all tests in random order. Can provide multiple tests, ex. `-t Rectangle Image` > - `-d` - test duration in seconds, defaults to 10. Can be set to 0, which means the test will run infinitely long and end only when user manually closes the stage, mostly useful for stability testing. > > Some tests use `duke.png` image provided with this PR. This is an openly available Duke Wave image taken from https://wiki.openjdk.org/display/duke/Gallery and rescaled for test purposes. > > PR consists of two commits: > - Base version of RenderPerfTest developed by @karthikpandelu > - My commit adding `-d` flag and implementing plenty of other fixes as part of [JDK-8331570](https://bugs.openjdk.org/browse/JDK-8331570) This pull request has now been integrated. Changeset: 9360575c Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/9360575cbb3209c1a0e8e758af79498cda2c679a Stats: 2326 lines in 2 files changed: 2326 ins; 0 del; 0 mod 8339508: RenderPerf Test Application 8331570: RenderPerf test: Add infinite test mode for stress-testing scenarios Co-authored-by: Karthik P K Reviewed-by: arapte, jdv ------------- PR: https://git.openjdk.org/jfx/pull/1568 From lkostyra at openjdk.org Fri Sep 20 07:00:47 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 07:00:47 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: References: <9bAzy4lHLe44jsTvkQHLnN2IonakEca7NYQI97jmQx4=.1afa965d-518f-4cda-9129-2b9894a43ba6@github.com> Message-ID: On Thu, 19 Sep 2024 21:06:53 GMT, Andy Goryachev wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TextInputControlTest.java line 517: >> >>> 515: } >>> 516: >>> 517: // @Test public void selectedTextWorksWhenSelectionIsBound() { >> >> This test was removed. Shouldn't we keep even commented tests around? > > out of scope, for this PR I'm not sure I understand. If removing old/commented out tests is out of scope of this PR then why is this one (and others) removed by this PR? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1768087834 From lkostyra at openjdk.org Fri Sep 20 08:04:50 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 08:04:50 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: <_oL1HHwOrDmD2g__AF7Wfawqhe0y8gIwrc-HgIglq4c=.e1c2cf9f-45e3-4d90-a2ae-2b8d1ceb3597@github.com> References: <_oL1HHwOrDmD2g__AF7Wfawqhe0y8gIwrc-HgIglq4c=.e1c2cf9f-45e3-4d90-a2ae-2b8d1ceb3597@github.com> Message-ID: <0q-q25NRbW-mYpr3AbCswWQxxy2ZXvw2rUBgQCcLGyE=.f9f28680-e53c-4fbc-bbf0-305c71828acf@github.com> On Thu, 19 Sep 2024 21:04:27 GMT, Andy Goryachev wrote: > should we set a minimum of two reviewers? I agree, there should be another pair of eyes looking at this. Even though it's quite repetitive, it is quite a big change, > modules/javafx.graphics/src/test/java/test/javafx/concurrent/ServiceTestBase.java line 65: > >> 63: // NOTE: This should be reverted once parametrized class tests are added to JUnit5 >> 64: // For now, tests call this manually >> 65: // @BeforeEach > > I wonder if we should log a JBS ticket to fix parameterized tests by reverting `@BeforeEach`, and then simply refer to it? > This way, once junit supports that, we can easily grep the code. > > (I've used a different comment for same purpose) > > What do you think? As mentioned in another comment, it's unlikely we'll spend more time on this later on. I will remove all the NOTE comments and commented out imports and such. > modules/javafx.graphics/src/test/java/test/javafx/stage/WindowTest.java line 222: > >> 220: >> 221: @Test >> 222: public void testSizeToSceneBeforeEachShowing() { > > this looks like unrelated change: > - why was the name changed? > - why change this method and not testSizeToSceneAfterShowing? Oops, it is unintentional yeah. Most of this patch was done with multi-caret editing to tackle multiple spots affected in the same way: - Mark affected spot - Ask my IDE to find and put a caret on all other occurrences of selected text - Edit them all at once Being in the rhythm of changing imports and `@Before` to `@BeforeEach` I probably unintentionally selected and changed this occurrence of the word "Before". I'll revert this. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1566#issuecomment-2363084472 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1768167064 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1768164494 From lkostyra at openjdk.org Fri Sep 20 11:23:45 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 11:23:45 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 15:36:53 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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 18 additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - part 9 cell > - part 8 > - ... and 8 more: https://git.openjdk.org/jfx/compare/9ec0cfd9...55b33b2c I reviewed the rest of your change, looks good outside of comments above. Will approve once we resolve those. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2363498307 From lkostyra at openjdk.org Fri Sep 20 11:59:42 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 11:59:42 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 11:45:57 GMT, Marius Hanl wrote: >> There will be plenty of uses of that all throughout this change, I wasn't 100% sure what JUnit5 expects or allows so I used the same `Stream` return type for parameter methods across all tests. > > This is fine and I think Stream is what you will in most documentations as well, so good IMO. I'll leave it as-is then. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1768468815 From kcr at openjdk.org Fri Sep 20 12:12:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 12:12:44 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 23:15:34 GMT, Andy Goryachev wrote: >> This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. >> >> The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. >> >> This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. >> >> I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. >> >> ### Testing instructions >> >> I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 263: > >> 261: @Override public void run() { >> 262: // Run dispose in a background thread and wait for up to >> 263: // 5 seconds for it to finish. If it doesn't, then throw an > > is 5 seconds a good timeout value? > > could it be shorter? > is it possible for the normal shutdown on a real system take more than 5 seconds? I think 5 seconds is a reasonable timeout value. I wouldn't want it to be any shorter nor too much longer. Normally, this is something that would take a few milliseconds. FWIW, we have a similar 5 second timeout in the (macOS-specific) initialization code that waits for app activation. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1574#discussion_r1768482493 From kcr at openjdk.org Fri Sep 20 12:12:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 12:12:44 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: <-T8euq10pGb6y0mGSzpG5iFTgyDwkkYBmcDLqZissKM=.04b4e716-cb4f-48e5-9f5e-afc058e05982@github.com> References: <-T8euq10pGb6y0mGSzpG5iFTgyDwkkYBmcDLqZissKM=.04b4e716-cb4f-48e5-9f5e-afc058e05982@github.com> Message-ID: On Fri, 20 Sep 2024 06:08:52 GMT, Ambarish Rapte wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 276: >> >>> 274: try { >>> 275: if (!disposeLatch.await(5, TimeUnit.SECONDS)) { >>> 276: throw new InternalError("dispose timed out"); >> >> could this happen on a real system? if so, should the message be more clear and user-friendly? >> >> also, if it can be encountered in the field, it might be better to declare a constant and add a javadoc to it explaining what it is. >> >> what do you think? > > I think javadoc and a property might be an overkill at this moment. The root problem is the deadlock and is very intermittent, and it hinders with the jenkins jobs. The change seems good means to avoid such situations where process keep running unchecked for hours. And if in case the frequency of issue increases or we could find a definite way of reproducing the issue, then we should try to fix the deadlock. > Approving, I shall re-approve if updated. I also think that's overkill to document this or make it programmable. This timed wait is to handle the (very rare) case of a hang/deadlock that will otherwise prevent the application from exiting at all. Remember that this code only gets run when the application calls `System.exit(int)`. I could provide a slightly more informative message. Maybe something like: Timeout shutting down the JavaFX toolkit ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1574#discussion_r1768482904 From kcr at openjdk.org Fri Sep 20 12:17:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 12:17:40 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely In-Reply-To: <0J6K18Z-pmpzDUdCNkVl9hOlm-CQ5Vpe5zTwmIpjU8o=.c708e4fb-08c9-4d95-a908-693b9f9d82ad@github.com> References: <0J6K18Z-pmpzDUdCNkVl9hOlm-CQ5Vpe5zTwmIpjU8o=.c708e4fb-08c9-4d95-a908-693b9f9d82ad@github.com> Message-ID: On Thu, 19 Sep 2024 23:09:37 GMT, Andy Goryachev wrote: >> This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). >> >> JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). >> >> While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. >> >> ### Testing instructions >> >> I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. >> >> The default timeout values for test and lifecycle methods can be modified using a gradle property: >> >> * `JUNIT_TEST_TIMEOUT` : default = 120s >> * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s >> >> For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: >> >> >> gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test > > tests/system/src/test/java/test/robot/javafx/scene/control/behavior/BehaviorRobotTestBase.java line 329: > >> 327: protected void sleep(int ms) { >> 328: try { >> 329: // KCR: this should be sleep(ms) not a hard-coded 1 > > good thing it's never called, but it is my fault. > this method was later replaced with `waitForIdle` > > I can either delete the method or fix it as part of #1569 > what do you think? If it isn't being used, then I like your idea of deleting it. Especially since this seems redundant given `Util.sleep(ms)`. I'll revert my changes and let you delete it as part of #1569. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1575#discussion_r1768487648 From lkostyra at openjdk.org Fri Sep 20 12:56:44 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 12:56:44 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 22:53:23 GMT, Andy Goryachev wrote: >> This PR converts all tests in `modules/javafx.graphics` to use JUnit5. >> >> ## Details >> >> Trivial changes resolved by first four commits: >> - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) >> - Message Strings in `assert*` calls moved to the end to follow 5's argument order >> - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations >> - Some test formatting unification - keeping annotations on a separate line from method definition >> - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. >> >> Non-trivial changes: >> - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: >> - `DirtyRegionTestBase` >> - `CssMethodsTestBase` >> - `ObjectMethodsTestBase` >> - `OnInvalidateMethodsTestBase` >> - `PropertiesTestBase` >> - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized >> - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` >> - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 >> >> At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. >> >> As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. >> >> ## Results >> >> Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: >> >> | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | >> | ------------ | ------ | ------ | >> | Test count | 23272 | 23275 | >> | Failures | 0 | 0 | >> | Ignored | 99 | 102 | >> | Successful % | 100% | 100% | >> >> The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion... > > modules/javafx.graphics/src/test/java/test/com/sun/javafx/test/CssMethodsTestBase.java line 113: > >> 111: } >> 112: >> 113: public static Arguments config(final Configuration configuration) { > > I think this can be simplified: use Configuration directly, no need to wrap it into Arguments. > But this code will work too. Changed it to `Configuration` and all parameter method sources to `Stream` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1768570580 From lkostyra at openjdk.org Fri Sep 20 13:07:45 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 13:07:45 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: <1YBGokdOaqqqMUiYThmTWEWNPx7IiZhtyyesc08BwN8=.f066d1d3-b8f5-4be8-a829-c472633b5265@github.com> Message-ID: On Thu, 19 Sep 2024 15:11:56 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/test/java/test/javafx/concurrent/ScheduledServiceTest.java line 95: >> >>> 93: } >>> 94: >>> 95: @Override public void setup(TestServiceFactory factory) { >> >> could have inserted a newline after the annotation... > > this particular test is not parameterized, so you could use `@BeforeEach` to setup the factory. Same for the `ServiceLifecycleTest`. > > it won't work for `ServiceExceptionTest` because it is parameterized. > > but this code is ok too. Changed it to use `@BeforeEach` in non-parametrized classes ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1768585178 From jvos at openjdk.org Fri Sep 20 13:12:44 2024 From: jvos at openjdk.org (Johan Vos) Date: Fri, 20 Sep 2024 13:12:44 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 14:03:45 GMT, Kevin Rushforth wrote: > This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. > > The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. > > This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. > > I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. > > ### Testing instructions > > I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. Marked as reviewed by jvos (Reviewer). This fix looks good. While we should avoid that the QuantumToolkit.dispose hangs, it is indeed good practice to take into account the (rare) possibility that it hangs. In this case, there is not much a developer or user can do, so the message returned with the InternalError doesn't matter to me. Regardless of this fix, it would still be good to have a fix for [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) (although that is likely less urgent now that the CI blocking is tackled) -- and there might be other issues that cause the dispose thread to not finish. ------------- PR Review: https://git.openjdk.org/jfx/pull/1574#pullrequestreview-2318242090 PR Comment: https://git.openjdk.org/jfx/pull/1574#issuecomment-2363704561 From lkostyra at openjdk.org Fri Sep 20 13:18:44 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 13:18:44 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: <2_-n02d2RwePxlgbMkhAUcLNvKQW88iaHrDzFqpZFy4=.77d35239-8d40-4000-bac6-74f8842175aa@github.com> References: <2_-n02d2RwePxlgbMkhAUcLNvKQW88iaHrDzFqpZFy4=.77d35239-8d40-4000-bac6-74f8842175aa@github.com> Message-ID: On Thu, 19 Sep 2024 18:20:03 GMT, Andy Goryachev wrote: >> This PR converts all tests in `modules/javafx.graphics` to use JUnit5. >> >> ## Details >> >> Trivial changes resolved by first four commits: >> - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) >> - Message Strings in `assert*` calls moved to the end to follow 5's argument order >> - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations >> - Some test formatting unification - keeping annotations on a separate line from method definition >> - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. >> >> Non-trivial changes: >> - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: >> - `DirtyRegionTestBase` >> - `CssMethodsTestBase` >> - `ObjectMethodsTestBase` >> - `OnInvalidateMethodsTestBase` >> - `PropertiesTestBase` >> - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized >> - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` >> - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 >> >> At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. >> >> As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. >> >> ## Results >> >> Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: >> >> | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | >> | ------------ | ------ | ------ | >> | Test count | 23272 | 23275 | >> | Failures | 0 | 0 | >> | Ignored | 99 | 102 | >> | Successful % | 100% | 100% | >> >> The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion... > > modules/javafx.graphics/src/test/java/test/javafx/scene/TreeShowingPropertyTest.java line 68: > >> 66: }; >> 67: >> 68: return Arrays.asList(new Object[][] { { supplier1 }, { supplier2 } }); > > the change may not be fully equivalent: the use of `Supplier` defers the moment of creation until each test is started. > > it is very likely that the parameters() method is called once for each test, creating all the instances before any of the tests cases are executed. > > this still might be ok because > a) the tests are headless > b) the nodes are not inserted into the scene graph > c) instances are not reused anywhere You're right, someone probably did this originally for a reason. I didn't know `Supplier` would work like this, but the more you know! Reverted to how it used to be, but JUnit5-ified. > modules/javafx.graphics/src/test/java/test/javafx/scene/effect/BoxBlur_properties_Test.java line 44: > >> 42: public final class BoxBlur_properties_Test extends PropertiesTestBase { >> 43: >> 44: public static Stream data() { > > you _could_ return the `List` directly Following above comments, I'll leave it as `Stream` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1768597561 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1768599900 From lkostyra at openjdk.org Fri Sep 20 13:31:06 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 13:31:06 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1566/files - new: https://git.openjdk.org/jfx/pull/1566/files/7d7d95b6..adbdf9f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1566&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1566&range=00-01 Stats: 480 lines in 19 files changed: 105 ins; 272 del; 103 mod Patch: https://git.openjdk.org/jfx/pull/1566.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1566/head:pull/1566 PR: https://git.openjdk.org/jfx/pull/1566 From lkostyra at openjdk.org Fri Sep 20 13:31:06 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 20 Sep 2024 13:31:06 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 [v2] In-Reply-To: <8366oZ6d6o8JmUVXn9M46j1_yFvQnLH6lOqoUQNT_tc=.d0452e93-e1dd-4d45-98d7-c2184448f96a@github.com> References: <8366oZ6d6o8JmUVXn9M46j1_yFvQnLH6lOqoUQNT_tc=.d0452e93-e1dd-4d45-98d7-c2184448f96a@github.com> Message-ID: On Thu, 19 Sep 2024 19:22:07 GMT, Andy Goryachev wrote: >> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > modules/javafx.graphics/src/test/java/test/javafx/scene/transform/AffineOperationsTest.java line 2781: > >> 2779: @ParameterizedTest >> 2780: @MethodSource("getParams") >> 2781: public void nonInvertibleExceptionShoudCancelAtomicOperation(Affine affine) { > > this is one humongous test!!! It definitely would be on the podium, especially for the parameter expansion... 181 tests times 32 arguments (5792 tests total). But the undisputed champion is `TransformOperationsTest` with 81 tests times 116 arguments (9396 tests) =) > modules/javafx.graphics/src/test/java/test/javafx/scene/transform/TransformOperationsTest.java line 2944: > >> 2942: boolean isInvertible, >> 2943: Class inverseType) { >> 2944: assertCol2D(t, is2d, MatrixType.MT_2D_2x3, 0, null, false, false, false); > > the trick with assigning instance fields might have helped here. > I discovered this too late myself, and now it's probably too late anyway... It is either adding a `setUp(...)` line at the start of every function, or editing these. Hard to say which path is really better, so I'd stay with this one. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1768609237 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1768611694 From kcr at openjdk.org Fri Sep 20 13:40:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 13:40:42 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 02:36:34 GMT, Jay Bhaskar wrote: >> Successfully converted Non-parametrized base tests to JUnit 5 > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > one missing , formating One remaining problem with mistakenly removed tests. The rest looks good. ------------- PR Review: https://git.openjdk.org/jfx/pull/1576#pullrequestreview-2318304282 From kcr at openjdk.org Fri Sep 20 13:40:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 13:40:43 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 21:06:40 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> one missing , formating > > modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ContentBindingSetTest.java line 99: > >> 97: public void testBind_X_Self() { >> 98: Bindings.bindContent(op2, op2); >> 99: } > > These test methods should be restored. You missed restoring these test methods. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1768628338 From kcr at openjdk.org Fri Sep 20 13:44:45 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 13:44:45 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: References: <9bAzy4lHLe44jsTvkQHLnN2IonakEca7NYQI97jmQx4=.1afa965d-518f-4cda-9129-2b9894a43ba6@github.com> Message-ID: <0M8iqZRAJEj36CGyStY-VyE-tcDCjN9XaYn20P36WNU=.a8dca587-cfa9-403a-a1fc-aff140e0c9f0@github.com> On Fri, 20 Sep 2024 06:57:51 GMT, Lukasz Kostyra wrote: >> out of scope, for this PR > > I'm not sure I understand. If removing old/commented out tests is out of scope of this PR then why is this one (and others) removed by this PR? I agree with @lukostyra -- we should not be removing any commented out tests. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1768647283 From angorya at openjdk.org Fri Sep 20 14:27:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 14:27:39 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 14:03:45 GMT, Kevin Rushforth wrote: > This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. > > The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. > > This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. > > I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. > > ### Testing instructions > > I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. thanks for clarifications! if this message is unlikely to be seen, the code is good as is. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1574#pullrequestreview-2318458205 From kcr at openjdk.org Fri Sep 20 15:12:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 15:12:42 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely In-Reply-To: <0J6K18Z-pmpzDUdCNkVl9hOlm-CQ5Vpe5zTwmIpjU8o=.c708e4fb-08c9-4d95-a908-693b9f9d82ad@github.com> References: <0J6K18Z-pmpzDUdCNkVl9hOlm-CQ5Vpe5zTwmIpjU8o=.c708e4fb-08c9-4d95-a908-693b9f9d82ad@github.com> Message-ID: On Thu, 19 Sep 2024 23:10:42 GMT, Andy Goryachev wrote: > I think it's better to wait until #1569 is integrated. Either should be fine, since there is no merge conflict, but I can wait to integrate this until after you integrate that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1575#issuecomment-2363956923 From kcr at openjdk.org Fri Sep 20 15:12:45 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 15:12:45 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v4] In-Reply-To: <47HMAEvg732rYOiAhtV7do9qwbQcC91TkhdjcNCyIOM=.ae429e36-b675-4164-bdc4-0dfaaf8eaedc@github.com> References: <47HMAEvg732rYOiAhtV7do9qwbQcC91TkhdjcNCyIOM=.ae429e36-b675-4164-bdc4-0dfaaf8eaedc@github.com> Message-ID: On Thu, 19 Sep 2024 22:37:00 GMT, Andy Goryachev wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > rotate test The changes you made look good. I still see some unexpected test failures in the (unstable) monocle tests suite. I ran the following command: gradle --continue --info -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true :systemTests:test --tests "test.robot.com.sun.glass.ui.monocle*" On master, I get: 1773 tests : 56 failures : 495 ignored With this PR, I get: 1326 tests : 422 failures: 12 ignored I note that we are actually running _more_ tests than before: `1773-495=1278` vs `1326-12=1314` As for the failures, since this is an unstable set of tests, the ones that timeout aren't a concern; which ones fail may vary slightly from run to run so a small difference is OK. In this case, the number of additional failures is much higher than I would expect: 56 vs 422. The ones that fail with an exception other than a timeout suggest a problem with the conversion of parameterized tests. See `InputDevicePropertyTest`, for one example. All 45 tests pass with master and all 45 fail with a "Toolkit not initialized" with this patch. ------------- PR Review: https://git.openjdk.org/jfx/pull/1569#pullrequestreview-2318522627 From kcr at openjdk.org Fri Sep 20 15:12:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 15:12:46 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 21:24:59 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 139: >> >>> 137: // Should throw IllegalStateException >>> 138: tmpScene.snapshot(p -> { >>> 139: throw new RuntimeException("Should never get here"); >> >> Suggestion: Use `fail`, rather than changing the Error into a RuntimeException. > > won't compile with `fail()`. any exception should be fine. In that case, `throw new AssertionError` seems the most equivalent change, in that it preserves the behavior of throwing an `Error` rather than a `RuntimeException` -- typically an Error is better for a case of "can't get here". I'll admit that it doesn't matter in this particular test, so it's just a suggestion. Feel free to ignore it. >> tests/system/src/test/java/test/javafx/scene/UIRenderSnapToPixelTest.java line 76: >> >>> 74: Assertions.assertEquals(0, ((sp.snappedBottomInset() * scale) + epsilon) % 1, 0.0001, "Bottom inset not snapped to pixel"); >>> 75: Assertions.assertEquals(0, ((sp.snappedLeftInset() * scale) + epsilon) % 1, 0.0001, "Left inset not snapped to pixel"); >>> 76: Assertions.assertEquals(0, ((sp.snappedRightInset() * scale) + epsilon) % 1, 0.0001, "Right inset not snapped to pixel"); >> >> Minor: these lines are geting a bit long. Maybe use static imports? > > still too long, but I do prefer having the class qualifier over static import (though static imports make more sense in the tests). > > I think tests is one area where we can relax the maximum line length rule (we already violate it in many places anyway) Yeah, don't worry about the line length, that was just an observation. > I do prefer having the class qualifier over static import (though static imports make more sense in the tests). So do I in most cases. For tests, I prefer static imports of the methods in `Assertions` and `Assumptions`, which is also the pattern recommended by the JUnit docs. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1768765939 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1768770602 From kcr at openjdk.org Fri Sep 20 15:37:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 15:37:41 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely In-Reply-To: References: <0J6K18Z-pmpzDUdCNkVl9hOlm-CQ5Vpe5zTwmIpjU8o=.c708e4fb-08c9-4d95-a908-693b9f9d82ad@github.com> Message-ID: On Fri, 20 Sep 2024 12:14:36 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/robot/javafx/scene/control/behavior/BehaviorRobotTestBase.java line 329: >> >>> 327: protected void sleep(int ms) { >>> 328: try { >>> 329: // KCR: this should be sleep(ms) not a hard-coded 1 >> >> good thing it's never called, but it is my fault. >> this method was later replaced with `waitForIdle` >> >> I can either delete the method or fix it as part of #1569 >> what do you think? > > If it isn't being used, then I like your idea of deleting it. Especially since this seems redundant given `Util.sleep(ms)`. I'll revert my changes and let you delete it as part of #1569. On closer inspection, I don't think this should be removed as part of PR #1569, since that file is already using JUnit 5 and is not touched by your PR. Either I can remove the method with this PR or we just leave it for a follow-up. Removing it with this PR seems easiest, since I am already modifying that method as part of this PR (along with other methods that catch and ignore InterruptedException from sleep). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1575#discussion_r1768826711 From kcr at openjdk.org Fri Sep 20 16:01:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 16:01:42 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 14:03:45 GMT, Kevin Rushforth wrote: > This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. > > The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. > > This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. > > I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. > > ### Testing instructions > > I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. Thanks for the reviews. I'll integrate it this afternoon (this is a product fix and it hasn't been "rfr" for 24 hours yet) if there are no other comments. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1574#issuecomment-2364047708 From kcr at openjdk.org Fri Sep 20 16:01:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 16:01:42 GMT Subject: RFR: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 13:10:11 GMT, Johan Vos wrote: > Regardless of this fix, it would still be good to have a fix for [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) (although that is likely less urgent now that the CI blocking is tackled) -- and there might be other issues that cause the dispose thread to not finish. Agreed on both points. While [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) is less urgent after this fix, it's still a bug. I instrumented the timer and dispose code as part of evaluating and then filing this shutdown hook bug, and I'll add some comments by way of a partial evaluation of that bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1574#issuecomment-2364048160 From kcr at openjdk.org Fri Sep 20 16:10:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 16:10:41 GMT Subject: RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 [v2] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 17:34:56 GMT, Hima Bindu Meda wrote: >> Updated additional webkit-619.1 fixes from webkitgtk-2.44.4. Build is successful on all platforms.No issues seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Looks good. Thanks for the explanation and for adding the missing copyright header. Since the only change from the previous, which @tiainen approved, is the addition of the copyright header comment block, a re-review by a single Reviewer will be sufficient. Approved. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1570#pullrequestreview-2318704426 From kcr at openjdk.org Fri Sep 20 16:10:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 16:10:42 GMT Subject: RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 [v2] In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 17:31:44 GMT, Hima Bindu Meda wrote: >> modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/HistoryItemClientJava.cpp line 1: >> >>> 1: #include "HistoryItemClientJava.h" >> >> Where did this file come from? I don't see any changes related to HistoryItemClient in the 2.44.4 release of WebKitGTK? >> >> Presuming we need this file, it will need a proper copyright header. > > This file has been added in order to adapt to the changes to the interface added as part of webkit commit def02cb5c4c24ed8a05e4e5075eb6ec95216ef80 in HistoryItem.h. > > Added the copyright header. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1570#discussion_r1768870444 From angorya at openjdk.org Fri Sep 20 16:34:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 16:34:39 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely In-Reply-To: References: <0J6K18Z-pmpzDUdCNkVl9hOlm-CQ5Vpe5zTwmIpjU8o=.c708e4fb-08c9-4d95-a908-693b9f9d82ad@github.com> Message-ID: On Fri, 20 Sep 2024 15:35:05 GMT, Kevin Rushforth wrote: >> If it isn't being used, then I like your idea of deleting it. Especially since this seems redundant given `Util.sleep(ms)`. I'll revert my changes and let you delete it as part of #1569. > > On closer inspection, I don't think this should be removed as part of PR #1569, since that file is already using JUnit 5 and is not touched by your PR. > > Either I can remove the method with this PR or we just leave it for a follow-up. Removing it with this PR seems easiest, since I am already modifying that method as part of this PR (along with other methods that catch and ignore InterruptedException from sleep). I agree with removing the method in this PR. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1575#discussion_r1768897041 From angorya at openjdk.org Fri Sep 20 16:43:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 16:43:41 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v4] In-Reply-To: References: <47HMAEvg732rYOiAhtV7do9qwbQcC91TkhdjcNCyIOM=.ae429e36-b675-4164-bdc4-0dfaaf8eaedc@github.com> Message-ID: On Fri, 20 Sep 2024 15:09:56 GMT, Kevin Rushforth wrote: > I still see some unexpected test failures in the (unstable) monocle tests suite. Speaking of that, I noticed that the number of failed tests varies between invocations on the same machine. For example with RotateTest on macOS running the command `gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test -PUNSTABLE_TEST=true --tests test.robot.com.sun.glass.ui.monocle.RotateTest` I get 5 failures, 10 failures, 6 failures, 7... Examples: RotateTest > testRotateLeftBigSteps(TestTouchDevice) > [8] NTrigDevice FAILED com.sun.glass.ui.monocle.TestLogShim$TestLogAssertion: Timed out after 3005ms waiting for 'TouchPoint: MOVED 285, 337' at app/javafx.graphics at 24-internal/com.sun.glass.ui.monocle.TestLogShim.waitForLog(TestLogShim.java:211) at app/javafx.graphics at 24-internal/com.sun.glass.ui.monocle.TestLogShim.waitForLogContaining(TestLogShim.java:237) at app/javafx.graphics at 24-internal/com.sun.glass.ui.monocle.TestLogShim.waitForLogContaining(TestLogShim.java:246) at app//test.robot.com.sun.glass.ui.monocle.RotateTest.Rotate(RotateTest.java:154) at app//test.robot.com.sun.glass.ui.monocle.RotateTest.Rotate(RotateTest.java:221) at app//test.robot.com.sun.glass.ui.monocle.RotateTest.testRotateLeftBigSteps(RotateTest.java:316) RotateTest > testRotateLeftFromMinus140Degrees(TestTouchDevice) > [8] NTrigDevice FAILED com.sun.glass.ui.monocle.TestLogShim$TestLogAssertion: Timed out after 3005ms waiting for 'TouchPoint: MOVED 640, 760' at app/javafx.graphics at 24-internal/com.sun.glass.ui.monocle.TestLogShim.waitForLog(TestLogShim.java:211) at app/javafx.graphics at 24-internal/com.sun.glass.ui.monocle.TestLogShim.waitForLogContaining(TestLogShim.java:237) at app/javafx.graphics at 24-internal/com.sun.glass.ui.monocle.TestLogShim.waitForLogContaining(TestLogShim.java:246) at app//test.robot.com.sun.glass.ui.monocle.RotateTest.Rotate(RotateTest.java:154) at app//test.robot.com.sun.glass.ui.monocle.RotateTest.Rotate(RotateTest.java:217) at app//test.robot.com.sun.glass.ui.monocle.RotateTest.testRotateLeftFromMinus140Degrees(RotateTest.java:407) 3 second timeout seems to be sufficient for the purpose, and I don't see any output captured by the TestLogShim. I haven't looked into the actual tests for long since it's out of scope, but maybe I am doing something wrong. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2364117398 From angorya at openjdk.org Fri Sep 20 17:13:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 17:13:40 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v4] In-Reply-To: <47HMAEvg732rYOiAhtV7do9qwbQcC91TkhdjcNCyIOM=.ae429e36-b675-4164-bdc4-0dfaaf8eaedc@github.com> References: <47HMAEvg732rYOiAhtV7do9qwbQcC91TkhdjcNCyIOM=.ae429e36-b675-4164-bdc4-0dfaaf8eaedc@github.com> Message-ID: On Thu, 19 Sep 2024 22:37:00 GMT, Andy Goryachev wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > rotate test Side note: TeshLogShim.log appears to be improperly synchronized in getLog(), countLog(), checkLog(), checkLogContaining(), but even when synchronization is fixed the tests still randomly fail... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2364164383 From kcr at openjdk.org Fri Sep 20 18:21:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 18:21:04 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v2] In-Reply-To: References: Message-ID: > This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). > > JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). > > While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. > > ### Testing instructions > > I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. > > The default timeout values for test and lifecycle methods can be modified using a gradle property: > > * `JUNIT_TEST_TIMEOUT` : default = 120s > * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s > > For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: > > > gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Remove unused sleep method from BehaviorRobotTestBase. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1575/files - new: https://git.openjdk.org/jfx/pull/1575/files/e16ef7ec..8a4078fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1575&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1575&range=00-01 Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1575.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1575/head:pull/1575 PR: https://git.openjdk.org/jfx/pull/1575 From kcr at openjdk.org Fri Sep 20 18:21:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 18:21:05 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v2] In-Reply-To: References: <0J6K18Z-pmpzDUdCNkVl9hOlm-CQ5Vpe5zTwmIpjU8o=.c708e4fb-08c9-4d95-a908-693b9f9d82ad@github.com> Message-ID: On Fri, 20 Sep 2024 16:31:58 GMT, Andy Goryachev wrote: >> On closer inspection, I don't think this should be removed as part of PR #1569, since that file is already using JUnit 5 and is not touched by your PR. >> >> Either I can remove the method with this PR or we just leave it for a follow-up. Removing it with this PR seems easiest, since I am already modifying that method as part of this PR (along with other methods that catch and ignore InterruptedException from sleep). > > I agree with removing the method in this PR. Thanks! Done. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1575#discussion_r1769017784 From angorya at openjdk.org Fri Sep 20 18:29:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 18:29:22 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) 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 24 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8339510.junit5.system - more fixes - rotate test - review comments - unused imports - fixes 4 - fixes 3 - fixes 2 - fixes 1 - part 12 last - ... and 14 more: https://git.openjdk.org/jfx/compare/17dd0938...777620ef ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1569/files - new: https://git.openjdk.org/jfx/pull/1569/files/7349f483..777620ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=03-04 Stats: 12729 lines in 163 files changed: 10911 ins; 580 del; 1238 mod Patch: https://git.openjdk.org/jfx/pull/1569.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1569/head:pull/1569 PR: https://git.openjdk.org/jfx/pull/1569 From angorya at openjdk.org Fri Sep 20 19:36:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 19:36:43 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v2] In-Reply-To: References: Message-ID: <3kLe2Xfrs-xeFHEMp75vhvT70EJfaYaPVfcIYNVN39o=.b83d4f19-fa69-4dd0-8a38-848bcc25dbce@github.com> On Fri, 20 Sep 2024 18:21:04 GMT, Kevin Rushforth wrote: >> This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). >> >> JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). >> >> While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. >> >> ### Testing instructions >> >> I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. >> >> The default timeout values for test and lifecycle methods can be modified using a gradle property: >> >> * `JUNIT_TEST_TIMEOUT` : default = 120s >> * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s >> >> For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: >> >> >> gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused sleep method from BehaviorRobotTestBase. looks good, thanks for removing the vestigial method. this PR will likely need more changes once #1569 gets integrated (I would recommend to integrate this one after, simply because the other has more files) ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1575#pullrequestreview-2319188800 From angorya at openjdk.org Fri Sep 20 20:11:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 20:11:43 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 02:36:34 GMT, Jay Bhaskar wrote: >> Successfully converted Non-parametrized base tests to JUnit 5 > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > one missing , formating looked at each line, double checking: - before->beforeEach etc. - exception types in assertThrows Could not run the junit4 query because there are still parameterized tests left. left a few comments, plus some tests need to be brought back. otherwise looks good. modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ContentBindingListTest.java line 203: > 201: assertFalse(golden.equals(ContentBinding.bind(op2, op3))); > 202: ContentBinding.unbind(op2, op3); > 203: } several lines seem to have indentation problem. could you check please? modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ErrorLoggingUtiltity.java line 28: > 26: package test.com.sun.javafx.binding; > 27: > 28: import static org.junit.jupiter.api.Assertions.*; Noticed the copyright year has not been updated in this file (and I am sure in others too). Should it be? modules/javafx.base/src/test/java/test/javafx/collections/VetoableObservableListTest.java line 151: > 149: ListIterator it = list.listIterator(); > 150: it.next(); > 151: assertThrows(NullPointerException.class, () -> it.set(null)); even though this is not an equivalent change, I think it actually makes the test better. good job! ------------- PR Review: https://git.openjdk.org/jfx/pull/1576#pullrequestreview-2319200535 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1769170527 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1769172840 PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1769191221 From johan.vos at gluonhq.com Fri Sep 20 20:27:08 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 20 Sep 2024 22:27:08 +0200 Subject: headless platform in sandbox Message-ID: Hi, Here is a quick update about the headless platform support, as developed in the jfx-sandbox repo [1]. While there is a Robot implementation in the headless platform (com.sun.glass.ui.headless), there are still many test failures because we don't read the pixels (yet). When running the systemtests, without the Robot tests, there are only 3 failures (592 tests, 44 ignored) on my Linux. These are: 1. ClipboardTest.testCopyUTF8String -> this relies on the AWT clipboard, which is linked with the system clipboard which depends on the windowing implementation (e.g. X). We don't want the headless platform to depend on this, so I think we should ignore this test when running headless. 2. MainLauncherTest.testMainLauncher[20] -> the logic is not 100% clear to me, but this is a test on headless which should fail (but it works for me) 3. SandboxAppTest.testFXNonApp -> this one and the testFXWebApp fail most of the time, but not always. I noticed that Thread.setContextClassLoader throws an AccessControlException when I run with the headless platform but not when I run with the GTK platform. Also, I noted there is an issue for this test on Windows [2] Feedback is of course very welcome. - Johan [1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless [2] https://bugs.openjdk.org/browse/JDK-8255486 -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Sep 20 20:27:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 20:27:45 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: <9bAzy4lHLe44jsTvkQHLnN2IonakEca7NYQI97jmQx4=.1afa965d-518f-4cda-9129-2b9894a43ba6@github.com> References: <9bAzy4lHLe44jsTvkQHLnN2IonakEca7NYQI97jmQx4=.1afa965d-518f-4cda-9129-2b9894a43ba6@github.com> Message-ID: On Thu, 19 Sep 2024 12:29:49 GMT, Lukasz Kostyra 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 18 additional commits since the last revision: >> >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 12, 9274 - 185 = 9089 >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 11, 9242 tests, 185 ignored >> - part 10 >> - part 9 cell >> - part 8 >> - ... and 8 more: https://git.openjdk.org/jfx/compare/c0cb2822...55b33b2c > > modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlTooltipTest.java line 48: > >> 46: import static org.junit.jupiter.api.Assertions.assertTimeout; >> 47: import static org.junit.jupiter.api.Assertions.assertNotEquals; >> 48: import org.junit.jupiter.api.Assumptions; > > Why not `import static org.junit.jupiter.api.Assumptions.assumeTrue`? We're directly importing `Assertions` this way anyway. a) I do prefer qualifiers, it makes it easier to see where things are coming from b) but in this case, and in this PR in general, there is a mixture of static imports and class imports - for convenience and speed. should be ok, it does not change the bytecode. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1769216032 From angorya at openjdk.org Fri Sep 20 20:31:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 20:31:42 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: <0M8iqZRAJEj36CGyStY-VyE-tcDCjN9XaYn20P36WNU=.a8dca587-cfa9-403a-a1fc-aff140e0c9f0@github.com> References: <9bAzy4lHLe44jsTvkQHLnN2IonakEca7NYQI97jmQx4=.1afa965d-518f-4cda-9129-2b9894a43ba6@github.com> <0M8iqZRAJEj36CGyStY-VyE-tcDCjN9XaYn20P36WNU=.a8dca587-cfa9-403a-a1fc-aff140e0c9f0@github.com> Message-ID: On Fri, 20 Sep 2024 13:42:28 GMT, Kevin Rushforth wrote: >> I'm not sure I understand. If removing old/commented out tests is out of scope of this PR then why is this one (and others) removed by this PR? > > I agree with @lukostyra -- we should not be removing any commented out tests. I thought that commented out tests have only historical value (or should be removed). If not, they should be disabled. If they are commented out, a comment must be added as to why. in this case, will apply the change to commented out test. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1769219677 From kcr at openjdk.org Fri Sep 20 20:35:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 20:35:41 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 18:29:22 GMT, Andy Goryachev wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > 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 24 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8339510.junit5.system > - more fixes > - rotate test > - review comments > - unused imports > - fixes 4 > - fixes 3 > - fixes 2 > - fixes 1 > - part 12 last > - ... and 14 more: https://git.openjdk.org/jfx/compare/42f2d9d3...777620ef The latest change look correct and fix most of the failures where the entire test class was failing. I still see a discrepancy between number of tests run before / after and there are more failures now. On master, I get: 1773 tests : 56 failures : 495 ignored With the latest version of this PR, I get: 1326 tests : 101 failures: 78 ignored So we are now running _fewer_ tests than before: `1773-495=1278` vs `1326-78=1248`. As for the failures, I ran it twice and got 102 failures the first time and 101 the second time. So there is likely some failure that isn't due to test instability. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2364576531 From angorya at openjdk.org Fri Sep 20 20:47:06 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 20:47:06 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: > Converting control module tests to junit5. > > The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ## JUnit5 Migration Notes > > Most of the changes are trivial, except for the following: > > 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) > 2. parameterized tests: junit5 allows for parameterizing individual tests > 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) > 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes > 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` > > ### Parameterized Class-Level Tests > > junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) > > The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. > > To summarize: > - remove `@Before` from the setup method > - call the setup method from each parameterized method (adding parameters and replacing `@Test` with > > @ParameterizedTest > @MethodSource("parameters") > > where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: > > private static Stream parameters() { > return Stream.of( > Arguments.of("a", 1), > Arguments.of("foo", 3) > ); > } > > > ### Migration Tricks > > Here are the steps that might speed up the process: > > 1. remove all the junit4 imports > 2. paste the following junit5 imports (below) > 3. fix the errors > 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) > 7. after all is done, verify that there is no more junit4 names by running the command mentioned below > > junit5 imports (in no particular order): > > import org.junit.jupiter.api.AfterEach; > import org.junit.jupiter.api.BeforeEach; > import org.junit.jupiter.api.Test; > import org.junit.jupiter.api.Disabled; > import org.junit.jupiter.params.ParameterizedTest; > imp... 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 20 additional commits since the last revision: - review comments - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - review comments - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - review comments - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - part 12, 9274 - 185 = 9089 - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls - part 11, 9242 tests, 185 ignored - part 10 - ... and 10 more: https://git.openjdk.org/jfx/compare/3aec3eb3...6c44cc6c ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1561/files - new: https://git.openjdk.org/jfx/pull/1561/files/55b33b2c..6c44cc6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1561&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1561&range=02-03 Stats: 12751 lines in 157 files changed: 10957 ins; 572 del; 1222 mod Patch: https://git.openjdk.org/jfx/pull/1561.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1561/head:pull/1561 PR: https://git.openjdk.org/jfx/pull/1561 From martin at martinfox.com Fri Sep 20 20:48:17 2024 From: martin at martinfox.com (Martin Fox) Date: Fri, 20 Sep 2024 13:48:17 -0700 Subject: How navigation currently works in FX, and an enhancement proposal In-Reply-To: References: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> <5be75966-ca82-4ea8-aa57-3e746bdabc55@gmail.com> Message-ID: John, I agree, the ScrollPane should not consume arrow keys when it doesn?t have focus. Under what conditions does the ScrollPane see these keys? With a TableView the focus either lies on the TableView itself or on one of the controls in the table. In the former case the ScrollPane won?t be in the dispatch chain and in the latter any of the standard controls will consume the arrow key to invoke traversal. It seems the ScrollPane responds to the arrow keys and the rest of the control set tries to make sure it never sees them. My biggest fear is that this would introduce a regression for accessibility clients. Restricting this behavior to occur only when the ScrollPane has focus is limiting because it?s so rare for a ScrollPane to have focus. I haven?t had time to figure out how other toolkits deal with this. A little Googling reveals that when Full Keyboard Access is turned on in macOS the scroll bars are added to the Tab traversal loop. That?s an interesting solution. Martin From angorya at openjdk.org Fri Sep 20 20:57:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 20:57:44 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: <31mhz53pceJmNjKOGf3Clv8ivrk_KEzjsI9HqmbpPuc=.416718b2-b847-4d7d-9376-e83f6b565567@github.com> On Fri, 20 Sep 2024 11:56:44 GMT, Lukasz Kostyra wrote: >> This is fine and I think Stream is what you will in most documentations as well, so good IMO. > > I'll leave it as-is then. that's fine. List is easier to manipulate, but this is very minor issue. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1769246843 From angorya at openjdk.org Fri Sep 20 21:03:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 21:03:41 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: <6M5FIYlERghICILn5xzCDCAw-lstKFkmzzJHZUupBNU=.7040dc7c-b682-4190-83f2-d1737b098b8f@github.com> On Fri, 20 Sep 2024 13:31:06 GMT, Lukasz Kostyra wrote: >> This PR converts all tests in `modules/javafx.graphics` to use JUnit5. >> >> ## Details >> >> Trivial changes resolved by first four commits: >> - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) >> - Message Strings in `assert*` calls moved to the end to follow 5's argument order >> - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations >> - Some test formatting unification - keeping annotations on a separate line from method definition >> - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. >> >> Non-trivial changes: >> - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: >> - `DirtyRegionTestBase` >> - `CssMethodsTestBase` >> - `ObjectMethodsTestBase` >> - `OnInvalidateMethodsTestBase` >> - `PropertiesTestBase` >> - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized >> - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` >> - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 >> >> At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. >> >> As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. >> >> ## Results >> >> Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: >> >> | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | >> | ------------ | ------ | ------ | >> | Test count | 23272 | 23275 | >> | Failures | 0 | 0 | >> | Ignored | 99 | 102 | >> | Successful % | 100% | 100% | >> >> The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion... > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review comments modules/javafx.graphics/src/test/java/test/javafx/scene/TreeShowingPropertyTest.java line 79: > 77: } > 78: > 79: public void setUp(Supplier nodeSupplier) { minor: this method should probably be `private` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1769253023 From kcr at openjdk.org Fri Sep 20 21:11:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 21:11:42 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 19:39:38 GMT, Andy Goryachev wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> one missing , formating > > modules/javafx.base/src/test/java/test/com/sun/javafx/binding/ErrorLoggingUtiltity.java line 28: > >> 26: package test.com.sun.javafx.binding; >> 27: >> 28: import static org.junit.jupiter.api.Assertions.*; > > Noticed the copyright year has not been updated in this file (and I am sure in others too). Should it be? No. Let the script do it. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1576#discussion_r1769258747 From kcr at openjdk.org Fri Sep 20 21:15:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 21:15:40 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 20:08:40 GMT, Andy Goryachev wrote: > Could not run the junit4 query because there are still parameterized tests left. What I did to verify this was to do a grep just on those files that changed: git diff --name-only master... | xargs grep -n -e "org.junit" -e "junit.framework" | grep -v jupiter So, while this doesn't verify that this PR picked up all classes without parameterized tests, it does confirm that there are no JUnit4 imports left in any of the ones that were converted. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1576#issuecomment-2364624830 From kcr at openjdk.org Fri Sep 20 21:21:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Sep 2024 21:21:42 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 02:36:34 GMT, Jay Bhaskar wrote: >> Successfully converted Non-parametrized base tests to JUnit 5 > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > one missing , formating I got curious, so I looked for all base test files with junit4 imports, and excluded the ones that have parameterized tests. I see that there are a few: modules/javafx.base/src/test/java/test/com/sun/javafx/property/adapter/JavaBeanPropertyBuilderHelperTest.java modules/javafx.base/src/test/java/test/javafx/beans/property/adapter/JavaBeanPropertyTestBase.java modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueSubscriptionsTest.java modules/javafx.base/src/test/java/test/javafx/binding/When_Boolean_Test.java modules/javafx.base/src/test/java/test/javafx/binding/When_Double_Test.java modules/javafx.base/src/test/java/test/javafx/binding/When_Float_Test.java modules/javafx.base/src/test/java/test/javafx/binding/When_Integer_Test.java modules/javafx.base/src/test/java/test/javafx/binding/When_Long_Test.java modules/javafx.base/src/test/java/test/javafx/binding/When_Object_Test.java modules/javafx.base/src/test/java/test/javafx/binding/When_String_Test.java modules/javafx.base/src/test/java/test/javafx/util/converter/CurrencyStringConverterTest.java modules/javafx.base/src/test/java/test/javafx/util/converter/NumberStringConverterTest.java So they can either be added to this PR (if there is nothing else that makes them tricky to convert) or lumped in with the parameterized tests and done in the follow-on bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1576#issuecomment-2364631292 From thiago.sayao at gmail.com Fri Sep 20 21:31:22 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 20 Sep 2024 18:31:22 -0300 Subject: How navigation currently works in FX, and an enhancement proposal In-Reply-To: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> References: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> Message-ID: Hi, I feel shy to add any thoughts on this. So don't mind if I don't make sense of it: I don't think all key bindings qualify as "navigation", but pressing ESCAPE on a text input control will eat the key even if there's no edit to cancel. So if you bind ESCAPE on the Scene as a shortcut (for closing the window for example) and you are on a text input control with no edit to cancel, it will eat the event. I think this logic should be applied: If the key event applies any change to the control, it should be consumed. If it does not change any control state, it should propagate. So on a ScrollPane, if the user presses UP to the top and there's nothing more to scroll, it should not consume the key event. Same for text input. If the user presses ESCAPE, and there's nothing to edit (no control state change), let it propagate. I hope it makes sense :) Em qui., 19 de set. de 2024 ?s 12:38, John Hendrikx escreveu: > I've been looking into how exactly navigation keys are being used in FX, > and who is responsible for handling them: > > - Controls can choose to install navigational keys directly in their > input map (using FocusTraversalInputMap::getFocusTraversalMappings) > - Controls can choose to do nothing and leave navigation keys to bubble > up to Scene, at which point Scene will act on any unconsumed navigation > keys (in the same was as the traversal mappings would) > > Scene basically is capable of almost all navigation you could possibly > want out of the box. Any control that does not install navigation keys, > and leaves said keys to bubble up gets navigation for **free**. This is > almost all controls in JavaFX, and it makes sense as Controls should not > care about navigation, they should only care about key presses that > affect them directly. Navigation should be a concern somewhere higher > up in the hierarchy. > > So why do some controls install their own navigation keys? > > There are two answers: > > 1. For some controls, navigation is conditional. A Spinner only allows > directional navigation for the left/right keys, or up/down keys > depending on its orientation. > 2. There is an unfortunate choice in ScrollPane that consumes > directional keys for scrolling purposes, and so if such keys were left > to bubble up, they would not end up at Scene. Any control supporting > directional navigation therefore must **specifically** install these > bindings directly, even though navigation is not their concern (a Button > cares about being pressed, not about activating unrelated controls nearby). > > The ScrollPane eating directional keys is an odd choice. In order for it > to do so one of the following must be true: > > - A control inside it has focus that should act on directional > navigation, but forgot to install navigation bindings (a custom > control). Such a control would work perfectly when not part of a > ScrollPane (as Scene would then handle directional navigation), but > break when placed inside it. Note that all JavaFX controls do this > "properly". I couldn't find any controls that would leave directional > keys to bubble up for a ScrollPane to consume. > > - The ScrollPane itself has focus; this can only happen when directly > selected with the mouse (or focus traversable is set to true) and no > specific control inside the pane was selected. The ScrollPane receives > the ":focused" style, clearly indicating that it is the target for > keyboard events to the user. > > In short, ScrollPane is making navigation a lot more complex within FX > than it needs to be. Especially custom controls that do not have access > (currently) to install navigational bindings will suffer from this, and > will have to resort to their own navigation implementation for > directional keys when placed inside a ScrollPane. > > # Proposal > > I think ScrollPane violates what I think should be a fundamental rule. > Keys should only be consumed by what the user perceives as the focused > control (ie. the one outlined with a highlighted border), with the only > exceptions being short cuts (from a menu) or mnemonics. Containers such > controls happen to be placed in should NOT consume key events -- the > container is not the control with the focus, and so would confuse the > user. Only ScrollPane is violating this currently. Note that if the > ScrollPane has focus itself (and it has the :focused highlight) then it > is perfectly fine and expected for it to consume keys as much as it wants. > > This is why I think we should modify ScrollPane to not consume the > directional keys, unless it specifically has the focus. All other > controls can then remove their navigational bindings and leave them to > bubble up to Scene, cleaning up their behaviors so they can focus on > other concerns. Custom controls would no longer need to install > navigational bindings either, and would not need to worry about being > placed inside a ScrollPane and having their directional navigation broken. > > Optional, but recommended, controls like Spinner should only act on the > directional keys intended for them, and leave the ones they can't use to > bubble up. So a vertical spinner would consume up/down for changing the > spinner value, but would leave left/right untouched for Scene to > handle. Controls that install a full set of navigational keys (like > Button, ListView and TitledPane) don't need to do so anymore. > > I think I will file a ticket for this soon, but I'm curious what others > think of this analysis. > > Note that by solving this problem, the need to make navigation > functionality available to custom controls severely diminishes as one > can simple leave the KeyEvents responsible for standard navigation to > bubble up (recommended as this may be different for each platform). > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Fri Sep 20 22:27:54 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 20 Sep 2024 22:27:54 +0000 Subject: How navigation currently works in FX, and an enhancement proposal In-Reply-To: References: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> Message-ID: Dear Thiago: You might be describing https://bugs.openjdk.org/browse/JDK-8320557 . You are absolutely right, the event should not be consumed if it effected no change in the control. I was planning to address it after the InputMap feature is in, but unfortunately, we ran into the same "better is the enemy of good" situation with that proposal too. Personally, I would prefer us to make gradual progress, even if the solution might seem to some less than perfect, but your voice and voice of everyone else counts, so please don't be shy in expressing your opinion. Cheers, -andy From: openjfx-dev on behalf of Thiago Milczarek Say?o Date: Friday, September 20, 2024 at 14:31 To: John Hendrikx Cc: openjfx-dev at openjdk.org Subject: Re: How navigation currently works in FX, and an enhancement proposal Hi, I feel shy to add any thoughts on this. So don't mind if I don't make sense of it: I don't think all key bindings qualify as "navigation", but pressing ESCAPE on a text input control will eat the key even if there's no edit to cancel. So if you bind ESCAPE on the Scene as a shortcut (for closing the window for example) and you are on a text input control with no edit to cancel, it will eat the event. I think this logic should be applied: If the key event applies any change to the control, it should be consumed. If it does not change any control state, it should propagate. So on a ScrollPane, if the user presses UP to the top and there's nothing more to scroll, it should not consume the key event. Same for text input. If the user presses ESCAPE, and there's nothing to edit (no control state change), let it propagate. I hope it makes sense :) Em qui., 19 de set. de 2024 ?s 12:38, John Hendrikx > escreveu: I've been looking into how exactly navigation keys are being used in FX, and who is responsible for handling them: - Controls can choose to install navigational keys directly in their input map (using FocusTraversalInputMap::getFocusTraversalMappings) - Controls can choose to do nothing and leave navigation keys to bubble up to Scene, at which point Scene will act on any unconsumed navigation keys (in the same was as the traversal mappings would) Scene basically is capable of almost all navigation you could possibly want out of the box. Any control that does not install navigation keys, and leaves said keys to bubble up gets navigation for **free**. This is almost all controls in JavaFX, and it makes sense as Controls should not care about navigation, they should only care about key presses that affect them directly. Navigation should be a concern somewhere higher up in the hierarchy. So why do some controls install their own navigation keys? There are two answers: 1. For some controls, navigation is conditional. A Spinner only allows directional navigation for the left/right keys, or up/down keys depending on its orientation. 2. There is an unfortunate choice in ScrollPane that consumes directional keys for scrolling purposes, and so if such keys were left to bubble up, they would not end up at Scene. Any control supporting directional navigation therefore must **specifically** install these bindings directly, even though navigation is not their concern (a Button cares about being pressed, not about activating unrelated controls nearby). The ScrollPane eating directional keys is an odd choice. In order for it to do so one of the following must be true: - A control inside it has focus that should act on directional navigation, but forgot to install navigation bindings (a custom control). Such a control would work perfectly when not part of a ScrollPane (as Scene would then handle directional navigation), but break when placed inside it. Note that all JavaFX controls do this "properly". I couldn't find any controls that would leave directional keys to bubble up for a ScrollPane to consume. - The ScrollPane itself has focus; this can only happen when directly selected with the mouse (or focus traversable is set to true) and no specific control inside the pane was selected. The ScrollPane receives the ":focused" style, clearly indicating that it is the target for keyboard events to the user. In short, ScrollPane is making navigation a lot more complex within FX than it needs to be. Especially custom controls that do not have access (currently) to install navigational bindings will suffer from this, and will have to resort to their own navigation implementation for directional keys when placed inside a ScrollPane. # Proposal I think ScrollPane violates what I think should be a fundamental rule. Keys should only be consumed by what the user perceives as the focused control (ie. the one outlined with a highlighted border), with the only exceptions being short cuts (from a menu) or mnemonics. Containers such controls happen to be placed in should NOT consume key events -- the container is not the control with the focus, and so would confuse the user. Only ScrollPane is violating this currently. Note that if the ScrollPane has focus itself (and it has the :focused highlight) then it is perfectly fine and expected for it to consume keys as much as it wants. This is why I think we should modify ScrollPane to not consume the directional keys, unless it specifically has the focus. All other controls can then remove their navigational bindings and leave them to bubble up to Scene, cleaning up their behaviors so they can focus on other concerns. Custom controls would no longer need to install navigational bindings either, and would not need to worry about being placed inside a ScrollPane and having their directional navigation broken. Optional, but recommended, controls like Spinner should only act on the directional keys intended for them, and leave the ones they can't use to bubble up. So a vertical spinner would consume up/down for changing the spinner value, but would leave left/right untouched for Scene to handle. Controls that install a full set of navigational keys (like Button, ListView and TitledPane) don't need to do so anymore. I think I will file a ticket for this soon, but I'm curious what others think of this analysis. Note that by solving this problem, the need to make navigation functionality available to custom controls severely diminishes as one can simple leave the KeyEvents responsible for standard navigation to bubble up (recommended as this may be different for each platform). --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Sep 20 23:56:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Sep 2024 23:56:45 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 18:29:22 GMT, Andy Goryachev wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > 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 24 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8339510.junit5.system > - more fixes > - rotate test > - review comments > - unused imports > - fixes 4 > - fixes 3 > - fixes 2 > - fixes 1 > - part 12 last > - ... and 14 more: https://git.openjdk.org/jfx/compare/9dbb00e7...777620ef so on macOS, running this command gradle --continue -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:cleanTest :systemTests:test -PUNSTABLE_TEST=true I got 2274 tests completed, 51 failed, 130 skipped I'll run the same command against master next week. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2364760947 From jbhaskar at openjdk.org Sat Sep 21 00:48:42 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sat, 21 Sep 2024 00:48:42 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 21:18:39 GMT, Kevin Rushforth wrote: > JavaBeanPropertyBuilderHelperTest I left those because these files have may assertThrows and having try catch , that required some extra care to convert, we will add then in parameterized test PR ------------- PR Comment: https://git.openjdk.org/jfx/pull/1576#issuecomment-2364787840 From jbhaskar at openjdk.org Sat Sep 21 00:54:05 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sat, 21 Sep 2024 00:54:05 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: > Successfully converted Non-parametrized base tests to JUnit 5 Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: restore and convert mistakenly removed tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1576/files - new: https://git.openjdk.org/jfx/pull/1576/files/0d221c8e..6a4db794 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1576&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1576&range=03-04 Stats: 23 lines in 2 files changed: 21 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1576.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1576/head:pull/1576 PR: https://git.openjdk.org/jfx/pull/1576 From michaelstrau2 at gmail.com Sat Sep 21 02:17:37 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Sat, 21 Sep 2024 04:17:37 +0200 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: > I'm not yet convinced that new vertex formats are the way to go. To be fair, I'm not sure why VertexFormat even exists. It serves no purpose when creating a TriangleMesh, as the vertex format could easily be inferred by the presence (or absence) of vertex data. Having users specify the VertexFormat explicitly is probably not a good API, as it now makes the other data components be dependent on the choice of the vertex format. Of course, not all combinations of vertex data are valid, but this could be specified in documentation and be validated by the implementation. I think it might be best to deprecate VertexFormat for removal. This would also prevent a potential explosion of vertex formats in the public API. I have no objection to the choice to add vertex colors as an additional data component to TriangleMesh. It adds to the API, but this is not a slippery slope as there's only a very finite set of features we might be tempted to add next: The most obvious thing that JavaFX 3D really can't do is shadows. These come in static form (light mapping) and dynamic form (shadow mapping). Light mapping requires a second set of texcoords, while shadow mapping does not. Adding light mapping would make JavaFX 3D competitive with late-90's graphics, and adding shadow mapping would make it competitive with early-2000's graphics. From john.hendrikx at gmail.com Sat Sep 21 07:14:24 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sat, 21 Sep 2024 09:14:24 +0200 Subject: How navigation currently works in FX, and an enhancement proposal In-Reply-To: References: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> Message-ID: <5a51a670-2333-4864-8d64-017a83c8410d@gmail.com> On 20/09/2024 23:31, Thiago Milczarek Say?o wrote: > Hi, > > I feel shy to add any thoughts on this. So don't mind if I don't make > sense of it: > > I don't think all key bindings qualify as "navigation", but pressing > ESCAPE on a text input control will eat the key even if there's no > edit to cancel. Yeah, there are more keys with problems in this regard.? Navigation keys are also often dual purposes -- ie. cursor keys are used by Text controls for moving the cursor, which has nothing to do with focus traversal -- similarly, ScrollPane uses them to pan the view, which also has nothing to do with focus traversal. > > So if you bind ESCAPE on the Scene as a shortcut (for closing the > window for example) and you are on a text input control with no edit > to cancel, it will eat the event. > > I think this logic should be applied: > > If the key event applies any change to the control, it should be > consumed. If it does not change any control state, it should propagate. That's exactly right, and that's what annoys me as well. KeyEvents only should be consumed when they're used.? The problem stems from the "auto consume" feature in InputMap.? Too many controls have this set to true, while their logic is conditional. > > So on a ScrollPane, if the user presses UP to the top and there's > nothing more to scroll, it should not consume the key event. > Same for text input. If the user presses ESCAPE, and there's nothing > to edit (no control state change), let it propagate. Yes, it should do this too, but it should also only consume keys targetted at it (ie. it has the ":focused" style so users know where keys are going), not keys that bubble up to it IMHO. I haven't found any real life non-FX controls that consume keys as scroll events when the scrollpane/bar wasn't specifically focused.? It would be very annoying I think if they did. --John > > I hope it makes sense :) > > > > Em qui., 19 de set. de 2024 ?s 12:38, John Hendrikx > escreveu: > > I've been looking into how exactly navigation keys are being used > in FX, > and who is responsible for handling them: > > - Controls can choose to install navigational keys directly in their > input map (using FocusTraversalInputMap::getFocusTraversalMappings) > - Controls can choose to do nothing and leave navigation keys to > bubble > up to Scene, at which point Scene will act on any unconsumed > navigation > keys (in the same was as the traversal mappings would) > > Scene basically is capable of almost all navigation you could > possibly > want out of the box.? Any control that does not install navigation > keys, > and leaves said keys to bubble up gets navigation for **free**.? > This is > almost all controls in JavaFX, and it makes sense as Controls > should not > care about navigation, they should only care about key presses that > affect them directly.? Navigation should be a concern somewhere > higher > up in the hierarchy. > > So why do some controls install their own navigation keys? > > There are two answers: > > 1. For some controls, navigation is conditional. A Spinner only > allows > directional navigation for the left/right keys, or up/down keys > depending on its orientation. > 2. There is an unfortunate choice in ScrollPane that consumes > directional keys for scrolling purposes, and so if such keys were > left > to bubble up, they would not end up at Scene.? Any control supporting > directional navigation therefore must **specifically** install these > bindings directly, even though navigation is not their concern (a > Button > cares about being pressed, not about activating unrelated controls > nearby). > > The ScrollPane eating directional keys is an odd choice. In order > for it > to do so one of the following must be true: > > - A control inside it has focus that should act on directional > navigation, but forgot to install navigation bindings (a custom > control).? Such a control would work perfectly when not part of a > ScrollPane (as Scene would then handle directional navigation), but > break when placed inside it.? Note that all JavaFX controls do this > "properly".? I couldn't find any?controls that would leave > directional > keys to bubble up for a ScrollPane to consume. > > - The ScrollPane itself has focus; this can only happen when directly > selected with the mouse (or focus traversable is set to true) and no > specific control inside the pane was selected.? The ScrollPane > receives > the ":focused" style, clearly indicating that it is the target for > keyboard events to the user. > > In short, ScrollPane is making navigation?a lot more complex > within FX > than it needs to be.? Especially custom controls that do not have > access > (currently) to install navigational bindings will suffer from > this, and > will have to resort to their own navigation implementation for > directional keys when placed inside a ScrollPane. > > # Proposal > > I think ScrollPane violates what I think should be a fundamental > rule. > Keys should only be consumed by what the user perceives as the > focused > control (ie. the one outlined with a highlighted border), with the > only > exceptions being short cuts (from a menu) or mnemonics. Containers > such > controls happen to be placed in should NOT consume key events -- the > container is not the control with the focus, and so would confuse the > user.??Only ScrollPane is violating this currently.? Note that if the > ScrollPane has focus itself (and it has the :focused highlight) > then it > is perfectly fine and expected for it to consume keys as much as > it wants. > > This is why I think we should modify ScrollPane to not consume the > directional keys, unless it specifically has the focus.? All other > controls can then remove their navigational bindings and leave > them to > bubble up to Scene, cleaning up their behaviors so they can focus on > other?concerns.? Custom controls would no longer need to install > navigational bindings either, and would not need to worry about being > placed inside a ScrollPane and having their directional navigation > broken. > > Optional, but recommended, controls like Spinner should only act > on the > directional keys intended for them, and leave the ones they can't > use to > bubble up.? So a vertical spinner would consume up/down for > changing the > spinner value, but would leave left/right untouched for Scene to > handle.? Controls that install a full set of navigational keys (like > Button, ListView and TitledPane) don't need to do so anymore. > > I think I will file a ticket for this soon, but I'm curious what > others > think of this analysis. > > Note that by solving this problem, the need to make navigation > functionality available to custom controls severely diminishes as one > can simple leave the KeyEvents responsible for standard navigation to > bubble up (recommended as this may be different for each platform). > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Sat Sep 21 14:36:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 21 Sep 2024 14:36:43 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 18:29:22 GMT, Andy Goryachev wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > 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 24 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8339510.junit5.system > - more fixes > - rotate test > - review comments > - unused imports > - fixes 4 > - fixes 3 > - fixes 2 > - fixes 1 > - part 12 last > - ... and 14 more: https://git.openjdk.org/jfx/compare/9a448034...777620ef Not sure why I'm seeing something different then. I tried running it on a second macOS system today (macOS 13.x Intel) and got similar results to my earlier runs. I ran the following command to just run the monocle tests: gradle --continue --info -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true :systemTests:test --tests "test.robot.com.sun.glass.ui.monocle*" #### master 1773 tests : 56 failures : 495 ignored -- tests run: 1773-495=1278 #### this PR 1326 tests : 106 failures: 78 ignored -- tests run: 1326-78=1248 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2365209955 From kcr at openjdk.org Sat Sep 21 14:55:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 21 Sep 2024 14:55:42 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: On Sat, 21 Sep 2024 00:54:05 GMT, Jay Bhaskar wrote: >> Successfully converted Non-parametrized base tests to JUnit 5 > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > restore and convert mistakenly removed tests Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1576#pullrequestreview-2319813951 From kcr at openjdk.org Sat Sep 21 14:55:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 21 Sep 2024 14:55:43 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 20:08:40 GMT, Andy Goryachev wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> one missing , formating > > looked at each line, double checking: > - before->beforeEach etc. > - exception types in assertThrows > > Could not run the junit4 query because there are still parameterized tests left. > > left a few comments, plus some tests need to be brought back. > otherwise looks good. Looks good now. Please wait to see if @andy-goryachev-oracle has any more comments. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1576#issuecomment-2365215090 From martin at martinfox.com Sat Sep 21 17:08:53 2024 From: martin at martinfox.com (Martin Fox) Date: Sat, 21 Sep 2024 10:08:53 -0700 Subject: How navigation currently works in FX, and an enhancement proposal In-Reply-To: <5a51a670-2333-4864-8d64-017a83c8410d@gmail.com> References: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> <5a51a670-2333-4864-8d64-017a83c8410d@gmail.com> Message-ID: <9C0C6B40-FEFA-4CA5-991C-9B78372B3765@martinfox.com> JavaFX doesn?t have many ways of prioritizing key event handling. On Windows and Mac there are mechanisms in place specifically to ensure ESC gets channeled to a dialog?s default cancel button. These mechanisms also prioritize menu accelerators before other uses. In JavaFX key events have to bubble up to the Scene unconsumed for accelerators to work which means they?re effectively prioritized last. The fix for https://bugs.openjdk.org/browse/JDK-8320557 is trivial but writing up a unit test is not. I?ll go see if there?s any existing tests I can extend. > On Sep 21, 2024, at 12:14?AM, John Hendrikx wrote: > > > > On 20/09/2024 23:31, Thiago Milczarek Say?o wrote: >> Hi, >> >> I feel shy to add any thoughts on this. So don't mind if I don't make sense of it: >> >> I don't think all key bindings qualify as "navigation", but pressing ESCAPE on a text input control will eat the key even if there's no edit to cancel. > Yeah, there are more keys with problems in this regard. Navigation keys are also often dual purposes -- ie. cursor keys are used by Text controls for moving the cursor, which has nothing to do with focus traversal -- similarly, ScrollPane uses them to pan the view, which also has nothing to do with focus traversal. >> >> So if you bind ESCAPE on the Scene as a shortcut (for closing the window for example) and you are on a text input control with no edit to cancel, it will eat the event. >> >> I think this logic should be applied: >> >> If the key event applies any change to the control, it should be consumed. If it does not change any control state, it should propagate. > That's exactly right, and that's what annoys me as well. KeyEvents only should be consumed when they're used. The problem stems from the "auto consume" feature in InputMap. Too many controls have this set to true, while their logic is conditional. > >> >> So on a ScrollPane, if the user presses UP to the top and there's nothing more to scroll, it should not consume the key event. >> Same for text input. If the user presses ESCAPE, and there's nothing to edit (no control state change), let it propagate. > Yes, it should do this too, but it should also only consume keys targetted at it (ie. it has the ":focused" style so users know where keys are going), not keys that bubble up to it IMHO. > > I haven't found any real life non-FX controls that consume keys as scroll events when the scrollpane/bar wasn't specifically focused. It would be very annoying I think if they did. > > --John > > > >> >> I hope it makes sense :) >> >> >> >> Em qui., 19 de set. de 2024 ?s 12:38, John Hendrikx > escreveu: >>> I've been looking into how exactly navigation keys are being used in FX, >>> and who is responsible for handling them: >>> >>> - Controls can choose to install navigational keys directly in their >>> input map (using FocusTraversalInputMap::getFocusTraversalMappings) >>> - Controls can choose to do nothing and leave navigation keys to bubble >>> up to Scene, at which point Scene will act on any unconsumed navigation >>> keys (in the same was as the traversal mappings would) >>> >>> Scene basically is capable of almost all navigation you could possibly >>> want out of the box. Any control that does not install navigation keys, >>> and leaves said keys to bubble up gets navigation for **free**. This is >>> almost all controls in JavaFX, and it makes sense as Controls should not >>> care about navigation, they should only care about key presses that >>> affect them directly. Navigation should be a concern somewhere higher >>> up in the hierarchy. >>> >>> So why do some controls install their own navigation keys? >>> >>> There are two answers: >>> >>> 1. For some controls, navigation is conditional. A Spinner only allows >>> directional navigation for the left/right keys, or up/down keys >>> depending on its orientation. >>> 2. There is an unfortunate choice in ScrollPane that consumes >>> directional keys for scrolling purposes, and so if such keys were left >>> to bubble up, they would not end up at Scene. Any control supporting >>> directional navigation therefore must **specifically** install these >>> bindings directly, even though navigation is not their concern (a Button >>> cares about being pressed, not about activating unrelated controls nearby). >>> >>> The ScrollPane eating directional keys is an odd choice. In order for it >>> to do so one of the following must be true: >>> >>> - A control inside it has focus that should act on directional >>> navigation, but forgot to install navigation bindings (a custom >>> control). Such a control would work perfectly when not part of a >>> ScrollPane (as Scene would then handle directional navigation), but >>> break when placed inside it. Note that all JavaFX controls do this >>> "properly". I couldn't find any controls that would leave directional >>> keys to bubble up for a ScrollPane to consume. >>> >>> - The ScrollPane itself has focus; this can only happen when directly >>> selected with the mouse (or focus traversable is set to true) and no >>> specific control inside the pane was selected. The ScrollPane receives >>> the ":focused" style, clearly indicating that it is the target for >>> keyboard events to the user. >>> >>> In short, ScrollPane is making navigation a lot more complex within FX >>> than it needs to be. Especially custom controls that do not have access >>> (currently) to install navigational bindings will suffer from this, and >>> will have to resort to their own navigation implementation for >>> directional keys when placed inside a ScrollPane. >>> >>> # Proposal >>> >>> I think ScrollPane violates what I think should be a fundamental rule. >>> Keys should only be consumed by what the user perceives as the focused >>> control (ie. the one outlined with a highlighted border), with the only >>> exceptions being short cuts (from a menu) or mnemonics. Containers such >>> controls happen to be placed in should NOT consume key events -- the >>> container is not the control with the focus, and so would confuse the >>> user. Only ScrollPane is violating this currently. Note that if the >>> ScrollPane has focus itself (and it has the :focused highlight) then it >>> is perfectly fine and expected for it to consume keys as much as it wants. >>> >>> This is why I think we should modify ScrollPane to not consume the >>> directional keys, unless it specifically has the focus. All other >>> controls can then remove their navigational bindings and leave them to >>> bubble up to Scene, cleaning up their behaviors so they can focus on >>> other concerns. Custom controls would no longer need to install >>> navigational bindings either, and would not need to worry about being >>> placed inside a ScrollPane and having their directional navigation broken. >>> >>> Optional, but recommended, controls like Spinner should only act on the >>> directional keys intended for them, and leave the ones they can't use to >>> bubble up. So a vertical spinner would consume up/down for changing the >>> spinner value, but would leave left/right untouched for Scene to >>> handle. Controls that install a full set of navigational keys (like >>> Button, ListView and TitledPane) don't need to do so anymore. >>> >>> I think I will file a ticket for this soon, but I'm curious what others >>> think of this analysis. >>> >>> Note that by solving this problem, the need to make navigation >>> functionality available to custom controls severely diminishes as one >>> can simple leave the KeyEvents responsible for standard navigation to >>> bubble up (recommended as this may be different for each platform). >>> >>> --John >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Sun Sep 22 13:10:48 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 22 Sep 2024 13:10:48 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 20:47:06 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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 20 additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - ... and 10 more: https://git.openjdk.org/jfx/compare/0deb1314...6c44cc6c Marked as reviewed by mhanl (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1561#pullrequestreview-2320851631 From mhanl at openjdk.org Sun Sep 22 13:10:50 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 22 Sep 2024 13:10:50 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: <-W1LzhNhPOdL_5QTxzTAGnAHR3L4M8CWAI4-DqMUp8E=.c319abb8-3581-4751-a132-f2ba8062f270@github.com> On Wed, 18 Sep 2024 15:36:53 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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 18 additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - part 9 cell > - part 8 > - ... and 8 more: https://git.openjdk.org/jfx/compare/3b6f1b51...55b33b2c modules/javafx.controls/src/test/java/test/javafx/scene/chart/NumberAxisTest.java line 260: > 258: > 259: @Test > 260: @Timeout(value=1000, unit=TimeUnit.MILLISECONDS) minor: I think the convention is to have spaces around the parameters, e.g. `@Timeout(value = 1000, unit = TimeUnit.MILLISECONDS)` Just scanned the JavaFX code and we seem to be inconsiostent on that, so I will leave that up to do. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1770550966 From mhanl at openjdk.org Sun Sep 22 14:12:45 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sun, 22 Sep 2024 14:12:45 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 13:31:06 GMT, Lukasz Kostyra wrote: >> This PR converts all tests in `modules/javafx.graphics` to use JUnit5. >> >> ## Details >> >> Trivial changes resolved by first four commits: >> - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) >> - Message Strings in `assert*` calls moved to the end to follow 5's argument order >> - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations >> - Some test formatting unification - keeping annotations on a separate line from method definition >> - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. >> >> Non-trivial changes: >> - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: >> - `DirtyRegionTestBase` >> - `CssMethodsTestBase` >> - `ObjectMethodsTestBase` >> - `OnInvalidateMethodsTestBase` >> - `PropertiesTestBase` >> - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized >> - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` >> - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 >> >> At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. >> >> As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. >> >> ## Results >> >> Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: >> >> | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | >> | ------------ | ------ | ------ | >> | Test count | 23272 | 23275 | >> | Failures | 0 | 0 | >> | Ignored | 99 | 102 | >> | Successful % | 100% | 100% | >> >> The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion... > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Found some things that may should be improved, but looks good otherwise! modules/javafx.graphics/src/test/java/test/javafx/scene/Node_bind_Test.java line 57: > 55: @Test > 56: public void testIllegalClip() { > 57: Thread.currentThread().setUncaughtExceptionHandler((thread, throwable) -> { I think this needs to be reset in an `@AfterEach`, see for example the `TableCellTest`. modules/javafx.graphics/src/test/java/test/javafx/scene/effect/EffectInputTest.java line 215: > 213: > 214: assertEquals(2, countIllegalArgumentException, "Cycle in effect chain detected, exception should occur 2 times."); > 215: Thread.currentThread().setUncaughtExceptionHandler(null); This should be done in an `@AfterEach`, because this code do not run when an exception is thrown before. modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundTest.java line 789: > 787: > 788: @Test > 789: public void testSingleFill() { Indentation looks off? modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundTest.java line 796: > 794: > 795: @Test > 796: public void testSingleFillWithNullPaint() { Indentation looks off? modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderPaneTest.java line 949: > 947: > 948: @Test > 949: public void testResizeBelowMinimum() { Indentation looks off? modules/javafx.graphics/src/test/java/test/javafx/scene/transform/TransformOperationsTest.java line 577: > 575: boolean isIdentity, > 576: boolean isInvertible, > 577: Class inverseType) { Minor: Can use `Class` ------------- PR Review: https://git.openjdk.org/jfx/pull/1566#pullrequestreview-2320858125 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1770558488 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1770559868 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1770562151 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1770562169 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1770562200 PR Review Comment: https://git.openjdk.org/jfx/pull/1566#discussion_r1770560911 From hmeda at openjdk.org Mon Sep 23 08:40:45 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 23 Sep 2024 08:40:45 GMT Subject: Integrated: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 18:45:45 GMT, Hima Bindu Meda wrote: > Updated additional webkit-619.1 fixes from webkitgtk-2.44.4. Build is successful on all platforms.No issues seen This pull request has now been integrated. Changeset: bc5adfa9 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/bc5adfa9b6f9180eb32930f61e59fdc46a83cb73 Stats: 596 lines in 103 files changed: 376 ins; 116 del; 104 mod 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1570 From lkostyra at openjdk.org Mon Sep 23 09:04:48 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 23 Sep 2024 09:04:48 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: <8aAowqb1YD4A1p1U3fnle1oiy7Fw-XJQWrbfKbwTBQU=.66d5ba34-ef40-4dfc-a920-b56cec70b04d@github.com> On Fri, 20 Sep 2024 20:47:06 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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 20 additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - ... and 10 more: https://git.openjdk.org/jfx/compare/a5da09ae...6c44cc6c LGTM ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1561#pullrequestreview-2321547818 From lkostyra at openjdk.org Mon Sep 23 09:14:02 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 23 Sep 2024 09:14:02 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Review comments v2 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1566/files - new: https://git.openjdk.org/jfx/pull/1566/files/adbdf9f1..1e335316 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1566&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1566&range=01-02 Stats: 104 lines in 6 files changed: 12 ins; 0 del; 92 mod Patch: https://git.openjdk.org/jfx/pull/1566.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1566/head:pull/1566 PR: https://git.openjdk.org/jfx/pull/1566 From kcr at openjdk.org Mon Sep 23 12:49:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 23 Sep 2024 12:49:43 GMT Subject: Integrated: 8340405: JavaFX shutdown hook can hang preventing app from exiting In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 14:03:45 GMT, Kevin Rushforth wrote: > This PR fixes a hang on exit which can happen if QuantumToolkit.dispose hangs when called from the QuantumToolkit shutdown hook. A shutdown hook should never run indefinitely, so the fix is to call dispose from a background thread and wait for up to 5 seconds for it to finish normally, and then throw an Error so that the application will be able to exit anyway. > > The QuantumToolkit registers a "Glass/Prism Shutdown Hook" that calls the QuantumToolkit.dispose method to gracefully shutdown the toolkit and renderer. If dispose hangs or deadlocks, this will prevent the application from exiting, requiring the process to be killed. This has been observed on macOS, due to [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505), which is is an intermittent deadlock that occurs during shutdown. We ought to eventually fix that intermittent deadlock, but even in the presence of a deadlock or hang, we don't want the shutdown hook to hang. > > This can happen at any time, but is especially a problem during an automated test run, which will then hang until the Jenkins job is either killed or its global timer (currently set to 12 hours) kills the job. Even in that case, processes can be left lying around which can affect subsequent runs. > > I discovered this while testing [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629), which adds a default Unit 5 timeout, and without fixing the deadlock, the timeout will be unable to abort the hanging test. > > ### Testing instructions > > I tested this in connection with PR #1575 / [JDK-8328629](https://bugs.openjdk.org/browse/JDK-8328629) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1575 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. This pull request has now been integrated. Changeset: addf0854 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/addf0854dcd95fb8b78ad0dce4413c1170fd70eb Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod 8340405: JavaFX shutdown hook can hang preventing app from exiting Reviewed-by: arapte, jvos, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1574 From lkostyra at openjdk.org Mon Sep 23 14:09:49 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 23 Sep 2024 14:09:49 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 18:29:22 GMT, Andy Goryachev wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > 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 24 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into 8339510.junit5.system > - more fixes > - rotate test > - review comments > - unused imports > - fixes 4 > - fixes 3 > - fixes 2 > - fixes 1 > - part 12 last > - ... and 14 more: https://git.openjdk.org/jfx/compare/1575b127...777620ef tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 265: > 263: // Should not get here > 264: latch.countDown(); > 265: throw new AssertionError("Should never get here"); Should probably be `fail` tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 387: > 385: // Should not get here > 386: latch.countDown(); > 387: throw new AssertionError("Should never get here"); Should probably be `fail` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1771412786 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1771413058 From arapte at openjdk.org Mon Sep 23 15:52:14 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 23 Sep 2024 15:52:14 GMT Subject: RFR: 8297072: Provide gradle option to test a previously built SDK Message-ID: #### Requirement: We want to be able to test a JavaFX SDK built somewhere else other than on current machine or current repo on same machine. Which means we should be able to run the unit and system tests with a different JavaFX SDK. #### Change: ##### Run tests using a specified JavaFX SDK: - Introduce a property `TEST_JAVAFX_SDK_PATH` that points to the JavaFX SDK which was built elsewhere. - Modify the paths generated by build.gradle to point to the path sepcified by `TEST_JAVAFX_SDK_PATH` - When a `TEST_JAVAFX_SDK_PATH` is specified `-PTEST_ONLY=true` must also be specified. ##### Generate the JavaFX SDK bundle - Generate the minimal JavaFX SDK bundle that is required to run the tests: We require content of the _build/sdk_ and _build/shims_ directories to achieve the same. #### Verification: ##### With a single machine: 1. Create two local copies JavaFX repo, [repo1, repo2] 2. Build sdk and shims in repo1. `gradle sdk shims` 3. In repo2, run different tests as, > gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**repo1/build** :base:test 4. In repo1 run `gradle all` 5. `javafx-sdk-shims.zip` file would be created under repo1/build. unzip it any `unzip-path` on machine 6. In repo2, run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH > gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test ##### With 2 machines. 1. Run `gradle all` on a machine1 2. Move build/javafx-sdk-shims.zip to machine2 and unzip to any `unzip-path` 3. Run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH > gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test #### Additional changes: Additionally we observed that three unit tests failed because they access a specific path. A path that would no exists when JavaFX SDK is not built. 1. Controls test: test.javafx.scene.control.ControlTest.testRT18097 It required path: modules/javafx.controls/build/classes/java/main/javafx.controls/javafx It is fixed by change on line 2811 2. Graphics test: test.javafx.css.CssMetaDataTest.testRT18097 It required path: modules/javafx.graphics/build/classes/java/main/javafx.graphics/javafx It is fixed by change on line 2722 3. Base test: test.com.sun.javafx.runtime.VersionInfoTest It required path: build/module-lib/javafx.properties VersionInfoTest is specific to the local build of JavaFX. So, It can be safely excluded when TEST_JAVAFX_SDK_PATH is specified. It is fixed by change on line 2304 to 2310 ------------- Commit messages: - TEST_JAVAFX_SDK_PATH and create sdk-shims-bundle Changes: https://git.openjdk.org/jfx/pull/1577/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1577&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297072 Stats: 61 lines in 1 file changed: 53 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1577.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1577/head:pull/1577 PR: https://git.openjdk.org/jfx/pull/1577 From nlisker at gmail.com Mon Sep 23 16:22:35 2024 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 23 Sep 2024 19:22:35 +0300 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: Having gone through some sources, I found the additional properties that can be added as per-vertex data: * Additional texture coordinates (mentioned by Michael). These can be used for detailed textures. * Bone indices and weights. These are for GPU skinning. Interestingly, the D3D vertex shader constants file has some preparation for skinning and bones [1]. * Tangents. Used similarly to normals in some lighting-related calculations. While it's not clear that we'll need these, the proliferation of vertex formats will be unmanageable with even one of these added (in addition to color). Looking at the use of VertexFormat in TriangleMesh with regards to normals: private boolean validateNormals() { // Only validate normals if vertex format has normal component if (getVertexFormat() != VertexFormat.POINT_NORMAL_TEXCOORD) return true; if (normals.size() == 0) { // Valid but meaningless for picking or rendering. return false; ... } I'm confused by this. If the normals should be validated only when the vertex format defines that normals are used, why does the method return true when normals aren't used? I would think, along with what Michael said, that either if the vertex format doesn't declare normals, or the user doesn't declare normal (size ==0), then the normals wouldn't be validated. That would also mean that the vertex format is redundant since it's implied by the existence/length of the array. Perhaps it's worth looking at the color implementation this way. Additional vertex formats should not be added, and the use of vertex colors should be dictated by looking at the array. [1] https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h On Sat, Sep 21, 2024 at 5:17?AM Michael Strau? wrote: > > I'm not yet convinced that new vertex formats are the way to go. > > To be fair, I'm not sure why VertexFormat even exists. It serves no > purpose when creating a TriangleMesh, as the vertex format could > easily be inferred by the presence (or absence) of vertex data. Having > users specify the VertexFormat explicitly is probably not a good API, > as it now makes the other data components be dependent on the choice > of the vertex format. > > Of course, not all combinations of vertex data are valid, but this > could be specified in documentation and be validated by the > implementation. I think it might be best to deprecate VertexFormat for > removal. This would also prevent a potential explosion of vertex > formats in the public API. > > I have no objection to the choice to add vertex colors as an > additional data component to TriangleMesh. It adds to the API, but > this is not a slippery slope as there's only a very finite set of > features we might be tempted to add next: > > The most obvious thing that JavaFX 3D really can't do is shadows. > These come in static form (light mapping) and dynamic form (shadow > mapping). Light mapping requires a second set of texcoords, while > shadow mapping does not. > > Adding light mapping would make JavaFX 3D competitive with late-90's > graphics, and adding shadow mapping would make it competitive with > early-2000's graphics. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Sep 23 18:02:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 18:02:49 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 20:47:06 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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 20 additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - ... and 10 more: https://git.openjdk.org/jfx/compare/2d04f3f1...6c44cc6c Thank you all for the time and effort reviewing it! This PR still needs one "R"eviewer though. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2368993407 From angorya at openjdk.org Mon Sep 23 18:02:51 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 18:02:51 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: <-W1LzhNhPOdL_5QTxzTAGnAHR3L4M8CWAI4-DqMUp8E=.c319abb8-3581-4751-a132-f2ba8062f270@github.com> References: <-W1LzhNhPOdL_5QTxzTAGnAHR3L4M8CWAI4-DqMUp8E=.c319abb8-3581-4751-a132-f2ba8062f270@github.com> Message-ID: On Sun, 22 Sep 2024 13:07:57 GMT, Marius Hanl 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 18 additional commits since the last revision: >> >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 12, 9274 - 185 = 9089 >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 11, 9242 tests, 185 ignored >> - part 10 >> - part 9 cell >> - part 8 >> - ... and 8 more: https://git.openjdk.org/jfx/compare/0b7ea989...55b33b2c > > modules/javafx.controls/src/test/java/test/javafx/scene/chart/NumberAxisTest.java line 260: > >> 258: >> 259: @Test >> 260: @Timeout(value=1000, unit=TimeUnit.MILLISECONDS) > > minor: I think the convention is to have spaces around the parameters, > e.g. `@Timeout(value = 1000, unit = TimeUnit.MILLISECONDS)` > Just scanned the JavaFX code and we seem to be inconsiostent on that, so I will leave that up to do. I don't think we have a (different) format for annotation arguments, so I've used the function arguments format convention here, no spaces. One point we could use later is to omit TimeUnit and express the value in seconds, but I kept milliseconds for sake of reviewers. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1771867083 From angorya at openjdk.org Mon Sep 23 18:12:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 18:12:48 GMT Subject: RFR: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: On Sat, 21 Sep 2024 00:54:05 GMT, Jay Bhaskar wrote: >> Successfully converted Non-parametrized base tests to JUnit 5 > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > restore and convert mistakenly removed tests thank you for making the changes! looks good now. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1576#pullrequestreview-2322988472 From kcr at openjdk.org Mon Sep 23 18:17:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 23 Sep 2024 18:17:47 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 20:47:06 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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 20 additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - ... and 10 more: https://git.openjdk.org/jfx/compare/965d03e2...6c44cc6c @arapte plans to review this as the needed "R"eviewer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1561#issuecomment-2369028663 From kcr at openjdk.org Mon Sep 23 18:17:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 23 Sep 2024 18:17:49 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v3] In-Reply-To: <-W1LzhNhPOdL_5QTxzTAGnAHR3L4M8CWAI4-DqMUp8E=.c319abb8-3581-4751-a132-f2ba8062f270@github.com> References: <-W1LzhNhPOdL_5QTxzTAGnAHR3L4M8CWAI4-DqMUp8E=.c319abb8-3581-4751-a132-f2ba8062f270@github.com> Message-ID: On Sun, 22 Sep 2024 13:07:57 GMT, Marius Hanl 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 18 additional commits since the last revision: >> >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 12, 9274 - 185 = 9089 >> - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls >> - part 11, 9242 tests, 185 ignored >> - part 10 >> - part 9 cell >> - part 8 >> - ... and 8 more: https://git.openjdk.org/jfx/compare/4a43f4fa...55b33b2c > > modules/javafx.controls/src/test/java/test/javafx/scene/chart/NumberAxisTest.java line 260: > >> 258: >> 259: @Test >> 260: @Timeout(value=1000, unit=TimeUnit.MILLISECONDS) > > minor: I think the convention is to have spaces around the parameters, > e.g. `@Timeout(value = 1000, unit = TimeUnit.MILLISECONDS)` > Just scanned the JavaFX code and we seem to be inconsiostent on that, so I will leave that up to do. @Maran23 is correct about the convention when there is an annotation (or a function call, for that matter) with an embedded parameter assignment. For example, see various `@Deprecated` annotations in the JDK and JavaFX. However, as he pointed out, we are not consistent on that, so I would leave it as is for this PR to avoid more churn. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1561#discussion_r1771887528 From arapte at openjdk.org Mon Sep 23 18:20:46 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 23 Sep 2024 18:20:46 GMT Subject: RFR: 8338468: [TestBug] Convert controls tests to JUnit 5 [v4] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 20:47:06 GMT, Andy Goryachev wrote: >> Converting control module tests to junit5. >> >> The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ## JUnit5 Migration Notes >> >> Most of the changes are trivial, except for the following: >> >> 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) >> 2. parameterized tests: junit5 allows for parameterizing individual tests >> 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) >> 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes >> 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` >> >> ### Parameterized Class-Level Tests >> >> junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) >> >> The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. >> >> To summarize: >> - remove `@Before` from the setup method >> - call the setup method from each parameterized method (adding parameters and replacing `@Test` with >> >> @ParameterizedTest >> @MethodSource("parameters") >> >> where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: >> >> private static Stream parameters() { >> return Stream.of( >> Arguments.of("a", 1), >> Arguments.of("foo", 3) >> ); >> } >> >> >> ### Migration Tricks >> >> Here are the steps that might speed up the process: >> >> 1. remove all the junit4 imports >> 2. paste the following junit5 imports (below) >> 3. fix the errors >> 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) >> 7. after all is done, verify that there is no more junit4 names by running the command mentioned below >> >> junit5 imports (in no particular order): >> >> import org.junit.jupiter.api.AfterEach; >> import org.junit.jupiter.api.BeforeEach; >> import org.junit.jupit... > > 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 20 additional commits since the last revision: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - review comments > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 12, 9274 - 185 = 9089 > - Merge remote-tracking branch 'origin/master' into 8338468.junit5.controls > - part 11, 9242 tests, 185 ignored > - part 10 > - ... and 10 more: https://git.openjdk.org/jfx/compare/17a50db8...6c44cc6c LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1561#pullrequestreview-2323004934 From angorya at openjdk.org Mon Sep 23 18:32:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 18:32:48 GMT Subject: Integrated: 8338468: [TestBug] Convert controls tests to JUnit 5 In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 18:25:40 GMT, Andy Goryachev wrote: > Converting control module tests to junit5. > > The following notes might help reviewers and people migrating other parts of https://bugs.openjdk.org/browse/JDK-8339170. The direct link to the notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ## JUnit5 Migration Notes > > Most of the changes are trivial, except for the following: > > 1. assertEquals() and similar methods: the message can be confused with the expected argument (junit5 moved the message to the last position) > 2. parameterized tests: junit5 allows for parameterizing individual tests > 3. parameterized `@BeforeEach` and `@AfterEach`: (see discussion below) > 4. charts: the test hierarchy for charts mixed parameterized and non-parameterized kinds, necessitating more changes > 5. overridden parameterized tests (must be annotated with ` @ParameterizedTest @MethodSource` > > ### Parameterized Class-Level Tests > > junit5 does not support parameterized class-level tests yet (see https://github.com/junit-team/junit5/issues/878) > > The workaround is to setup each test explicitly by calling the method that used to be annotated with `@Before` in each parameterized test method. There might be another solutions (see, for example, https://stackoverflow.com/questions/62036724/how-to-parameterize-beforeeach-in-junit-5/69265907#69265907) but I thought explicit setup might be simpler to deploy. > > To summarize: > - remove `@Before` from the setup method > - call the setup method from each parameterized method (adding parameters and replacing `@Test` with > > @ParameterizedTest > @MethodSource("parameters") > > where parameters() is a static method which supplies the parameters. In the case when parameters have more than one element, the following code might be useful: > > private static Stream parameters() { > return Stream.of( > Arguments.of("a", 1), > Arguments.of("foo", 3) > ); > } > > > ### Migration Tricks > > Here are the steps that might speed up the process: > > 1. remove all the junit4 imports > 2. paste the following junit5 imports (below) > 3. fix the errors > 6. optimize imports via IDE (command-shift-O in Eclipse on macOS) > 7. after all is done, verify that there is no more junit4 names by running the command mentioned below > > junit5 imports (in no particular order): > > import org.junit.jupiter.api.AfterEach; > import org.junit.jupiter.api.BeforeEach; > import org.junit.jupiter.api.Test; > import org.junit.jupiter.api.Disabled; > import org.junit.jupiter.params.ParameterizedTest; > imp... This pull request has now been integrated. Changeset: 51717533 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/51717533b1d54fdb8a2817035b201763b3d4febe Stats: 9605 lines in 212 files changed: 3409 ins; 1823 del; 4373 mod 8338468: [TestBug] Convert controls tests to JUnit 5 Reviewed-by: mhanl, lkostyra, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1561 From angorya at openjdk.org Mon Sep 23 18:38:23 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 18:38:23 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: 30 more ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1569/files - new: https://git.openjdk.org/jfx/pull/1569/files/777620ef..bbf40343 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1569&range=04-05 Stats: 4 lines in 2 files changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1569.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1569/head:pull/1569 PR: https://git.openjdk.org/jfx/pull/1569 From angorya at openjdk.org Mon Sep 23 19:34:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 19:34:45 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v5] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 13:19:36 GMT, Lukasz Kostyra 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 24 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into 8339510.junit5.system >> - more fixes >> - rotate test >> - review comments >> - unused imports >> - fixes 4 >> - fixes 3 >> - fixes 2 >> - fixes 1 >> - part 12 last >> - ... and 14 more: https://git.openjdk.org/jfx/compare/206e184f...777620ef > > tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 265: > >> 263: // Should not get here >> 264: latch.countDown(); >> 265: throw new AssertionError("Should never get here"); > > Should probably be `fail` won't compile with `fail()`, needs an exception > tests/system/src/test/java/test/javafx/scene/Snapshot1Test.java line 387: > >> 385: // Should not get here >> 386: latch.countDown(); >> 387: throw new AssertionError("Should never get here"); > > Should probably be `fail` won't compile with `fail()`, needs an exception ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1771973318 PR Review Comment: https://git.openjdk.org/jfx/pull/1569#discussion_r1771973375 From angorya at openjdk.org Mon Sep 23 19:43:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 19:43:43 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 18:38:23 GMT, Andy Goryachev wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 30 more The latest commit fixes the number of tests issue. Note: we should not look at the number of tests reported by gradle at the end of the test run, instead we should look at the HTML report. master: tests=2728, failures=49, ignored=554 (tests - ignored = 2174) this PR: tests=2281, failures=96, ignored=107 (test - ignored = 2174) The actual number of failed tests varies from run to run, and also, being "unstable", differs between master and PR. For example: FuzzyTapTest: fails with timeout (TO) vs. passing in master SingleTouchTest: passing vs. failing with TO in master TouchButtonTest pass vs failures with TO in master I also noticed a bug in USKeyboardTest, see https://bugs.openjdk.org/browse/JDK-8340693 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2369211321 From angorya at openjdk.org Mon Sep 23 19:50:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 19:50:44 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 09:14:02 GMT, Lukasz Kostyra wrote: >> This PR converts all tests in `modules/javafx.graphics` to use JUnit5. >> >> ## Details >> >> Trivial changes resolved by first four commits: >> - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) >> - Message Strings in `assert*` calls moved to the end to follow 5's argument order >> - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations >> - Some test formatting unification - keeping annotations on a separate line from method definition >> - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. >> >> Non-trivial changes: >> - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: >> - `DirtyRegionTestBase` >> - `CssMethodsTestBase` >> - `ObjectMethodsTestBase` >> - `OnInvalidateMethodsTestBase` >> - `PropertiesTestBase` >> - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized >> - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` >> - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 >> >> At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. >> >> As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. >> >> ## Results >> >> Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: >> >> | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | >> | ------------ | ------ | ------ | >> | Test count | 23272 | 23275 | >> | Failures | 0 | 0 | >> | Ignored | 99 | 102 | >> | Successful % | 100% | 100% | >> >> The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion... > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review comments v2 Looks good, thank you for making changes! May thanks to @Maran23 for lending your expertise and time to this review! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1566#pullrequestreview-2323172176 From angorya at openjdk.org Mon Sep 23 20:24:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 20:24:45 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v3] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> Message-ID: On Thu, 22 Aug 2024 22:39:25 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 incrementally with one additional commit since the last revision: > > in case of hitting min max this toddler PR needs attention ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2369300308 From angorya at openjdk.org Mon Sep 23 20:26:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 20:26:40 GMT Subject: RFR: 8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed [v2] In-Reply-To: References: Message-ID: On Tue, 13 Aug 2024 21:35:11 GMT, Andy Goryachev wrote: >> Enable backpropagation of `isConsumed` flag to the ancestor(s) of events cloned via `Event.copyFor()`. >> >> This change has a minimal API impact and allows for a fine-grained control of when to propagate and when not to propagate. >> >> The proposed change could make [JDK-8303209](https://bugs.openjdk.org/browse/JDK-8303209) unnecessary. > > 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 10 additional commits since the last revision: > > - avoid csr > - Merge remote-tracking branch 'origin/master' into ag.consume > - only if consumed > - only when consumed > - propagate > - cleanup > - simpler > - event helper > - copy for test > - propagate consume action converting to Draft to investigate a solution that will not require public API changes ------------- PR Comment: https://git.openjdk.org/jfx/pull/1523#issuecomment-2369304116 From angorya at openjdk.org Mon Sep 23 20:27:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Sep 2024 20:27:49 GMT Subject: Withdrawn: 8319555: [TestBug] Utility for creating instruction window for manual tests In-Reply-To: References: Message-ID: On Wed, 20 Mar 2024 20:21:30 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1413 From kcr at openjdk.org Mon Sep 23 20:36:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 23 Sep 2024 20:36:41 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 18:38:23 GMT, Andy Goryachev wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 30 more Marked as reviewed by kcr (Lead). I ran the latest and I now see the missing 30 tests being run. gradle --continue --info -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true -PUNSTABLE_TEST=true \ :systemTests:test --tests "test.robot.com.sun.glass.ui.monocle*" #### master 1773 tests : 56 failures : 495 ignored -- tests run: 1773-495=1278 #### this PR run 1: 1326 tests : 72 failures: 48 ignored -- tests run: 1326-48=1278 run 2: 1326 tests : 37 failures: 48 ignored -- tests run: 1326-48=1278 All good. ------------- PR Review: https://git.openjdk.org/jfx/pull/1569#pullrequestreview-2323254703 PR Comment: https://git.openjdk.org/jfx/pull/1569#issuecomment-2369321752 From mhanl at openjdk.org Mon Sep 23 20:55:42 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 23 Sep 2024 20:55:42 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 09:14:02 GMT, Lukasz Kostyra wrote: >> This PR converts all tests in `modules/javafx.graphics` to use JUnit5. >> >> ## Details >> >> Trivial changes resolved by first four commits: >> - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) >> - Message Strings in `assert*` calls moved to the end to follow 5's argument order >> - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations >> - Some test formatting unification - keeping annotations on a separate line from method definition >> - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. >> >> Non-trivial changes: >> - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: >> - `DirtyRegionTestBase` >> - `CssMethodsTestBase` >> - `ObjectMethodsTestBase` >> - `OnInvalidateMethodsTestBase` >> - `PropertiesTestBase` >> - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized >> - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` >> - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 >> >> At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. >> >> As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. >> >> ## Results >> >> Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: >> >> | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | >> | ------------ | ------ | ------ | >> | Test count | 23272 | 23275 | >> | Failures | 0 | 0 | >> | Ignored | 99 | 102 | >> | Successful % | 100% | 100% | >> >> The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion... > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review comments v2 Looks good! ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1566#pullrequestreview-2323287483 From kcr at openjdk.org Mon Sep 23 23:06:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 23 Sep 2024 23:06:40 GMT Subject: RFR: 8297072: Provide gradle option to test a previously built SDK In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 15:48:00 GMT, Ambarish Rapte wrote: > #### Requirement: > We want to be able to test a JavaFX SDK built somewhere else other than on current machine or current repo on same machine. Which means we should be able to run the unit and system tests with a different JavaFX SDK. > > #### Change: > ##### Run tests using a specified JavaFX SDK: > - Introduce a property `TEST_JAVAFX_SDK_PATH` that points to the JavaFX SDK which was built elsewhere. > - Modify the paths generated by build.gradle to point to the path sepcified by `TEST_JAVAFX_SDK_PATH` > - When a `TEST_JAVAFX_SDK_PATH` is specified `-PTEST_ONLY=true` must also be specified. > > ##### Generate the JavaFX SDK bundle > - Generate the minimal JavaFX SDK bundle that is required to run the tests: We require content of the _build/sdk_ and _build/shims_ directories to achieve the same. > > > #### Verification: > ##### With a single machine: > 1. Create two local copies JavaFX repo, [repo1, repo2] > 2. Build sdk and shims in repo1. `gradle sdk shims` > 3. In repo2, run different tests as, >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**repo1/build** :base:test > 4. In repo1 run `gradle all` > 5. `javafx-sdk-shims.zip` file would be created under repo1/build. unzip it any `unzip-path` on machine > 6. In repo2, run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test > > ##### With 2 machines. > 1. Run `gradle all` on a machine1 > 2. Move build/javafx-sdk-shims.zip to machine2 and unzip to any `unzip-path` > 3. Run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test > > > #### Additional changes: > Additionally we observed that three unit tests failed because they access a specific path. A path that would no exists when JavaFX SDK is not built. > 1. Controls test: test.javafx.scene.control.ControlTest.testRT18097 > It required path: modules/javafx.controls/build/classes/java/main/javafx.controls/javafx > It is fixed by change on line 2811 > > 2. Graphics test: test.javafx.css.CssMetaDataTest.testRT18097 > It required path: modules/javafx.graphics/build/classes/java/main/javafx.graphics/javafx > It is fixed by change on line 2722 > > 3. Base test: test.com.sun.javafx.runtime.VersionInfoTest > It required path: build/module-lib/javafx.properties > VersionInfoTest is specific to the local build of JavaFX. So, It can be safely excluded when TEST_JAVAFX_SDK_PATH is specified. > It is fixed by change on line 2304 t... I tried the first recipe, with repo1 pointing to a full build of the current jfx master, and repo2 pointing to a clean repo with the patch from this PR. I deliberately did not build the sdk in repo2. I was able to compile and run the tests from all projects except `javafx.swt`. Those tests are disabled (not run), but compilation of the tests is enabled, and it fails without having first compiled the "sdk" in repo2. Here is the error: $ cd repo2 $ gradle --info --continue -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=repo1/build test ... > Task :swt:compileTestJava FAILED Caching disabled for task ':swt:compileTestJava' because: Build cache is disabled 'Forking compiler via ForkOptions.executable' satisfied Task ':swt:compileTestJava' is not up-to-date because: Task has failed previously. The input changes require a full rebuild for incremental task ':swt:compileTestJava'. Compilation mode: command line compilation Compiling with toolchain '/jdk-22.0.2.jdk/Contents/Home'. Compiling with Java command line compiler '/jdk-22.0.2.jdk/Contents/Home/bin/javac'. Starting process 'command '/jdk-22.0.2.jdk/Contents/Home/bin/javac''. Working directory: jfx/modules/javafx.swt Command: /jdk-22.0.2.jdk/Contents/Home/bin/javac @jfx/modules/javafx.swt/build/tmp/compileTestJava/java-compiler-args.txt Successfully started process 'command '/jdk-22.0.2.jdk/Contents/Home/bin/javac'' jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/FXCanvasScaledTest.java:43: error: package javafx.embed.swt does not exist import javafx.embed.swt.FXCanvas; ^ jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/FXCanvasScaledTest.java:123: error: cannot find symbol private static void initFX(FXCanvas canvas) { ^ symbol: class FXCanvas location: class FXCanvasScaledTest jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTCursorsTest.java:28: error: package javafx.embed.swt does not exist import javafx.embed.swt.FXCanvas; ^ jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/FXCanvasTest.java:28: error: package javafx.embed.swt does not exist import javafx.embed.swt.FXCanvas; ^ jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/FXCanvasScaledTest.java:71: error: cannot find symbol final FXCanvas canvas = new FXCanvas(shell, SWT.NONE); ^ symbol: class FXCanvas location: class FXCanvasScaledTest jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/FXCanvasScaledTest.java:71: error: cannot find symbol final FXCanvas canvas = new FXCanvas(shell, SWT.NONE); ^ symbol: class FXCanvas location: class FXCanvasScaledTest jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTCursorsTest.java:49: error: cannot find symbol final FXCanvas canvas = new FXCanvas(shell, SWT.NONE); ^ symbol: class FXCanvas location: class SWTCursorsTest jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/SWTCursorsTest.java:49: error: cannot find symbol final FXCanvas canvas = new FXCanvas(shell, SWT.NONE); ^ symbol: class FXCanvas location: class SWTCursorsTest jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/FXCanvasTest.java:47: error: cannot find symbol final FXCanvas canvas = new FXCanvas(shell, SWT.NONE); ^ symbol: class FXCanvas location: class FXCanvasTest jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/FXCanvasTest.java:47: error: cannot find symbol final FXCanvas canvas = new FXCanvas(shell, SWT.NONE); ^ symbol: class FXCanvas location: class FXCanvasTest jfx/modules/javafx.swt/src/test/java/test/javafx/embed/swt/FXCanvasTest.java:55: error: cannot find symbol assertSame(canvas, FXCanvas.getFXCanvas(canvas.getScene())); ^ symbol: variable FXCanvas location: class FXCanvasTest 11 errors Resolve mutations for :swt:processTestResources (Thread[#65,included builds,5,main]) started. :swt:processTestResources (Thread[#65,included builds,5,main]) started. > Task :swt:processTestResources UP-TO-DATE Caching disabled for task ':swt:processTestResources' because: Build cache is disabled Not worth caching Skipping task ':swt:processTestResources' as it is up-to-date. FAILURE: Build failed with an exception. Unlike the other modules, the `javafx.swt` module is not loaded from the module path, so the absence of the sdk build in the repo you are testing causes the compilations of the javafx.swt tests to fail. Since they aren't being run, perhaps the best solution is to disable the compileTestJava task in the `:swt` project if `IS_TEST_JAVAFX_SDK` is true. I left a minor naming suggestion for the name of the new gradle property. build.gradle line 733: > 731: > 732: ext.IS_TEST_JAVAFX_SDK = false > 733: if (hasProperty("TEST_JAVAFX_SDK_PATH")) { Suggestion: drop `JAVAFX_` from the name of this property and just call it `TEST_SDK_PATH`. That's closer to what we did in JDK 8 when we had a similar feature (it was called `TEST_SDK`, but I think adding `_PATH` as a suffix is good). build.gradle line 745: > 743: fail("The provided TEST_JAVAFX_SDK_PATH=${TEST_JAVAFX_SDK_PATH} is invalid") > 744: } > 745: ext.IS_TEST_JAVAFX_SDK = true Similarly, you might consider removing `JAVAFX_` from this property, but it's an internal-only variable, so it doesn't matter. ------------- PR Review: https://git.openjdk.org/jfx/pull/1577#pullrequestreview-2323660081 PR Review Comment: https://git.openjdk.org/jfx/pull/1577#discussion_r1772318410 PR Review Comment: https://git.openjdk.org/jfx/pull/1577#discussion_r1772319485 From jbhaskar at openjdk.org Tue Sep 24 00:29:43 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 24 Sep 2024 00:29:43 GMT Subject: Integrated: 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 In-Reply-To: References: Message-ID: <63BS9QGDsITldMnRWpjxViEwjsawuqjR5B1G5JJr9CM=.66d88a43-b79d-4c89-abdf-f7065df8803f@github.com> On Thu, 19 Sep 2024 16:14:31 GMT, Jay Bhaskar wrote: > Successfully converted Non-parametrized base tests to JUnit 5 This pull request has now been integrated. Changeset: 5bec3f8e Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/5bec3f8e83f514063b767585b039d27c0bb46a0f Stats: 2367 lines in 170 files changed: 775 ins; 31 del; 1561 mod 8339511: [TestBug] Convert Non parametrized base tests to JUnit 5 Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1576 From lkostyra at openjdk.org Tue Sep 24 06:03:44 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 24 Sep 2024 06:03:44 GMT Subject: RFR: 8339512: [TestBug] Convert graphics tests to JUnit 5 [v3] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 09:14:02 GMT, Lukasz Kostyra wrote: >> This PR converts all tests in `modules/javafx.graphics` to use JUnit5. >> >> ## Details >> >> Trivial changes resolved by first four commits: >> - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) >> - Message Strings in `assert*` calls moved to the end to follow 5's argument order >> - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations >> - Some test formatting unification - keeping annotations on a separate line from method definition >> - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. >> >> Non-trivial changes: >> - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: >> - `DirtyRegionTestBase` >> - `CssMethodsTestBase` >> - `ObjectMethodsTestBase` >> - `OnInvalidateMethodsTestBase` >> - `PropertiesTestBase` >> - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized >> - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` >> - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 >> >> At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. >> >> As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. >> >> ## Results >> >> Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: >> >> | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | >> | ------------ | ------ | ------ | >> | Test count | 23272 | 23275 | >> | Failures | 0 | 0 | >> | Ignored | 99 | 102 | >> | Successful % | 100% | 100% | >> >> The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion... > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review comments v2 Thanks for your help everyone! This sure was a monster, but we got through it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1566#issuecomment-2370261181 From lkostyra at openjdk.org Tue Sep 24 06:03:45 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 24 Sep 2024 06:03:45 GMT Subject: Integrated: 8339512: [TestBug] Convert graphics tests to JUnit 5 In-Reply-To: References: Message-ID: On Fri, 13 Sep 2024 15:14:39 GMT, Lukasz Kostyra wrote: > This PR converts all tests in `modules/javafx.graphics` to use JUnit5. > > ## Details > > Trivial changes resolved by first four commits: > - Import changes to use `org.junit.jupiter` package instead of `org.junit` or `junit.framework` and all changes that follow it (ex. `@Before` -> `@BeforeEach`) > - Message Strings in `assert*` calls moved to the end to follow 5's argument order > - Some simple Parametrized tests (aka. those which only did a straightforward assignment of test parameters) adjusted to use JUnit5's `@ParametrizedTest` and `@MethodSource` annotations > - Some test formatting unification - keeping annotations on a separate line from method definition > - Some tests used `@Rule` annotation which is missing from JUnit5. Luckily, all those uses just set `ExpectedException thrown = ExpectedException.none()` and then mid-test set it to some expected exception class. This was easily replaceable with `assertThrows`. > > Non-trivial changes: > - Mutliple tests use common test bases and derive from it to check specific behaviors. Those include: > - `DirtyRegionTestBase` > - `CssMethodsTestBase` > - `ObjectMethodsTestBase` > - `OnInvalidateMethodsTestBase` > - `PropertiesTestBase` > - `ServiceTestBase` & derivatives required some rework due to `ServiceExceptionTest` being a derived parametrized class while other `ServiceTestBase` were not parametrized > - `TransformOperationsTest` not only expanded 3 test parameters onto 6 different test class members, but also exposed its `getParams()` call to other testers - `AffineOperationsTest` and `TransformUtilsTest` > - Other classes used `@BeforeEach` annotation which accessed test parameters, those setup methods were called manually in-test as per discussion in #1561 > > At the end I added a change converting `assertTimeout` uses I added to `@Timeout` annotation, as recommended in other PRs. > > As for conversion practices and methods, most of these were discussed as part of #1561 so I will skip them here. > > ## Results > > Below are results of the test conversion and runs of `gradle --info :graphics:test` on my machine: > > | Category | JUnit4 ( 4647367ce ) | JUnit5 (this PR) | > | ------------ | ------ | ------ | > | Test count | 23272 | 23275 | > | Failures | 0 | 0 | > | Ignored | 99 | 102 | > | Successful % | 100% | 100% | > > The difference in test count and ignored comes from `Popup_parentWindow_Test.java` where the entire test class was annotated as `@Ignored`. After conversion, the `@Disabled` annotation applies to each test individually rather than t... This pull request has now been integrated. Changeset: 41738406 Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/417384066a4ed9be0cc2ff99320f6d5eb4d14a66 Stats: 14320 lines in 410 files changed: 4506 ins; 2105 del; 7709 mod 8339512: [TestBug] Convert graphics tests to JUnit 5 Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1566 From arapte at openjdk.org Tue Sep 24 06:19:13 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 24 Sep 2024 06:19:13 GMT Subject: RFR: 8297072: Provide gradle option to test a previously built SDK [v2] In-Reply-To: References: Message-ID: > #### Requirement: > We want to be able to test a JavaFX SDK built somewhere else other than on current machine or current repo on same machine. Which means we should be able to run the unit and system tests with a different JavaFX SDK. > > #### Change: > ##### Run tests using a specified JavaFX SDK: > - Introduce a property `TEST_JAVAFX_SDK_PATH` that points to the JavaFX SDK which was built elsewhere. > - Modify the paths generated by build.gradle to point to the path sepcified by `TEST_JAVAFX_SDK_PATH` > - When a `TEST_JAVAFX_SDK_PATH` is specified `-PTEST_ONLY=true` must also be specified. > > ##### Generate the JavaFX SDK bundle > - Generate the minimal JavaFX SDK bundle that is required to run the tests: We require content of the _build/sdk_ and _build/shims_ directories to achieve the same. > > > #### Verification: > ##### With a single machine: > 1. Create two local copies JavaFX repo, [repo1, repo2] > 2. Build sdk and shims in repo1. `gradle sdk shims` > 3. In repo2, run different tests as, >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**repo1/build** :base:test > 4. In repo1 run `gradle all` > 5. `javafx-sdk-shims.zip` file would be created under repo1/build. unzip it any `unzip-path` on machine > 6. In repo2, run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test > > ##### With 2 machines. > 1. Run `gradle all` on a machine1 > 2. Move build/javafx-sdk-shims.zip to machine2 and unzip to any `unzip-path` > 3. Run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test > > > #### Additional changes: > Additionally we observed that three unit tests failed because they access a specific path. A path that would no exists when JavaFX SDK is not built. > 1. Controls test: test.javafx.scene.control.ControlTest.testRT18097 > It required path: modules/javafx.controls/build/classes/java/main/javafx.controls/javafx > It is fixed by change on line 2811 > > 2. Graphics test: test.javafx.css.CssMetaDataTest.testRT18097 > It required path: modules/javafx.graphics/build/classes/java/main/javafx.graphics/javafx > It is fixed by change on line 2722 > > 3. Base test: test.com.sun.javafx.runtime.VersionInfoTest > It required path: build/module-lib/javafx.properties > VersionInfoTest is specific to the local build of JavaFX. So, It can be safely excluded when TEST_JAVAFX_SDK_PATH is specified. > It is fixed by change on line 2304 t... Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: - disable swt compileTestJava - review: rename vars ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1577/files - new: https://git.openjdk.org/jfx/pull/1577/files/7157f574..fca8e6b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1577&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1577&range=00-01 Stats: 23 lines in 1 file changed: 4 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/1577.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1577/head:pull/1577 PR: https://git.openjdk.org/jfx/pull/1577 From arapte at openjdk.org Tue Sep 24 06:23:41 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 24 Sep 2024 06:23:41 GMT Subject: RFR: 8297072: Provide gradle option to test a previously built SDK [v2] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 23:03:54 GMT, Kevin Rushforth wrote: > disable the compileTestJava task in the :swt project if IS_TEST_JAVAFX_SDK is true. disabled the task accordingly. Thanks for the review, updated the PR as per comments. The names TEST_SDK_PATH and IS_TEST_SDK seem better. > build.gradle line 733: > >> 731: >> 732: ext.IS_TEST_JAVAFX_SDK = false >> 733: if (hasProperty("TEST_JAVAFX_SDK_PATH")) { > > Suggestion: drop `JAVAFX_` from the name of this property and just call it `TEST_SDK_PATH`. That's closer to what we did in JDK 8 when we had a similar feature (it was called `TEST_SDK`, but I think adding `_PATH` as a suffix is good). Changed name as `TEST_SDK_PATH` > build.gradle line 745: > >> 743: fail("The provided TEST_JAVAFX_SDK_PATH=${TEST_JAVAFX_SDK_PATH} is invalid") >> 744: } >> 745: ext.IS_TEST_JAVAFX_SDK = true > > Similarly, you might consider removing `JAVAFX_` from this property, but it's an internal-only variable, so it doesn't matter. Changed name as `IS_TEST_SDK` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1577#issuecomment-2370292396 PR Review Comment: https://git.openjdk.org/jfx/pull/1577#discussion_r1772696103 PR Review Comment: https://git.openjdk.org/jfx/pull/1577#discussion_r1772696056 From mhanl at openjdk.org Tue Sep 24 07:51:42 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 24 Sep 2024 07:51:42 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v2] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 18:21:04 GMT, Kevin Rushforth wrote: >> This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). >> >> JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). >> >> While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. >> >> ### Testing instructions >> >> I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. >> >> The default timeout values for test and lifecycle methods can be modified using a gradle property: >> >> * `JUNIT_TEST_TIMEOUT` : default = 120s >> * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s >> >> For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: >> >> >> gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused sleep method from BehaviorRobotTestBase. Makes sense and is a good imrovement! ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1575#pullrequestreview-2324367629 From lkostyra at openjdk.org Tue Sep 24 09:58:44 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 24 Sep 2024 09:58:44 GMT Subject: RFR: 8339510: [TestBug] Convert system tests to JUnit 5 [v6] In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 18:38:23 GMT, Andy Goryachev wrote: >> Converting system tests to junit5. >> >> Please see migration notes: >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md >> >> ### Notes: >> >> I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) >> >> QPathTest > executionError FAILED >> org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) >> at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) >> at app//test.util.Util.runAndWait(Util.java:156) >> at app//test.util.Util.runAndWait(Util.java:127) >> at app//test.util.Util.shutdown(Util.java:365) >> at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) >> >> >> This test might fail intermittently (?) on linux only: >> >> SetSceneScalingTest > testShowAndSetScene() FAILED >> org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) >> at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) >> at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > 30 more LGTM ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1569#pullrequestreview-2324734966 From tsayao at openjdk.org Tue Sep 24 11:23:50 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 24 Sep 2024 11:23:50 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v25] In-Reply-To: References: Message-ID: On Wed, 21 Aug 2024 09:58:53 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 incrementally with one additional commit since the last revision: > > Remove negative checks Just a reminder to not let this forgotten. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2370978833 From thiago.sayao at gmail.com Tue Sep 24 12:07:36 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 24 Sep 2024 09:07:36 -0300 Subject: Possible leak on prism es2 Message-ID: Hi, While doing some work on replacing GLX with EGL I discovered a possible leak. Running this test: gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SetSceneScalingTest will result in X11GLDrawable -> nCreateDrawable to be called multiple times on the same test, while GLDrawable -> deleteDrawableInfo is never called, generating a leak (I think). I can probably fix this, but I still have little knowledge on the es2 part, so any help would be appreciated. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Sep 24 13:12:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 13:12:43 GMT Subject: RFR: 8297072: Provide gradle option to test a previously built SDK [v2] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 06:19:13 GMT, Ambarish Rapte wrote: >> #### Requirement: >> We want to be able to test a JavaFX SDK built somewhere else other than on current machine or current repo on same machine. Which means we should be able to run the unit and system tests with a different JavaFX SDK. >> >> #### Change: >> ##### Run tests using a specified JavaFX SDK: >> - Introduce a property `TEST_JAVAFX_SDK_PATH` that points to the JavaFX SDK which was built elsewhere. >> - Modify the paths generated by build.gradle to point to the path sepcified by `TEST_JAVAFX_SDK_PATH` >> - When a `TEST_JAVAFX_SDK_PATH` is specified `-PTEST_ONLY=true` must also be specified. >> >> ##### Generate the JavaFX SDK bundle >> - Generate the minimal JavaFX SDK bundle that is required to run the tests: We require content of the _build/sdk_ and _build/shims_ directories to achieve the same. >> >> >> #### Verification: >> ##### With a single machine: >> 1. Create two local copies JavaFX repo, [repo1, repo2] >> 2. Build sdk and shims in repo1. `gradle sdk shims` >> 3. In repo2, run different tests as, >>> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**repo1/build** :base:test >> 4. In repo1 run `gradle all` >> 5. `javafx-sdk-shims.zip` file would be created under repo1/build. unzip it any `unzip-path` on machine >> 6. In repo2, run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >>> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test >> >> ##### With 2 machines. >> 1. Run `gradle all` on a machine1 >> 2. Move build/javafx-sdk-shims.zip to machine2 and unzip to any `unzip-path` >> 3. Run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >>> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test >> >> >> #### Additional changes: >> Additionally we observed that three unit tests failed because they access a specific path. A path that would no exists when JavaFX SDK is not built. >> 1. Controls test: test.javafx.scene.control.ControlTest.testRT18097 >> It required path: modules/javafx.controls/build/classes/java/main/javafx.controls/javafx >> It is fixed by change on line 2811 >> >> 2. Graphics test: test.javafx.css.CssMetaDataTest.testRT18097 >> It required path: modules/javafx.graphics/build/classes/java/main/javafx.graphics/javafx >> It is fixed by change on line 2722 >> >> 3. Base test: test.com.sun.javafx.runtime.VersionInfoTest >> It required path: build/module-lib/javafx.properties >> VersionInfoTest is specific to the local build of JavaFX. So, It can be safely ... > > Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: > > - disable swt compileTestJava > - review: rename vars Looks good. I ran the following in a clean repo1 and all tests passes: gradle -PTEST_ONLY=true -PFULL_TEST=true -PTEST_SDK_PATH=repo2/build test ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1577#pullrequestreview-2325209791 From kcr at openjdk.org Tue Sep 24 13:34:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 13:34:44 GMT Subject: [jfx23u] RFR: Merge jfx:jfx23 Message-ID: Clean merge from `jfx:jfx23` to `master` (final sync to pick up release notes). ------------- Commit messages: - Merge remote-tracking branch 'jfx/jfx23' into merge-jfx-jfx23-to-master-2024-09-24 - 8339247: Create release notes for JavaFX 23 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx23u/pull/21/files Stats: 145 lines in 1 file changed: 145 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx23u/pull/21.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/21/head:pull/21 PR: https://git.openjdk.org/jfx23u/pull/21 From angorya at openjdk.org Tue Sep 24 14:27:51 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 24 Sep 2024 14:27:51 GMT Subject: Integrated: 8339510: [TestBug] Convert system tests to JUnit 5 In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024 17:57:07 GMT, Andy Goryachev wrote: > Converting system tests to junit5. > > Please see migration notes: > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/JUnit5Migration.md > > ### Notes: > > I see shutdown timeout on linux, this will be addressed by [JDK-8340403](https://bugs.openjdk.org/browse/JDK-8340403) > > QPathTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:39) > at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:134) > at app//test.util.Util.runAndWait(Util.java:156) > at app//test.util.Util.runAndWait(Util.java:127) > at app//test.util.Util.shutdown(Util.java:365) > at app//test.com.sun.marlin.QPathTest.teardownOnce(QPathTest.java:146) > > > This test might fail intermittently (?) on linux only: > > SetSceneScalingTest > testShowAndSetScene() FAILED > org.opentest4j.AssertionFailedError: 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.AssertTrue.assertTrue(AssertTrue.java:35) > at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:179) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestShowSetSceneApp.test(SetSceneScalingTest.java:129) > at app//test.robot.javafx.stage.SetSceneScalingTest$TestApp.runTest(SetSceneScalingTest.java:89) > at app//test.robot.javafx.stage.SetSceneScalingTest.testShowAndSetScene(SetSceneScalingTest.java:193) This pull request has now been integrated. Changeset: 21601f8f Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/21601f8ff108d2829d057d5e85e05843f4ccb5e3 Stats: 5002 lines in 277 files changed: 818 ins; 967 del; 3217 mod 8339510: [TestBug] Convert system tests to JUnit 5 Reviewed-by: kcr, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1569 From angorya at openjdk.org Tue Sep 24 14:29:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 24 Sep 2024 14:29:44 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v2] In-Reply-To: References: Message-ID: On Fri, 20 Sep 2024 18:21:04 GMT, Kevin Rushforth wrote: >> This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). >> >> JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). >> >> While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. >> >> ### Testing instructions >> >> I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. >> >> The default timeout values for test and lifecycle methods can be modified using a gradle property: >> >> * `JUNIT_TEST_TIMEOUT` : default = 120s >> * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s >> >> For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: >> >> >> gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused sleep method from BehaviorRobotTestBase. #1569 has been integrated, we can make the final changes ------------- PR Comment: https://git.openjdk.org/jfx/pull/1575#issuecomment-2371461704 From kcr at openjdk.org Tue Sep 24 14:46:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 14:46:23 GMT Subject: [jfx23u] RFR: Merge jfx:jfx23 [v2] In-Reply-To: References: Message-ID: > Clean merge from `jfx:jfx23` to `master` (final sync to pick up release notes). 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 21 additional commits since the last revision: - Merge remote-tracking branch 'jfx/jfx23' into merge-jfx-jfx23-to-master-2024-09-24 - 8339848: Change JavaFX release version to 23.0.2 in jfx23u Reviewed-by: jvos - 8338701: Provide media support for libavcodec version 61 Backport-of: 6115b396bacf62f39dcaa93c7c0adcd60b428b8c - 8337481: File API: file.name contains path instead of name Backport-of: ca70a07b3ee712b1d06baf8a3901e6ae96070124 - 8334124: Rendering issues with CSS "text-shadow" in WebView Backport-of: e0ceafb7dba15b4faa683c336828e79f19a59d30 - 8338886: JavaFX debug builds fail on macOS Reviewed-by: angorya Backport-of: 48497168892f5625f77936eccf19e836a6c1971e - 8336940: Update GStreamer to 1.24.6 8336939: Update Glib to 2.80.4 Backport-of: b88ac0495650bd033ba11e3131e9bffc517872eb - 8338307: Additional WebKit 619.1 fixes from WebKitGTK 2.44.3 Backport-of: aa52f7efc370a4c55ff7a05a6903988871436d64 - Merge - 8338306: WebView Drag and Drop fails with WebKit 619.1 Backport-of: 67ac9d7804cd8d572bcc3e06e2f640d8a744d3bb - ... and 11 more: https://git.openjdk.org/jfx23u/compare/5f5a6e32...d2ee763a ------------- Changes: - all: https://git.openjdk.org/jfx23u/pull/21/files - new: https://git.openjdk.org/jfx23u/pull/21/files/d2ee763a..d2ee763a Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jfx23u&pr=21&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx23u/pull/21.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/21/head:pull/21 PR: https://git.openjdk.org/jfx23u/pull/21 From kcr at openjdk.org Tue Sep 24 14:46:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 14:46:24 GMT Subject: [jfx23u] Integrated: Merge jfx:jfx23 In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 13:29:24 GMT, Kevin Rushforth wrote: > Clean merge from `jfx:jfx23` to `master` (final sync to pick up release notes). This pull request has now been integrated. Changeset: dba5b200 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx23u/commit/dba5b20034aec1dd8d90a38a8d8651e1c1548aa7 Stats: 145 lines in 1 file changed: 145 ins; 0 del; 0 mod Merge ------------- PR: https://git.openjdk.org/jfx23u/pull/21 From jcorvel at gmail.com Tue Sep 24 14:51:37 2024 From: jcorvel at gmail.com (Johan Corveleyn) Date: Tue, 24 Sep 2024 16:51:37 +0200 Subject: Dead keys followed by space Message-ID: Hi, (This is my first post here, hope I'm following the right path) It seems JavaFX TextFields (and friends) do not automatically convert + into simply . They make it into +, which is very atypical. I would consider this behavior a bug, since it is different from any editor I know (and makes it very hard to enter a dead key character on its own). We ran into this with Java 8, I also reproduced it with openjdk 21 + openjfx 23. For instance if in a JavaFX TextField I type a '^' keystroke, it waits for the next keystroke (which is normal since it's a dead key, possibly followed by a character on which to put the '^'). But if I then type I expect a simple '^' to appear. Instead, in JavaFX, '^ ' appears. This does not happen in Swing, nor in any editor or shell or ... Background context: a user of our JavaFX application couldn't authenticate with their password (typed in a PasswordField). After an awful lot of troubleshooting we found that they used a '^' in their password. Of course the user didn't notice that after typing ^+space two dots appeared in the PasswordField. Now that user knows they have to backspace after typing ^+space ... I suppose inserting a Swing JPasswordField in our JavaFX app would work around this issue, but ... isn't there a better solution? Shouldn't this be regarded as a bug? -- Johan From thiago.sayao at gmail.com Tue Sep 24 15:15:54 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 24 Sep 2024 12:15:54 -0300 Subject: Dead keys followed by space In-Reply-To: References: Message-ID: Hi Johan, It might vary be platform. Which one are you using? (Windows, Mac, Linux). Try disabling IME (Input Method Editor) and see it it works. - Thiago Em ter., 24 de set. de 2024 11:51, Johan Corveleyn escreveu: > Hi, > > (This is my first post here, hope I'm following the right path) > > It seems JavaFX TextFields (and friends) do not automatically convert > + into simply . They make it into > +, which is very atypical. I would consider > this behavior a bug, since it is different from any editor I know (and > makes it very hard to enter a dead key character on its own). We ran > into this with Java 8, I also reproduced it with openjdk 21 + openjfx > 23. > > For instance if in a JavaFX TextField I type a '^' keystroke, it waits > for the next keystroke (which is normal since it's a dead key, > possibly followed by a character on which to put the '^'). But if I > then type I expect a simple '^' to appear. Instead, in JavaFX, > '^ ' appears. This does not happen in Swing, nor in any editor or > shell or ... > > Background context: a user of our JavaFX application couldn't > authenticate with their password (typed in a PasswordField). After an > awful lot of troubleshooting we found that they used a '^' in their > password. Of course the user didn't notice that after typing ^+space > two dots appeared in the PasswordField. Now that user knows they have > to backspace after typing ^+space ... > > I suppose inserting a Swing JPasswordField in our JavaFX app would > work around this issue, but ... isn't there a better solution? > Shouldn't this be regarded as a bug? > > -- > Johan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Sep 24 15:31:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 15:31:02 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v3] In-Reply-To: References: Message-ID: > This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). > > JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). > > While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. > > ### Testing instructions > > I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. > > The default timeout values for test and lifecycle methods can be modified using a gradle property: > > * `JUNIT_TEST_TIMEOUT` : default = 120s > * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s > > For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: > > > gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test 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 five additional commits since the last revision: - throw new AssertionError(ex) --> fail(ex) - Merge remote-tracking branch 'upstream/master' into 8328629-junit-timeout - Remove unused sleep method from BehaviorRobotTestBase. - Fix typo (extra spaces) in system property name - 8328629: JUnit test without a timeout value can hang indefinitely ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1575/files - new: https://git.openjdk.org/jfx/pull/1575/files/8a4078fe..de443509 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1575&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1575&range=01-02 Stats: 38648 lines in 1261 files changed: 15843 ins; 5497 del; 17308 mod Patch: https://git.openjdk.org/jfx/pull/1575.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1575/head:pull/1575 PR: https://git.openjdk.org/jfx/pull/1575 From kcr at openjdk.org Tue Sep 24 15:31:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 15:31:02 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v2] In-Reply-To: References: Message-ID: <5fMbSKb6f1h14T2_dux6dGcBMe9SQrkkW1DcANDZUfo=.d1aca6a3-f9ed-4dcb-bfea-2303d4bb2b47@github.com> On Tue, 24 Sep 2024 14:27:16 GMT, Andy Goryachev wrote: > #1569 has been integrated, we can make the final changes Done. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1575#issuecomment-2371627170 From angorya at openjdk.org Tue Sep 24 15:49:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 24 Sep 2024 15:49:48 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v3] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 15:31:02 GMT, Kevin Rushforth wrote: >> This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). >> >> JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). >> >> While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. >> >> ### Testing instructions >> >> I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. >> >> The default timeout values for test and lifecycle methods can be modified using a gradle property: >> >> * `JUNIT_TEST_TIMEOUT` : default = 120s >> * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s >> >> For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: >> >> >> gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test > > 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 five additional commits since the last revision: > > - throw new AssertionError(ex) --> fail(ex) > - Merge remote-tracking branch 'upstream/master' into 8328629-junit-timeout > - Remove unused sleep method from BehaviorRobotTestBase. > - Fix typo (extra spaces) in system property name > - 8328629: JUnit test without a timeout value can hang indefinitely tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 112: > 110: Thread.sleep(2000); > 111: } catch (Exception e) { > 112: fail(e); something wrong with indent? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1575#discussion_r1773621003 From angorya at openjdk.org Tue Sep 24 15:54:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 24 Sep 2024 15:54:42 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v3] In-Reply-To: References: Message-ID: <0xjVSeGYBz0dhY0hoKe1pCaqvG4GoYYIzEO0UwVXehY=.eafa06e4-ff99-4550-ab14-90c9718a1acd@github.com> On Tue, 24 Sep 2024 15:31:02 GMT, Kevin Rushforth wrote: >> This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). >> >> JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). >> >> While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. >> >> ### Testing instructions >> >> I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. >> >> The default timeout values for test and lifecycle methods can be modified using a gradle property: >> >> * `JUNIT_TEST_TIMEOUT` : default = 120s >> * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s >> >> For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: >> >> >> gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test > > 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 five additional commits since the last revision: > > - throw new AssertionError(ex) --> fail(ex) > - Merge remote-tracking branch 'upstream/master' into 8328629-junit-timeout > - Remove unused sleep method from BehaviorRobotTestBase. > - Fix typo (extra spaces) in system property name > - 8328629: JUnit test without a timeout value can hang indefinitely one minor formatting issue, otherwise looks good. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1575#pullrequestreview-2325714559 From kcr at openjdk.org Tue Sep 24 16:34:21 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 16:34:21 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v4] In-Reply-To: References: Message-ID: > This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). > > JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). > > While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. > > ### Testing instructions > > I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. > > The default timeout values for test and lifecycle methods can be modified using a gradle property: > > * `JUNIT_TEST_TIMEOUT` : default = 120s > * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s > > For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: > > > gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: fix indentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1575/files - new: https://git.openjdk.org/jfx/pull/1575/files/de443509..980c3edc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1575&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1575&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1575.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1575/head:pull/1575 PR: https://git.openjdk.org/jfx/pull/1575 From kcr at openjdk.org Tue Sep 24 16:34:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 16:34:23 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v3] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 15:47:12 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 five additional commits since the last revision: >> >> - throw new AssertionError(ex) --> fail(ex) >> - Merge remote-tracking branch 'upstream/master' into 8328629-junit-timeout >> - Remove unused sleep method from BehaviorRobotTestBase. >> - Fix typo (extra spaces) in system property name >> - 8328629: JUnit test without a timeout value can hang indefinitely > > tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 112: > >> 110: Thread.sleep(2000); >> 111: } catch (Exception e) { >> 112: fail(e); > > something wrong with indent? Good catch. I'll fix. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1575#discussion_r1773682420 From angorya at openjdk.org Tue Sep 24 16:50:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 24 Sep 2024 16:50:41 GMT Subject: RFR: 8328629: JUnit test without a timeout value can hang indefinitely [v4] In-Reply-To: References: Message-ID: <2avi6mgoRbBg3cZ5YooeGcyLNpAFU7hosmmfyom0oYM=.07c657c9-a213-4234-87de-04dd55a3396e@github.com> On Tue, 24 Sep 2024 16:34:21 GMT, Kevin Rushforth wrote: >> This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). >> >> JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). >> >> While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. >> >> ### Testing instructions >> >> I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. >> >> The default timeout values for test and lifecycle methods can be modified using a gradle property: >> >> * `JUNIT_TEST_TIMEOUT` : default = 120s >> * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s >> >> For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: >> >> >> gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > fix indentation Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1575#pullrequestreview-2325848838 From kcr at openjdk.org Tue Sep 24 17:03:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 17:03:46 GMT Subject: Integrated: 8328629: JUnit test without a timeout value can hang indefinitely In-Reply-To: References: Message-ID: On Thu, 19 Sep 2024 14:15:23 GMT, Kevin Rushforth wrote: > This PR adds a default timeout of 120 seconds for JUnit 5 tests that do not have an explicit `@Timeout` on either the methods or the class, and a default timeout of 20 seconds for lifecycle methods (e.g., `@BeforeEach`, `@BeforeAll`, `@AfterEach`, `@AfterAll`). > > JUnit 5 effects its timeout by interrupting the test thread. We have several tests that catch and ignore InterruptedException for sleep or await, so I fixed these tests to throw an error if InterruptedException is caught (they may or may not be a problem, but if any of them can happen in a loop, it would block the timeout from killing the test). > > While testing this, I discovered that by itself, this JUnit 5 timeout is ineffective if the deadlock described in [JDK-8238505](https://bugs.openjdk.org/browse/JDK-8238505) occurs. The reason for this is that the deadlock almost always occurs when called from a shutdown hook (called by `System.exit`), and that prevents the process from exiting even when interrupted by the test runner after the timeout. A separate PR is out for that bug fix. > > ### Testing instructions > > I tested this in connection with PR #1574 / [JDK-8340405](https://bugs.openjdk.org/browse/JDK-8340405) using my [test-timeout-and-shutdown-hang](https://github.com/kevinrushforth/jfx/tree/test-timeout-and-shutdown-hang) branch. That branch has the fixes from both this PR and PR #1574 as well as tests that will hang indefinitely without the fixes and fail due to the expected timeout with the fixes. > > The default timeout values for test and lifecycle methods can be modified using a gradle property: > > * `JUNIT_TEST_TIMEOUT` : default = 120s > * `JUNIT_LIFECYCLE_TIMEOUT` : default = 20s > > For example, to set a timeout of 60 seconds for tests and 15 seconds for lifecycle methods: > > > gradle -PJUNIT_TEST_TIMEOUT=60s -PJUNIT_LIFECYCLE_TIMEOUT=15s test This pull request has now been integrated. Changeset: 29004352 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/29004352006e4d1d01401d658d22a35ae2648de5 Stats: 106 lines in 29 files changed: 69 ins; 14 del; 23 mod 8328629: JUnit test without a timeout value can hang indefinitely Reviewed-by: angorya, arapte, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1575 From thiago.sayao at gmail.com Tue Sep 24 17:10:52 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 24 Sep 2024 14:10:52 -0300 Subject: Possible leak on prism es2 In-Reply-To: References: Message-ID: I might be mistaken, but it seems deleteDrawableInfo is never called. I think it should be called when the platform View is replaced or when the window is closed. Github search for deleteDrawableInfo https://github.com/search?q=repo%3Aopenjdk%2Fjfx%20deleteDrawableInfo&type=code Em ter., 24 de set. de 2024 ?s 09:07, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > While doing some work on replacing GLX with EGL I discovered a possible > leak. > > Running this test: > gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > SetSceneScalingTest > > will result in X11GLDrawable -> nCreateDrawable to be called multiple > times on the same test, while GLDrawable -> deleteDrawableInfo is never > called, generating a leak (I think). > > I can probably fix this, but I still have little knowledge on the es2 > part, so any help would be appreciated. > > -- Thiago. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmeda at openjdk.org Tue Sep 24 17:17:13 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 24 Sep 2024 17:17:13 GMT Subject: [jfx23u] RFR: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 Message-ID: Clean Backport ------------- Commit messages: - Backport bc5adfa9b6f9180eb32930f61e59fdc46a83cb73 Changes: https://git.openjdk.org/jfx23u/pull/22/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=22&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340208 Stats: 596 lines in 103 files changed: 376 ins; 116 del; 104 mod Patch: https://git.openjdk.org/jfx23u/pull/22.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/22/head:pull/22 PR: https://git.openjdk.org/jfx23u/pull/22 From hmeda at openjdk.org Tue Sep 24 17:26:09 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 24 Sep 2024 17:26:09 GMT Subject: [jfx23u] Integrated: 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 17:11:55 GMT, Hima Bindu Meda wrote: > Clean Backport This pull request has now been integrated. Changeset: fa41f904 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx23u/commit/fa41f904fc9e0034d3af4d7b4b4cc5d7ddde3300 Stats: 596 lines in 103 files changed: 376 ins; 116 del; 104 mod 8340208: Additional WebKit 619.1 fixes from WebKitGTK 2.44.4 Backport-of: bc5adfa9b6f9180eb32930f61e59fdc46a83cb73 ------------- PR: https://git.openjdk.org/jfx23u/pull/22 From kcr at openjdk.org Tue Sep 24 17:39:18 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 24 Sep 2024 17:39:18 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX [v3] In-Reply-To: References: Message-ID: > Add the `jdk.jsobject` module to JavaFX. This module is currently delivered by the JDK, but will be terminally-deprecated in JDK 24 by [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530), which is out for review at openjdk/jdk#20555. We therefore plan to start delivering it with JavaFX in JavaFX 24. > > ### Testing scenarios > > Both JDK and JavaFX for some period of time, so we need to test various scenarios. I built and tested this PR branch with each of the following JDKs: > > 1. JDK 23 or earlier (I used the default boot JDK, which is currently JDK 22.0.2); this JDK includes `jdk.jsobject` as a normal, non-upgradable module > 2. A locally-built JDK 24 from my [8311530-depr-jsobject](https://github.com/kevinrushforth/jdk/tree/8311530-depr-jsobject) branch, which has the fix for [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530); this JDK includes `jdk.jsobject` as a terminally-deprecated, upgradable module > 3. A locally-built JDK 24 from my [WIP-rm-jsobject](https://github.com/kevinrushforth/jdk/tree/WIP-rm-jsobject) branch, which removes the `jdk.jsobject` module, and is therefore a prototype of what will happen in JDK 26 (or later) when it is removed from the JDK > > I ran a build and test of JavaFX from this PR branch using each of the above JDKs. All tests pass. > > I then took the JavaFX artifacts built by JDK 1 (matching how we will deliver this in JavaFX 24), and ran the following additional tests, all of which match my expectations: > > * java --module-path=.../jfx/build/sdk/lib without any additional flags (required for JDK 1; recommended for JDK 3)
    RESULT: JDKs 1 and 2 use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > * java --module-path=.../jfx/build/sdk/lib --upgrade-module-path=.../jfx/build/sdk/lib (recommended for JDK 2, OK for 3)
    RESULT: JDK 1 will fail to launch; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with .../jfx/build/jmods ahead of $JAVA_HOME/jmods (recommended for JDKs 2 and 3)
    RESULT: JDK 1 will fail to link; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX > * jlink with $JAVA_HOME/jmods ahead of .../jfx/build/jmods (required for JDK 1)
    RESULT: JDKs 1 and 2 will use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX > > I have not verified the maven artifacts, but they are being generated correctly. 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 10 additional commits since the last revision: - Use --upgrade-module-path when compiling or running tests on JDK 24 or later - Merge branch 'master' into 8337280-jsobject - Update copyright year in settings.gradle - Merge branch 'master' into 8337280-jsobject - Merge branch 'master' into 8337280-jsobject - Merge branch 'master' into 8337280-jsobject - Update copyright years - Merge branch 'master' into 8337280-jsobject - Update to pick up latest version from jdk master - 8337280: Include jdk.jsobject module with JavaFX ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1529/files - new: https://git.openjdk.org/jfx/pull/1529/files/bb9a3b62..2c00deb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1529&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1529&range=01-02 Stats: 47112 lines in 1384 files changed: 22062 ins; 6661 del; 18389 mod Patch: https://git.openjdk.org/jfx/pull/1529.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1529/head:pull/1529 PR: https://git.openjdk.org/jfx/pull/1529 From andy.goryachev at oracle.com Tue Sep 24 18:53:44 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 24 Sep 2024 18:53:44 +0000 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: <4b9071be-a3a8-4be8-ba88-2e5119789810@gmail.com> References: <4b9071be-a3a8-4be8-ba88-2e5119789810@gmail.com> Message-ID: Dear John: Now with the test sprint over, let me try to respond to your earlier questions (sorry for the delay!). > What is the point of TraversalEvent.NODE_TRAVERSED? My understanding it's an alternative to adding a TraversalEngine.TraverseListener in the original implementation. The main purpose, I think, is to notify the control of the fact that its child got focus. You might be right that it might be possible to replace the event by adding a listener to Scene.focusOwnerProperty, though it's likely to complicate the event handling machinery in the skins. > What does it mean if I filter this event? What if I consume it? Current behavior of Skins that depend on it will break. Were there other questions? Please let me know. Allow me to summarize various suggestions and ideas floated during the discussion: Additional problems: * existing problem of consuming events that had no effect on the control(s) * priority of handling e.g. accelerators vs regular key events You proposed an alternative design which consists of * creating a new hierarchy of TraversalEvents * separate KeyEvents and TraversalEvents (Directional and Logical). * redesigning controls and Scene to react to these instead of KeyEvents * add 2 properties to Parent (Directional and Logical) * TraversalPolicy enum { OPEN, CONFINED, CYCLIC, IGNORED } The benefits of this idea are: * ability to completely customize traversal ("crazy custom navigation") * setting of traversal policies with CSS Some additional issues were touched upon during the discussion: * ScrollPane consuming navigational keys * some (ScrollPane, Spinner, TextField) control needlessly consume key events (see also JDK-8320557) * possible accessibility regression with ScrollPane Is this a complete list? Did I miss anything? -andy From: John Hendrikx Date: Thursday, September 19, 2024 at 07:24 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: Re: [External] : Re: Proposal: Focus Traversal API My apologies then, I was a bit impatient. Good luck with the test sprint then! --John On 18/09/2024 17:13, Andy Goryachev wrote: Oh, sorry, I did not mean to ignore your comments. I should have mentioned we are having a bi-annual "test sprint" and work exclusively on the test suite. You made a lot of good comments that require some thought and careful consideration, for which I simply had no spare CPU cycles last week or this week. Sorry, will definitely respond in detail early next week. -andy From: John Hendrikx Date: Tuesday, September 17, 2024 at 23:05 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: Re: [External] : Re: Proposal: Focus Traversal API Andy, As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. --John On 18/09/2024 01:09, Andy Goryachev wrote: Dear John: You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. Thank you -andy From: John Hendrikx Date: Saturday, September 14, 2024 at 09:41 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Proposal: Focus Traversal API Hi Andy, First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. On 14/09/2024 00:17, Andy Goryachev wrote: Dear John, Everyone: Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: 1. move the focus traversal logic away from the components and into the Scene 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents 3. (more) standard policies 4. using CSS (there is of course more topics in your response, but let me start with the 4 above) #1 I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? There's two things here. 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. #2 This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? #3 One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). #4 The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: - I define the container hierarchy (VBox, HBox, which children go where) - I set a style name - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? -- There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. Also I think this can be implemented gradually. Here's a potential plan: 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... Public API: Limited to a new Event 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys Public API: none 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are Public API: none Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. 4. Expose policy property/properties on Parent Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. Public API: new properties on Parent 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. Benefit: less work for control implementors (although they could just "copy" said code) Public API: Maybe some methods in Node, or some kind of static helper. 6. CSS styleable properties If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). Public API: Nothing in Java, but document as CSS properties --John Thank you, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, September 11, 2024 at 19:05 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Focus Traversal API Hi Andy / List, I've given this some thought first, without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ## KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: - OPEN This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: Node from = ... switch (((KeyEvent)event).getCode()) { case UP: FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); event.consume(); break; case DOWN: // or use the convenience method FocusTraversal.traverseDown(from); event.consume(); break; } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: Node from = ... Node result = switch(traversalEvent.getEventType()) { case TraversalEvent.UP -> FocusTraversals.findUp(from); case TraversalEvent.DOWN -> FocusTraversals.findDown(from); // etc } if (result != null) { result.requestFocus(); traversalEvent.consume(); } Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Sep 24 18:57:28 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 24 Sep 2024 18:57:28 +0000 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: I fully agree with Martin here. -andy From: Martin Fox Date: Wednesday, September 18, 2024 at 11:49 To: John Hendrikx Cc: Andy Goryachev , OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API John, Sorry I didn?t respond to this thread earlier. I?ve been looking at the code and bug database trying to work backward to a problem statement. The bug reports cited in the PR are light on details so I?m trying to come up with a more concrete set of use cases to consider. Currently I?m failing to see the benefit of a traversal event model. - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). It doesn?t really matter whether the control is capturing the key event and invoking the traversal engine directly or firing off a TraversalEvent. The problem is that the control is processing the key event in the first place. You?re talking about something that happens before traversal is even initiated. It?s unfortunate that the code snippet in the proposal shows a control doing a direct mapping from KeyCodes to traversal calls. That?s not how the current system is intended to work. There?s already a dispatcher at the Scene level that processes KeyEvents and invokes the traversal machinery so controls should just let the traversal keys bubble up. There are exceptions to this throughout the code which I would like to get a better handle on since I can?t tell if they?re bugs or truly necessary exceptions. Once the system has determined that it?s time for traversal it needs to map from a KeyEvent to a direction and type. I can see where providing a centralized API for doing this could be of benefit but I?m not sure that has anything to do with this PR or the concept of TraversalEvents. This is also a decision made before traversal is initiated. You give some examples of customizing traversal in various ways. From what I can tell all of them can be accomplished using this PR with maybe one exception that I?ll get to when I respond to Andy?s proposal. In other cases I can?t tell if a TraversalEvent would provide a cleaner implementation because I don?t understand how they would work. For example, one could imagine a system where a TraversalEvent is fired by the Scene and expected to bubble back up to the Scene which will then utilize the existing centralized engines to actually perform the traversal. But one could also imagine a system where the Scene fires a TraversalEvent and the nodes act on them directly as it bubbles up. I?m not sure what you have in mind. It would be nice to see some examples of how a TraversalEvent would move through the system in various scenarios particularly when traversing laterally. Martin On Sep 17, 2024, at 11:05?PM, John Hendrikx wrote: Andy, As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. --John On 18/09/2024 01:09, Andy Goryachev wrote: Dear John: You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. Thank you -andy From: John Hendrikx Date: Saturday, September 14, 2024 at 09:41 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Proposal: Focus Traversal API Hi Andy, First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. On 14/09/2024 00:17, Andy Goryachev wrote: Dear John, Everyone: Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: 1. move the focus traversal logic away from the components and into the Scene 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents 3. (more) standard policies 4. using CSS (there is of course more topics in your response, but let me start with the 4 above) #1 I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? There's two things here. 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. #2 This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? #3 One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). #4 The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: - I define the container hierarchy (VBox, HBox, which children go where) - I set a style name - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? -- There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. Also I think this can be implemented gradually. Here's a potential plan: 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... Public API: Limited to a new Event 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys Public API: none 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are Public API: none Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. 4. Expose policy property/properties on Parent Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. Public API: new properties on Parent 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. Benefit: less work for control implementors (although they could just "copy" said code) Public API: Maybe some methods in Node, or some kind of static helper. 6. CSS styleable properties If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). Public API: Nothing in Java, but document as CSS properties --John Thank you, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, September 11, 2024 at 19:05 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Focus Traversal API Hi Andy / List, I've given this some thought first, without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ## KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: - OPEN This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: Node from = ... switch (((KeyEvent)event).getCode()) { case UP: FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); event.consume(); break; case DOWN: // or use the convenience method FocusTraversal.traverseDown(from); event.consume(); break; } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: Node from = ... Node result = switch(traversalEvent.getEventType()) { case TraversalEvent.UP -> FocusTraversals.findUp(from); case TraversalEvent.DOWN -> FocusTraversals.findDown(from); // etc } if (result != null) { result.requestFocus(); traversalEvent.consume(); } Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Sep 24 19:00:40 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 24 Sep 2024 19:00:40 +0000 Subject: How navigation currently works in FX, and an enhancement proposal In-Reply-To: References: <9736d202-94dc-4346-8bb0-6e0fe77c7a26@gmail.com> Message-ID: Chuck: Does it mean you agree in principle with necessity for adding focus traversal methods and ability to install custom traversal policy? Do you think APIs described in the proposal are sufficient to implement the requirements in your app(s)? -andy From: openjfx-dev on behalf of Chuck Davis Date: Thursday, September 19, 2024 at 11:30 To: Cc: openjfx-dev at openjdk.org Subject: Re: How navigation currently works in FX, and an enhancement proposal Focus traversal in JavaFX is one of the two things I miss most about Swing. With Swing we could access the policy and move to the next or previous object programmatically -- a feature that is sadly lacking in FX. For those of us old enough to remember the good old days of character interfaces, hitting the enter key was the way to move to the next input field. I still maintain that feature but I've had to write all the code myself and for each field it has to be hard coded -- a real nuisance and totally unnecessary if we could access the TraversalPolicy and call next() or previous() like we did in Swing. For example, place characters in a TextField and hit the enter key to trigger an event. Execute the method to process the verification, conversion, formatting and then TraversalPolicy.next() places focus on the next input field -- good old efficient input and finger action. No unnecessary and inefficient hand movements. My $.02 on this whole discussion in this and associated threads regarding addressing the FX TraversalPolicy. On Thu, Sep 19, 2024 at 8:39?AM John Hendrikx > wrote: I've been looking into how exactly navigation keys are being used in FX, and who is responsible for handling them: - Controls can choose to install navigational keys directly in their input map (using FocusTraversalInputMap::getFocusTraversalMappings) - Controls can choose to do nothing and leave navigation keys to bubble up to Scene, at which point Scene will act on any unconsumed navigation keys (in the same was as the traversal mappings would) Scene basically is capable of almost all navigation you could possibly want out of the box. Any control that does not install navigation keys, and leaves said keys to bubble up gets navigation for **free**. This is almost all controls in JavaFX, and it makes sense as Controls should not care about navigation, they should only care about key presses that affect them directly. Navigation should be a concern somewhere higher up in the hierarchy. So why do some controls install their own navigation keys? There are two answers: 1. For some controls, navigation is conditional. A Spinner only allows directional navigation for the left/right keys, or up/down keys depending on its orientation. 2. There is an unfortunate choice in ScrollPane that consumes directional keys for scrolling purposes, and so if such keys were left to bubble up, they would not end up at Scene. Any control supporting directional navigation therefore must **specifically** install these bindings directly, even though navigation is not their concern (a Button cares about being pressed, not about activating unrelated controls nearby). The ScrollPane eating directional keys is an odd choice. In order for it to do so one of the following must be true: - A control inside it has focus that should act on directional navigation, but forgot to install navigation bindings (a custom control). Such a control would work perfectly when not part of a ScrollPane (as Scene would then handle directional navigation), but break when placed inside it. Note that all JavaFX controls do this "properly". I couldn't find any controls that would leave directional keys to bubble up for a ScrollPane to consume. - The ScrollPane itself has focus; this can only happen when directly selected with the mouse (or focus traversable is set to true) and no specific control inside the pane was selected. The ScrollPane receives the ":focused" style, clearly indicating that it is the target for keyboard events to the user. In short, ScrollPane is making navigation a lot more complex within FX than it needs to be. Especially custom controls that do not have access (currently) to install navigational bindings will suffer from this, and will have to resort to their own navigation implementation for directional keys when placed inside a ScrollPane. # Proposal I think ScrollPane violates what I think should be a fundamental rule. Keys should only be consumed by what the user perceives as the focused control (ie. the one outlined with a highlighted border), with the only exceptions being short cuts (from a menu) or mnemonics. Containers such controls happen to be placed in should NOT consume key events -- the container is not the control with the focus, and so would confuse the user. Only ScrollPane is violating this currently. Note that if the ScrollPane has focus itself (and it has the :focused highlight) then it is perfectly fine and expected for it to consume keys as much as it wants. This is why I think we should modify ScrollPane to not consume the directional keys, unless it specifically has the focus. All other controls can then remove their navigational bindings and leave them to bubble up to Scene, cleaning up their behaviors so they can focus on other concerns. Custom controls would no longer need to install navigational bindings either, and would not need to worry about being placed inside a ScrollPane and having their directional navigation broken. Optional, but recommended, controls like Spinner should only act on the directional keys intended for them, and leave the ones they can't use to bubble up. So a vertical spinner would consume up/down for changing the spinner value, but would leave left/right untouched for Scene to handle. Controls that install a full set of navigational keys (like Button, ListView and TitledPane) don't need to do so anymore. I think I will file a ticket for this soon, but I'm curious what others think of this analysis. Note that by solving this problem, the need to make navigation functionality available to custom controls severely diminishes as one can simple leave the KeyEvents responsible for standard navigation to bubble up (recommended as this may be different for each platform). --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Sep 24 19:08:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 24 Sep 2024 19:08:43 GMT Subject: Withdrawn: 8314683: TextArea: scroll bar size and content padding In-Reply-To: References: Message-ID: <2zqMzaGGNxQ-UBaQglXNS9yMRunXBFNt_taMWysqmCg=.c79aadf0-aa79-4890-afd7-b421c6f44e9e@github.com> On Fri, 31 May 2024 21:50:08 GMT, Andy Goryachev wrote: > Changing certain ScrollBar, ScrollPane, and TextArea sizes from `em` to `px` in modena.css to make them independent of the font size *in that control*. > > After the change, the UI still looks good which can be tested by scaling default font size in a fairly wide range: > > > .root { -fx-font-size:100%; } > > > Using CSS Playground tool in the Monkey Tester at 50% and 200% font size: > > ![Screenshot 2024-05-31 at 14 48 41](https://github.com/openjdk/jfx/assets/107069028/c41e1500-ccfe-4aa6-b47a-42571f60b335) > > ![Screenshot 2024-05-31 at 14 49 34](https://github.com/openjdk/jfx/assets/107069028/78270097-4ce3-4c3e-8600-aba8d368495c) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1469 From angorya at openjdk.org Tue Sep 24 19:11:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 24 Sep 2024 19:11:07 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v13] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - review comments - fixed directories - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - hide impl. detail - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - removed duplicate files - moved to apps, review comments - bsd license for sample code - fixes and review comments - ... and 11 more: https://git.openjdk.org/jfx/compare/136e69f7...42f84f58 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/ce1b6953..42f84f58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=11-12 Stats: 44704 lines in 1334 files changed: 20866 ins; 5623 del; 18215 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Tue Sep 24 20:05:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 24 Sep 2024 20:05:55 GMT Subject: RFR: 8090456: Focus Management [v3] In-Reply-To: References: Message-ID: > Public APIs for focus traversal and the focus traversal policy: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > This work is loosely based on the patch > https://cr.openjdk.org/~jgiles/8061673/ Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge remote-tracking branch 'origin/master' into 8090456.focus.traversal - Merge remote-tracking branch 'origin/master' into 8090456.focus.traversal - review comments - Merge remote-tracking branch 'origin/master' into 8090456.focus.traversal - review comments part 1 - Merge remote-tracking branch 'origin/master' into 8090456.focus.traversal - Merge remote-tracking branch 'origin/master' into 8090456.focus.traversal - whitespace - 8090456: focus traversal ------------- Changes: https://git.openjdk.org/jfx/pull/1555/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=02 Stats: 3656 lines in 57 files changed: 1603 ins; 1538 del; 515 mod Patch: https://git.openjdk.org/jfx/pull/1555.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1555/head:pull/1555 PR: https://git.openjdk.org/jfx/pull/1555 From angorya at openjdk.org Tue Sep 24 20:14:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 24 Sep 2024 20:14:31 GMT Subject: RFR: 8090456: Focus Management [v4] In-Reply-To: References: Message-ID: > Public APIs for focus traversal and the focus traversal policy: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > This work is loosely based on the patch > https://cr.openjdk.org/~jgiles/8061673/ 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/1555/files - new: https://git.openjdk.org/jfx/pull/1555/files/12a54fee..02a8d261 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1555.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1555/head:pull/1555 PR: https://git.openjdk.org/jfx/pull/1555 From martin at martinfox.com Tue Sep 24 20:29:52 2024 From: martin at martinfox.com (Martin Fox) Date: Tue, 24 Sep 2024 13:29:52 -0700 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: Message-ID: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> Andy, Glad to finally see a proposal for opening up traversal. Long overdue. There?s a case in the current control set that this API doesn?t cover. ToggleButtons intercept the arrow keys so they can implement a cyclic traversal policy among buttons in the ToggleGroup. They don?t assume that their Parent will do this for them. To reproduce this behavior this API would have to be extended so it can first ask the focusOwner where to traverse to before moving on to the Parent. (And looking at the code I think there?s yet another bug where events are consumed when they should not be. Sigh). The proposal doesn?t provide any use cases for the TraversalEvent. It also doesn?t specify the initial target of the event or how it should be handled. I had to look in the sources to see what it?s being used for and that (a) it?s being fired at the new focus owner and (b) it?s a bad idea to consume it. It looks more like information you want to broadcast to a set of listeners rather than a message to be acted on. If nothing else the bounds should be removed from this event since that?s a very specific piece of info that only the ScrollPaneSkin wants. I haven?t mapped out the details but I?m pretty sure it can figure out the bounds itself. This proposal should give some quick background on how traversal key events are handled, specifically that controls should let the key events bubble up to the Scene to invoke traversal. And if the traversal keys are always going to be consumed by the Scene that should also be mentioned. There?s been a few comments suggesting the traversal key events should not be consumed if the focusOwner doesn?t change. Unfortunately that would break Popups which have an, um, interesting event architecture. And I don?t want to introduce yet another instance where events need to be consumed under specific conditions or things break down (I?m currently tracking down bugs where ESCAPE is consumed when it shouldn?t be or not consumed when it should be). We should figure out what these clients need and ensure it?s delivered to them in a reliable way. Perhaps when traversal ends we could fire an event at the Scene with all the details? The sample code is problematic since we really don?t want controls to kick off traversal themselves unless they absolutely have to. That caveat should probably precede the code. If you must provide some sample code please make sure it checks the modifier state on the KeyEvent. (There really should be a central API for mapping a KeyEvent to a TraversalDirection but that would be a different proposal.) If we provide pre-packaged traversal policies we?ll need to provide multiple variants of CYCLIC. A menu bar cycles horizontally with the arrow keys and Tab but not vertically. According to the w3c a toggle button group should cycle with all the arrow keys but not with the Tab key. And there?s probably one or two more combinations in the current control set and w3c accessibility guidelines. Martin > On Sep 24, 2024, at 11:57?AM, Andy Goryachev wrote: > > I fully agree with Martin here. > > -andy > > From: Martin Fox > Date: Wednesday, September 18, 2024 at 11:49 > To: John Hendrikx > Cc: Andy Goryachev , OpenJFX > Subject: Re: [External] : Re: Proposal: Focus Traversal API > > John, > > Sorry I didn?t respond to this thread earlier. I?ve been looking at the code and bug database trying to work backward to a problem statement. The bug reports cited in the PR are light on details so I?m trying to come up with a more concrete set of use cases to consider. > > Currently I?m failing to see the benefit of a traversal event model. > > - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). > > It doesn?t really matter whether the control is capturing the key event and invoking the traversal engine directly or firing off a TraversalEvent. The problem is that the control is processing the key event in the first place. You?re talking about something that happens before traversal is even initiated. > > It?s unfortunate that the code snippet in the proposal shows a control doing a direct mapping from KeyCodes to traversal calls. That?s not how the current system is intended to work. There?s already a dispatcher at the Scene level that processes KeyEvents and invokes the traversal machinery so controls should just let the traversal keys bubble up. There are exceptions to this throughout the code which I would like to get a better handle on since I can?t tell if they?re bugs or truly necessary exceptions. > > Once the system has determined that it?s time for traversal it needs to map from a KeyEvent to a direction and type. I can see where providing a centralized API for doing this could be of benefit but I?m not sure that has anything to do with this PR or the concept of TraversalEvents. This is also a decision made before traversal is initiated. > > You give some examples of customizing traversal in various ways. From what I can tell all of them can be accomplished using this PR with maybe one exception that I?ll get to when I respond to Andy?s proposal. In other cases I can?t tell if a TraversalEvent would provide a cleaner implementation because I don?t understand how they would work. For example, one could imagine a system where a TraversalEvent is fired by the Scene and expected to bubble back up to the Scene which will then utilize the existing centralized engines to actually perform the traversal. But one could also imagine a system where the Scene fires a TraversalEvent and the nodes act on them directly as it bubbles up. I?m not sure what you have in mind. It would be nice to see some examples of how a TraversalEvent would move through the system in various scenarios particularly when traversing laterally. > Martin > > On Sep 17, 2024, at 11:05?PM, John Hendrikx wrote: > > Andy, > > As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. > > --John > > On 18/09/2024 01:09, Andy Goryachev wrote: > Dear John: > > You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: > > 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. > > 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. > > I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. > > Thank you > -andy > > > From: John Hendrikx > Date: Saturday, September 14, 2024 at 09:41 > To: Andy Goryachev , openjfx-dev at openjdk.org > Subject: [External] : Re: Proposal: Focus Traversal API > > Hi Andy, > > First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. > > An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. > > Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. > > On 14/09/2024 00:17, Andy Goryachev wrote: > Dear John, Everyone: > > Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: > > 1. move the focus traversal logic away from the components and into the Scene > 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents > 3. (more) standard policies > 4. using CSS > > (there is of course more topics in your response, but let me start with the 4 above) > > #1 > > I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? > There's two things here. > > 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). > > 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. > > I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. > > Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. > > > #2 > > This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. > I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? > > > #3 > > One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. > Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. > > I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). > > > #4 > > The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. > I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. > > Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: > > - I define the container hierarchy (VBox, HBox, which children go where) > - I set a style name > - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). > > All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? > > -- > > There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. > "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. > > I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. > > This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. > > Also I think this can be implemented gradually. Here's a potential plan: > > 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents > > Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... > > Public API: Limited to a new Event > > 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent > > This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. > > Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys > > Public API: none > > 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) > > Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. > > Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are > > Public API: none > > Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. > > 4. Expose policy property/properties on Parent > > Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. > > Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. > > Public API: new properties on Parent > 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. > > This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. > > Benefit: less work for control implementors (although they could just "copy" said code) > > Public API: Maybe some methods in Node, or some kind of static helper. > > 6. CSS styleable properties > > If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. > > Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). > > Public API: Nothing in Java, but document as CSS properties > > --John > > > Thank you, > -andy > > > > > From: openjfx-dev on behalf of John Hendrikx > Date: Wednesday, September 11, 2024 at 19:05 > To: openjfx-dev at openjdk.org > Subject: Re: Proposal: Focus Traversal API > > Hi Andy / List, > > I've given this some thought first, without looking too much at the proposal. > > In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). > > ## KeyEvent and TraversalEvent separation > > I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. > > This separation of KeyEvents into TraversalEvents achieves the following: > > - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. > > - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. > > - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. > > ## Traversal Policy Properties on Parent > > I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. > > In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). > > These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). > > Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). > > - logicalTraversalPolicy > - directionalTraversalPolicy > > The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: > > - OPEN > > This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. > > - CONFINED > > This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. > > - CYCLIC > > Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. > > - IGNORED > > This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. > > Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. > > ## Use Cases > > 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) > Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. > > 2) User wants to act on Traversal events that the standard policy leaves to bubble up > > Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). > > 3) User wants to do crazy custom navigation > > Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. > > 4) User wants to change what keys are considered navigation keys > > Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event > > 5) User wants to use keys that are considered navigation keys for their own purposes > > Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them > > 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely > > With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. > > ----- > > About the Proposal: > > I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. > > I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. > > Motivation looks okay. > > > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. > > I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. > > About your typical example: > > Node from = ... > switch (((KeyEvent)event).getCode()) { > case UP: > FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); > event.consume(); > break; > case DOWN: > // or use the convenience method > FocusTraversal.traverseDown(from); > event.consume(); > break; > } > > I think this is not a good way to deal with events. > > 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? > > 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. > > 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. > > So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: > > Node from = ... > > Node result = switch(traversalEvent.getEventType()) { > case TraversalEvent.UP -> FocusTraversals.findUp(from); > case TraversalEvent.DOWN -> FocusTraversals.findDown(from); > // etc > } > > if (result != null) { > result.requestFocus(); > traversalEvent.consume(); > } > > Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. > > This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. > > I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > > > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. > > What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. > > --John > > > > > > On 03/09/2024 21:33, Andy Goryachev wrote: > > Dear fellow developers: > > I'd like to propose the public focus traversal API: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > Draft PR: > > https://github.com/openjdk/jfx/pull/1555 > > Your comments and suggestions will be warmly accepted and appreciated. > > Thank you > > -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Tue Sep 24 21:51:14 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 24 Sep 2024 23:51:14 +0200 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: <4b9071be-a3a8-4be8-ba88-2e5119789810@gmail.com> Message-ID: On 24/09/2024 20:53, Andy Goryachev wrote: > > Dear John: > > Now with the test sprint over, let me try to respond to your earlier > questions (sorry for the delay!). > Looks like you guys did a lot of useful work in a short time.? It's good to see many tests being converted. > > > What is the point of TraversalEvent.NODE_TRAVERSED? > > My understanding it's an alternative to adding a > TraversalEngine.TraverseListener in the original implementation. > > The main purpose, I think, is to notify the control of the fact that > its child got focus. > > You might be right that it might be possible to replace the event by > adding a listener to Scene.focusOwnerProperty, though it's likely to > complicate the event handling machinery in the skins. > Yeah, I think this should not be part of the public API if it is to handle some internal Skin problem. Events should be consumable/filterable to prevent some action from occurring.? This Event would make sense if it initiated traversal, but instead only informs about it. > > > What does it mean if I filter this event? What if I consume it? > > Current behavior of Skins that depend on it will break. > > Were there other questions?? Please let me know. > Please have a look at https://bugs.openjdk.org/browse/JDK-8340852 -- I think this should be fixed sooner rather than later, and will probably simplify a traversal API implementation. > > > Allow me to summarize various suggestions and ideas floated during the > discussion: > > Additional problems: > > * existing problem of consuming events that had no effect on the > control(s) > These should be fixed on a case by case basis yes. > > * priority of handling e.g. accelerators vs regular key events > Accelerators are handled by Scene with no way to get in between. That sounds like a different topic altogether, and one I wouldn't be so sure off you should be allowed to get in between.? If there is some kind of prioritized event handler system, then the user could potentially intercept these by installing a handler with a higher priority. Most of the issues I've had with keys being consumed too early is caused by Controls directly installing navigational keys in their input maps, instead of leaving them to bubble up to Scene.? This is fine for controls that have specific navigation needs, but currently all controls do this or they would break when nested inside a ScrollPane (see https://bugs.openjdk.org/browse/JDK-8340852). > You proposed an alternative design which consists of > > * creating a new hierarchy of TraversalEvents > This probably won't work, I was looking for a real purpose for having a TraversalEvent.? I think it would be sufficient to give users tools on Scene level to do the most common navigation options (ie. directional and logical).? Anything more custom just means that user can implement this by doing their own node traversal (there is more than sufficient information there to implement custom traversal strategies, beyond those that we wish to provide out of the box with a simple focusNext/Previous/Up/Down/Left/Right API). I've dumbed down my idea to just fixing ScrollPane, and perhaps adding some methods to Scene to trigger directional/logical navigation.? That should solve most concerns, with the left over niche cases probably being so specific that it would require scanning the Scene graph to find what Node you'd want to focus... > The benefits of this idea are: > > * ability to completely customize traversal ("crazy custom navigation") > We don't need this, you can already do whatever crazy custom navigation you want, we just need the standard navigation to be available easily (and if ScrollPane bug is solved, then you get that completely free from Scene for your custom control).? More complex navigation can be handled by calling methods on Scene in handlers. For example, here is a simple navigation method that you can implement yourself in current FX: /** * Focuses the first focusable node under the given node. * * @paramnode a {@link Node}or child of the given node to give focus. * @returntrueif focus was given, otherwise false */ publicstaticbooleanfocus(Node node) { if(node instanceofParent p) { for(Node child : p.getChildrenUnmodifiable()) { if(focus(child)) { returntrue; } } } if(node.isFocusTraversable() && !node.isDisabled() && node.isVisible()) { node.requestFocus(); returntrue; } returnfalse; } Ideally, you shouldn't need to do yourself. It should be sufficient to call a `focusNext` type method. > > * setting of traversal policies with CSS > I think this would be highly useful and so must be considered to be a possibility.? As explained in one of my replies, JavaFX CSS is not limited to visual policies. > > Some additional issues were touched upon during the discussion: > > * ScrollPane consuming navigational keys > That's the big one IMHO.? Fix that, and most problems are already solved; the traversal API should see how much is still needed **after** that problem is fixed. > > * some (ScrollPane, Spinner, TextField) ?control needlessly consume > key events (see also _JDK-8320557)_ > Yeah, we should just make PR's for those and get them fixed. > > * possible accessibility regression with ScrollPane > I didn't see this anywhere. > Is this a complete list?? Did I miss anything? > Looks pretty complete. Thanks. --John > -andy > > *From: *John Hendrikx > *Date: *Thursday, September 19, 2024 at 07:24 > *To: *Andy Goryachev , > openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: Proposal: Focus Traversal API > > My apologies then, I was a bit impatient.? Good luck with the test > sprint then! > > --John > > On 18/09/2024 17:13, Andy Goryachev wrote: > > Oh, sorry, I did not mean to ignore your comments. ?I should have > mentioned we are having a bi-annual "test sprint" and work > exclusively on the test suite.? You made a lot of good comments > that require some thought and careful consideration, for which I > simply had no spare CPU cycles last week or this week.? Sorry, > will definitely respond in detail early next week. > > -andy > > *From: *John Hendrikx > > *Date: *Tuesday, September 17, 2024 at 23:05 > *To: *Andy Goryachev > , openjfx-dev at openjdk.org > > *Subject: *Re: [External] : Re: Proposal: Focus Traversal API > > Andy, > > As you're not responding to any of the suggestions or any of my > questions, but are only re-iterating points that I believe are not > going to be a benefit to the long term viability of FX, I see no > point in continuing the discussion further. > > --John > > On 18/09/2024 01:09, Andy Goryachev wrote: > > Dear John: > > You do bring a lot of good points, no doubt.? And I do agree > with a lot of the suggestion, but I still want to emphasize > two points: > > 1. The backward compatibility should not be dismissed that > easily.? There is a number of existing applications out there > and we do not want to break them. Whether the behavior is > specified or not is irrelevant, we do not want to cause mayhem > from the customers and developers alike whose keyboard > navigation suddenly changed. > > 2. I question the cost benefit analysis of the redesign idea.? > While I agree with you that it might help with some unusual > cases, the overall benefit is rather limited.? The benefit of > the proposed solution is, in my opinion, far greater: it > allows for custom traversal policies (a feature that has been > requested multiple times) and enables focus traversal from > custom components, something of a lesser value, but still > important.? Exposing the existing APIs is a relatively cheap > solution that will give us two features at nearly zero cost.? > On the other hand, I doubt that our team, or yourself, are > willing commit substantial development effort to redesign the > thing to use events.? Which brings me to the choice I > mentioned earlier: realistically, we have a choice of > providing two requested features soon, or never. > > I would also encourage other members of the development > community to voice their opinion on the subject, perhaps there > is something else we can do to move forward. > > Thank you > > -andy > > *From: *John Hendrikx > > *Date: *Saturday, September 14, 2024 at 09:41 > *To: *Andy Goryachev > , openjfx-dev at openjdk.org > > *Subject: *[External] : Re: Proposal: Focus Traversal API > > Hi Andy, > > First let me say that when it comes to designing an API, you > really need to take the time to think the solution through.? > The current internal solution was probably kept internal for > exactly that reason, insufficient time to work out the kinks > and look into alternatives. > > An API is almost impossible to change later, so the general > rule is that if you're not sure about an API, then its better > to have no API.? This is why I think it is important that we > first look for what the API should look like, then worry about > how this can be fitted onto JavaFX.? Making concessions > related to the current implementation before having a clear > idea of how the API should preferably work is not part of > that.? You start making concessions only when it turns out the > preferred design would encounter unresolvable problems in the > current implementation. > > Since I think there is very little public API related to focus > traversal, nor is there any specification of how it currently > works, I think we have a lot of room to maneuver.? This is why > I think we should first reach a consensus on the API, then > look how it can be fitted on top of FX.? Sometimes a well > thought out API also is a natural fit, and may be easier to > migrate to than you think. > > On 14/09/2024 00:17, Andy Goryachev wrote: > > Dear John, Everyone: > > Thank you for a thoughtful response!? Some of the ideas > you described definitely deserve further consideration.? > If I were to summarize: > > 1. move the focus traversal logic away from the components > and into the Scene > > 2. re-implement focus traversal through TraversalEvents > rather than responding directly to KeyEvents > > 3. (more) standard policies > > 4. using CSS > > (there is of course more topics in your response, but let > me start with the 4 above) > > #1 > > I generally like this idea.? In some sense it is already > how things work internally, but without the ability to > customize that (i.e. by introducing custom traversal keys, > or removing existing ones).? The downside is substantial: > not only we'd need to re-design the whole of the focus > traversal, but also rework the existing control's > behaviors.? Did I mention the risk of regression, given > the absence of comprehensive behavioral tests? > > There's two things here. > > 1. There is no need to re-design the whole focus traversal.? > The old internal system can be gradually replaced (it works by > directly consuming KeyEvents after all). > > 2. Regression.? When nothing is specified, and the fact that > controls **ought** to work like other common controls in > different UI toolkits, is it a regression when focus traversal > works the same as those other platforms, even if it may be a > regression from the point of view of FX?? For example, a > Spinner will currently react to any mouse key, where as other > common toolkits only react to the left mouse button.? Is it a > regression if FX is adjusted to also only react to the left > mouse button?? It's not specified anywhere. > > I think we have sufficient space to maneuver here as long as > we are not making focus traversal completely different from > how it commonly works in UI's. > > Can there be regressions versus the current (unspecified) > implementation?? Sure, there can be.? Is that necessarily > bad?? That depends.? If the new focus traversal works like it > does on all other toolkits, then no, it is more of a bug fix.? > Did we break something with the new implementation?? That's > always possible, but will then be fixed as soon as it is reported. > > #2 > > This may or may not be an integral part of #1.? > Potentially, it allows for injection of events by the > application code, as well as simplifies creation of > complex custom controls.? The latter becomes possible with > the original proposal, so net benefit is limited to the > first part, I think. > > I think TraversalEvents are quite central to making this an > API that will really stand the test of time.? It leverages the > existing event system, giving you all the power that comes > with it.? You did not answer my question about the > TraversalEvents in your design.? Why are the Events when they > can't be triggered, filtered or?consumed? > > #3 > > One obvious possibility is to enable creation of a simple > policy based on a list of Nodes.? I must mention one use > case that is impossible to cover with pre-defined policy > is one where navigation depends on some state.? Such a > policy must be implemented programmatically.? I think one > property should be sufficient - I am strongly against > adding two properties here. > > Programmatic escapes can always be achieved by responding > directly to a TraversalEvent.? I think however this should be > a rare case, and standard policies should really cover almost > all use cases.? It may be a gap that should be investigated, > and the API adjusted for (usually the "exceptions" are well > worth looking into to see if with a tweak they can't become > "standard").? As for being "strongly against" having two > properties -- that's an odd stance to take without motivating > it.? It could also be rolled into "one" where the Policy is a > record with the two values, but I think we're getting ahead of > ourselves here.? First the API, then the implementation. > > I do think however there is great value in having the Logical > and Directional navigation split.? Often you'll only want to > replace one of these with a custom policy (or a different > standard policy), so that the other navigation method can be > used to escape the control.? For example, a Toolbar could be > tabbed in an out of (using Logical navigation) while the > Directional navigation is cyclic (and thus can't be used to > escape the control's context). > > #4 > > The idea of using CSS to specify traversal policy seems > wrong to me: the CSS defines the presentation aspects > (styles) rather than behavioral ones. I know it is > possible to set custom skins and the corresponding > behavior via CSS, and we know why (skins define the > appearance), but we should not go beyond that, in my opinion. > > I see no problem styling such properties.? They're FX > properties, and it would be very convenient to style them to > globally alter how focus works, instead of having to rely on, > say, Builders or Factories for controls where traversal > policies can be applied.? There are also already properties > that don't only influence the look of controls.? "-fx-skin" > being the most obvious one, but there is also > "-fx-focus-traversable", "-fx-context-menu-enabled", > "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", > "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", > "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and > probably more.? Aside from "-fx-skin" none of these properties > have a visual impact, but instead alter behavior. > > Note: I'm not saying this needs to be there immediately.? I > just want to make sure we're not closing off this direction, > as again, it would be a huge hassle to do this > programmatically.? In "code" the only things I usually do on > my controls are the following: > > - I define the container hierarchy (VBox, HBox, which children > go where) > - I set a style name > - I set anything that unfortunately cannot be CSS styled > (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid > sizes, etc, things that are clearly "visual" but still can't > be styled). > > All the rest I don't touch, or want to touch.? Having to > select a traversal policy for every control of type X I create > is just cumbersome and unnecessary.? There will be a call then > to set this "globally", and then there will be the question, > do we make something custom with many limitations because it > doesn't fit our conceptions of what (FX) CSS is for (ie, > not?style, but only?*visual* style) or do we just expose these > properties as Styleable?leveraging an existing powerful system > with almost zero effort? > > -- > > There is one more aspect of the problem that I think we > should consider.? The current proposal does not change the > implementation in any material way, nor does it change the > behavior, thus can be done quickly.? The benefit everyone > gets from it is ability to trigger focus traversal and to > control it via custom policies.? Any other solution will > require resources and the bandwidth we currently don't > have, which means the /probability/ of it being added to > FX is virtually zero.? Let me emphasize, I am not against > attempting to discuss or implement the best possible > solution, but we should be aware of the limitations of the > reality we live in. > > "Quickly" and API's are incompatible with each other.? There > is nothing worse than exposing an API quickly, which then > becomes a burden on the system -- I think the current CSS API > is a prime example of where "quickly" has gone wrong, costing > us tremendous amounts of effort to make even minor changes to it. > > I urge you to ignore the current implementation, think > thoroughly how (in an ideal world) you would want such an API > to work (from a user perspective, not from an implementor's > perspective) and only then see how this could be made to fit > into JavaFX. > > This is exactly what I did.? I did not look at the > implementation, although I'm aware of some of it.? I looked at > how I as a user of FX am building applications, the struggles > I have?with it currently, (with controls for example "eating" > KeyEvents), and how I would like to be able to adjust focus > traversal. Do I want to respond to "KeyCode.LEFT" or do I want > to respond to "TraversalEvent.LEFT"? Do I also need to respond > to "KeyCode.NUM_PAD_LEFT"?? These things should be abstracted, > and preferably I should just be able to choose from common > navigation standards.? And when I do want to change such a > standard, in 99% of the cases that will be the case for all > similar controls in my application.? How do I do such things > currently if I want to change something for all controls in my > application?? I use CSS. > > Also I think this can be implemented gradually.? Here's a > potential plan: > > 1. Have Scene listen to unused KeyEvents and translate them to > TraversalEvents > > Benefit:?gives custom controls a way to respond to keyboard > based navigation in a platform agnostic way; this probably > already removes the biggest roadblock for custom controls... > > Public API: Limited to a new Event > > 2. Start converting existing controls to listen to > TraversalEvent instead of KeyEvent > > This hits a lot of controls, but should be relatively easy to > do, and it can be all kept internal for now.? It can be done > in a few batches. > > Benefit: for each control converted, user can now > programmatically trigger focus changes, and by overriding > things at Scene level can completely change navigation keys > > Public API: none > > 3. Implement a number of standard policies internally (OPEN, > CONFINED, CYCLIC, IGNORED) > > Convert any controls that could use these as their default, > removing any custom logic if it happens to match one of the > defaults. > > Benefit: less code to maintain and debug, gives us experience > with which policies make sense and where the gaps are > > Public API: none > > Order: It is possible to do this before 2, and so some of the > control conversions could just consist of removing their > custom logic, and selecting a standard policy. > > 4. Expose policy property/properties?on Parent > > Any controls that are not using a custom policy anymore (of > type IGNORED) can now be user adjusted. We don't have to > guarantee that each policy makes sense for each control. > Changing a default IGNORED policy to a standard one will > change the behavior (as intended) but it need not be a > "complete" behavior that users like.? This is not FX's > problem, and can be improved upon later. > > Benefit: users can now change policies on any existing > control, even ones with a custom policy; many of the controls > may support a switch between OPEN, CONFINED and CYCLIC out of > the box. > > Public API: new properties on Parent > > 5. Perhaps expose some helpful tools to calculate the "next" > Node for a given traversal option. > > This can be done at any stage, and can be considered > completely separate.? It is IMHO a relatively low?priority need. > > Benefit: less work for control implementors (although they > could just "copy" said code) > > Public API: Maybe some methods in Node, or some kind of static > helper. > > 6. CSS styleable properties > > If we really want to give power to our users, and impress them > with a flexible focus traversal API, then make these > properties styleable. > > Benefit: allow users to pick any control, and set is policy > globally or within a subset of controls (ie. dialogs, popups, > etc). > > Public API: Nothing in Java, but document as CSS properties > > --John > > Thank you, > > -andy > > *From: *openjfx-dev > on behalf of John > Hendrikx > > *Date: *Wednesday, September 11, 2024 at 19:05 > *To: *openjfx-dev at openjdk.org > > *Subject: *Re: Proposal: Focus Traversal API > > Hi Andy / List, > > I've given this some thought first,?without looking too > much at the proposal. > > In my view, focus traversal should be implemented using > events, and FX should provide standard handling of these > events controlled with properties (potentially even CSS > stylable for easy mass changing of the default navigation > policy). > > ##?KeyEvent and TraversalEvent separation > > I think the cleanest implementation would be to implement > a KeyEvent listener on Scene that takes any unused > KeyEvents, checks if they're considered navigation keys, > and converts these keys to a new type of event, the > TraversalEvent. The TraversalEvent is then fired at the > original target. The TraversalEvent is structured into > Directional and Logical sub types, and has leaf types > UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS.? Scene is the > logical place to handle this as without a Scene there is > no focus owner, and so there is no point in doing focus > traversal. > > This separation of KeyEvents into TraversalEvents achieves > the following: > > - User can decide to act on **any** key, even navigation > keys, without the system interfering by consuming keys > early, unexpectedly or even consuming these keys without > doing anything (sometimes keys get consumed that don't > actually change focus...).? The navigation keys have many > possible dual purposes, and robbing the user of the > opportunity to use them due to an overzealous component > interpreting them as traversal keys is very annoying.? > Dual purposes include for example cursor control in > TextField/TextArea, Scrollbars, etc.? The user should have > the same control here as these FX controls have. > > - Scene is interpreting the KeyEvents, and this > interpretation is now controllable.? If I want a Toolbar > (or the whole application) to react to WASD navigation > keys, then installing a KeyEvent handler at Scene level or > at any intermediate Parent level that converts WASD to > UP/LEFT/DOWN/RIGHT Traversal events would affect this > change easily. > > - The separation also allows to block Focus Traversal > only, without blocking the actual Keys involved.? If I > want to stop a Toolbar from reacting to LEFT/RIGHT, but I > need those keys higher up in the hierarchy, then I'm > screwed.? With the separation, the key events are > unaffected, and I can block Toolbars from reacting > specifically to traversal events only. > > ## Traversal Policy Properties on Parent > > I think FX should provide several policies out of the box, > based on common navigation patterns.? The goal here is to > have policies in place that cover all use cases in current > FX provided controls.? This will provide a good base that > will cover probably all realistic work loads that custom > controls may have. The goal is not to support every > esoteric form of navigation, instead an escape hatch will > be provided in the form of disabling the standard navigation. > > In order to achieve this, I think Parent should get two > new properties, which control how it will react to > Directional and Logical navigation.? These will have > default values that allow navigation to flow from Node to > Node within a Parent and from Parent to its Parent when > navigation options in a chosen direction are exhausted > within a Parent.? Custom controls like Combo boxes, > Toolbars, Button groups, etc, can change the default > provided by a Parent (similar to how some controls change > the mouse transparent flag default). > > These two properties should cover all realistic needs, and > IMHO should be considered to be CSS stylable in the future > to allow easy changing of default policies of controls > (ie. want all Toolbars to react differently to navigation > keys, then just style the appropriate property for all > toolbars in one go). > > Parent will use these properties to install an event > handler that reacts to TraversalEvents (not KeyEvents).? > This handler can be fully disabled, or overridden (using > setOnTraversalEvent). > > - logicalTraversalPolicy > - directionalTraversalPolicy > > The properties can be set with a value from a > TraversalPolicy enum.? I would suggest the following options: > > - OPEN > > This policy should be the default policy for all Parents.? > It will act and consume a given TraversalEvent only when > there is a suitable target within its hierarchy.? If there > is no suitable target, or the target would remain > unchanged, the event is NOT consumed and left to bubble > up, allowing its parent(s) to act on it instead. > > - CONFINED > > This policy consumes all TraversalEvents, regardless of > whether there is something to navigate to or not.? This > policy is suitable for controls that have some kind of > substructure that we don't want to accidentally exit with > either Directional or Logical navigation.? In most cases, > you only want to set one of the properties to CONFINED as > otherwise there would be no keyboard supported way to exit > your control. This is a suitable policy for say button > groups, toolbars, comboboxes, etc. > > - CYCLIC > > Similar to CONFINED but instead of stopping navigation at > the controls logical boundaries, the navigation wraps > around to the logical start.? For example, when were > positioned on the right most button in a button group, > pressing RIGHT again would navigate to the left most button. > > - IGNORED > > This is similar to the mouseTransparent property, and > basically leaves the TraversalEvent to bubble up.? This > policy allows you to completely disable directional and/or > logical navigation for a control. Useful if you want to > install your own handler (the escape hatch) but still want > to keep either the default directional or logical navigation. > > Possible other options for this enum could include a > version that consumes all TraversalEvents (BLOCK) but I > don't see a use for it at the moment.? There may also be > variants of CONFINED and CYCLIC that make an exception for > cases where there is only a single choice available.? A > ButtonGroup for example may want to react differently > depending on whether it has 0, 1 or more buttons. Whether > these should be enshrined with a custom enum value, or > perhaps a flag, or just left up to a custom implementation > is something we'd need to decide still. > > ## Use Cases > > 1) User wants to change the behavior of a control from its > default to something else (ie. a Control that is CYCLIC > can be changed to OPEN or CONFINED) > > Just call the setters with the appropriate preferred > policy.? This could be done in CSS for maximum convenience > to enable a global change of all similar controls. > > 2) User wants to act on Traversal events that the standard > policy leaves to bubble up > > Just install a Traversal event handler either on the > control or on its parent (depending on their needs).? A > potential action to an unused Traversal event could be to > close a Dialog/Toast popup, or a custom behavior like > selecting the first/last item or next/previous row (ie. if > I press "RIGHT" and there is no further right item, a user > could decide to have this select the first item again in > the current Row or the first item in the **next** Row). > > 3) User wants to do crazy custom navigation > > Set both policies to?IGNORED, then install your own event > handler (or use the setOnTraversalHandler to completely > override the handler).? Now react on the Traversal events, > consuming them at will and changing focus to whatever > control you desire. > > 4) User wants to change what keys are considered > navigation keys > > Install event handler on Scene (or any intermediate > Parent) for KeyEvents, interpret WASD keys as > UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal > event > > 5) User wants to use keys that are considered navigation > keys for their own purposes > > Just install a KeyEvent handler as usual, without having > to worry that Skins/Controls eat these events before you > can get to them > > 6) User wants to stop a control from reacting to traversal > events, without filtering navigation keys completely > > With the separation of unconsumed KeyEvents into > TraversalEvents, a user can now block only the latter to > achieve this goal without having to blanket block certain > KeyEvents. > > ----- > > About the Proposal: > > I think the Goals are fine as stated, although I think we > differ on what the Traversal events signify. > > I think CSS support should be considered a possible future > goal.? The proposal should therefore take into account > that we may want to offer this in the future. > > Motivation looks okay. > > > The focus traversal is provided by the FocusTraversal > class which offers static methods for traversing focus in > various directions, determined by the TraversalDirection enum. > > I think these methods don't need to be exposed with a good > selection of standard TraversalPolicy options.? After all, > there are only so many ways that you can do a sensible > navigation action without confusing the user, and > therefore I think these policy options will cover 99% of > the use cases already.? For the left over 1% we could > **consider** providing these focus traversal functions as > a separate public API, but I would have them return the > Node they would suggest, and leave the final decision to > call requestFocus up to the caller.? Initially however I > think there is already more than enough power for custom > implementations to listen to Traversal events and do their > own custom navigation.? If it is not similar to one of the > standard navigation options, the traverseUp/Down functions > won't be of much use then anyway. > > About your typical example: > > ??? Node from = ... > ??? switch (((KeyEvent)event).getCode()) { > ??? case UP: > FocusTraversal.traverse(from, TraversalDirection.UP, > TraversalMethod.KEY); > ??????? event.consume(); > ??????? break; > ??? case DOWN: > ??????? // or use the convenience method > FocusTraversal.traverseDown(from); > ??????? event.consume(); > ??????? break; > ??? } > > I think this is not a good way to deal with events. > > 1) The event is consumed regardless of the outcome of > traverse.? What if focus did not change? Should the event > be consumed? > > 2) This is consuming KeyEvents directly, robbing the user > of the opportunity to act on keys considered "special" by FX. > > 3) This code is not only consuming KeyEvents directly, but > also deciding what keys are navigation keys. > > So I think this example?code should be different. However, > first I expect that in most cases, configuring a different > traversal policy on your Parent subclass will already be > sufficient in almost all cases (especially if we look at > FX current controls and see if the suggested policies > would cover those use cases).? So this code will almost > never be needed.? However, in the event that you need > something even more specific, you may consider handling > Traversal events directly.? In which case the code should > IMHO look something like this: > > ??? Node from = ... > > ??? Node result = switch(traversalEvent.getEventType()) { > ?? ?? case TraversalEvent.UP -> FocusTraversals.findUp(from); > ?? ?? case TraversalEvent.DOWN -> > FocusTraversals.findDown(from); > ? ? ? // etc > ?? } > > ??? if (result != null) { > result.requestFocus(); > traversalEvent.consume(); > ??? } > > Note that the above code leaves the final decision to call > requestFocus up to the caller.? It also allows the caller > to distinguish between the case where there is no suitable > Node in the indicated direction and act accordingly. > > This allows it to?NOT consume the event if it prefers its > Parent to handle it (if the control doesn't want CYCLIC or > CONFINED style navigation).? It also allows it to further > scrutinize the suggested Node, and if it decides it does > not like it (due to some property or CSS style or > whatever) it may follow up with another findXXX call or > some other option to pick the Node it wants.? It also > allows (in the case of no Node being found) to pick its > own preferred Node in those cases.? In other words, it is > just far more flexible. > > I'm not sure yet where to place these static helper > methods (if we decide to expose them at all initially), or > even if they should be static. Given that its first > parameter is always a Node, a non-static location for them > could simply be on Node itself, in which case the calling > convention would become "Node result? = > from.findTraversableUp()" (suggested name only) > > > Focus traversals generate a new type of event, > encapsulated by the class TraversalEvent which extends > javafx.event.Event, using the event type > TraversalEvent.NODE_TRAVERSED. > > What is the point of this event?? If you want to know that > focus changed, you can add a listener to > Scene.focusOwnerProperty. What does it mean if I filter > this event?? What if I consume it?? I don't think this > should be an event at all, unless implemented as I > suggested above, where consuming/filtering/bubbling can be > used to control how controls will react to navigation events. > > --John > > On 03/09/2024 21:33, Andy Goryachev wrote: > > Dear fellow developers: > > I'd like to propose the public focus traversal API: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > > Draft PR: > > https://github.com/openjdk/jfx/pull/1555 > > > Your comments and suggestions will be warmly accepted > and appreciated. > > Thank you > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Tue Sep 24 21:53:12 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 24 Sep 2024 23:53:12 +0200 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> References: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> Message-ID: On 24/09/2024 22:29, Martin Fox wrote: > This proposal should give some quick background on how traversal key > events are handled, specifically that controls should let the key > events bubble up to the Scene to invoke traversal. And if the > traversal keys are always going to be consumed by the Scene that > should also be mentioned. > > There?s been a few comments suggesting the traversal key events should > not be consumed if the focusOwner doesn?t change. Almost all controls that do their own focus traversal handling do so because they may get stuck in a ScrollPane which consumes keys without having the focus.? If this is fixed, keys can just bubble up to the Scene for handling.? See https://bugs.openjdk.org/browse/JDK-8340852 > Unfortunately that would break Popups which have an, um, interesting > event architecture. If keys bubble up to Scene, as they should in most cases, then there is no further bubbling anyway, so consumed or unconsumed would be irrelevant. --John From andy.goryachev at oracle.com Tue Sep 24 21:58:19 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 24 Sep 2024 21:58:19 +0000 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> References: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> Message-ID: Dear Martin: Thank you for a very thoughtful and constructive response! It will take me some time to digest, but I do want to mention some thoughts I had while listening to the discussion earlier. 1. TraversalEvent You are right, it appears there might be a few or no use cases for this event as far as app code is concerned. Looking at the code, it was a replacement for internal TraversalEngine.TraverseListener utilized by several skins. It might be possible to remove it and instead rely on listening to Scene.focusOwnerProperty, at the expense of complicating the skins. Is this a good idea? Will removing the event make it more difficult to write a custom component/skin? 2. The fact that some policies depend on the state of the control basically negates the idea of standard set of policies encoded in an enum. 3. Controls may need to intercept traversal keys and fire off the traversal, for example, TAB on a read-only TextArea should traverse, but should insert the tab character into the editable TextArea. (I would imagine this can be also implemented by not consuming events if they effect no change in the control, but that is a different story). 4. It might be possible for controls like ToggleButton to set its own traversal policy instead intercepting KeyEvents (which is the current way of dealing with conditional traversal). I would imagine this being done as a separate enhancement though. Thanks, -andy From: Martin Fox Date: Tuesday, September 24, 2024 at 13:30 To: Andy Goryachev Cc: OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API Andy, Glad to finally see a proposal for opening up traversal. Long overdue. There?s a case in the current control set that this API doesn?t cover. ToggleButtons intercept the arrow keys so they can implement a cyclic traversal policy among buttons in the ToggleGroup. They don?t assume that their Parent will do this for them. To reproduce this behavior this API would have to be extended so it can first ask the focusOwner where to traverse to before moving on to the Parent. (And looking at the code I think there?s yet another bug where events are consumed when they should not be. Sigh). The proposal doesn?t provide any use cases for the TraversalEvent. It also doesn?t specify the initial target of the event or how it should be handled. I had to look in the sources to see what it?s being used for and that (a) it?s being fired at the new focus owner and (b) it?s a bad idea to consume it. It looks more like information you want to broadcast to a set of listeners rather than a message to be acted on. If nothing else the bounds should be removed from this event since that?s a very specific piece of info that only the ScrollPaneSkin wants. I haven?t mapped out the details but I?m pretty sure it can figure out the bounds itself. This proposal should give some quick background on how traversal key events are handled, specifically that controls should let the key events bubble up to the Scene to invoke traversal. And if the traversal keys are always going to be consumed by the Scene that should also be mentioned. There?s been a few comments suggesting the traversal key events should not be consumed if the focusOwner doesn?t change. Unfortunately that would break Popups which have an, um, interesting event architecture. And I don?t want to introduce yet another instance where events need to be consumed under specific conditions or things break down (I?m currently tracking down bugs where ESCAPE is consumed when it shouldn?t be or not consumed when it should be). We should figure out what these clients need and ensure it?s delivered to them in a reliable way. Perhaps when traversal ends we could fire an event at the Scene with all the details? The sample code is problematic since we really don?t want controls to kick off traversal themselves unless they absolutely have to. That caveat should probably precede the code. If you must provide some sample code please make sure it checks the modifier state on the KeyEvent. (There really should be a central API for mapping a KeyEvent to a TraversalDirection but that would be a different proposal.) If we provide pre-packaged traversal policies we?ll need to provide multiple variants of CYCLIC. A menu bar cycles horizontally with the arrow keys and Tab but not vertically. According to the w3c a toggle button group should cycle with all the arrow keys but not with the Tab key. And there?s probably one or two more combinations in the current control set and w3c accessibility guidelines. Martin On Sep 24, 2024, at 11:57?AM, Andy Goryachev wrote: I fully agree with Martin here. -andy From: Martin Fox Date: Wednesday, September 18, 2024 at 11:49 To: John Hendrikx Cc: Andy Goryachev , OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API John, Sorry I didn?t respond to this thread earlier. I?ve been looking at the code and bug database trying to work backward to a problem statement. The bug reports cited in the PR are light on details so I?m trying to come up with a more concrete set of use cases to consider. Currently I?m failing to see the benefit of a traversal event model. - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). It doesn?t really matter whether the control is capturing the key event and invoking the traversal engine directly or firing off a TraversalEvent. The problem is that the control is processing the key event in the first place. You?re talking about something that happens before traversal is even initiated. It?s unfortunate that the code snippet in the proposal shows a control doing a direct mapping from KeyCodes to traversal calls. That?s not how the current system is intended to work. There?s already a dispatcher at the Scene level that processes KeyEvents and invokes the traversal machinery so controls should just let the traversal keys bubble up. There are exceptions to this throughout the code which I would like to get a better handle on since I can?t tell if they?re bugs or truly necessary exceptions. Once the system has determined that it?s time for traversal it needs to map from a KeyEvent to a direction and type. I can see where providing a centralized API for doing this could be of benefit but I?m not sure that has anything to do with this PR or the concept of TraversalEvents. This is also a decision made before traversal is initiated. You give some examples of customizing traversal in various ways. From what I can tell all of them can be accomplished using this PR with maybe one exception that I?ll get to when I respond to Andy?s proposal. In other cases I can?t tell if a TraversalEvent would provide a cleaner implementation because I don?t understand how they would work. For example, one could imagine a system where a TraversalEvent is fired by the Scene and expected to bubble back up to the Scene which will then utilize the existing centralized engines to actually perform the traversal. But one could also imagine a system where the Scene fires a TraversalEvent and the nodes act on them directly as it bubbles up. I?m not sure what you have in mind. It would be nice to see some examples of how a TraversalEvent would move through the system in various scenarios particularly when traversing laterally. Martin On Sep 17, 2024, at 11:05?PM, John Hendrikx wrote: Andy, As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. --John On 18/09/2024 01:09, Andy Goryachev wrote: Dear John: You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. Thank you -andy From: John Hendrikx Date: Saturday, September 14, 2024 at 09:41 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Proposal: Focus Traversal API Hi Andy, First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. On 14/09/2024 00:17, Andy Goryachev wrote: Dear John, Everyone: Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: 1. move the focus traversal logic away from the components and into the Scene 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents 3. (more) standard policies 4. using CSS (there is of course more topics in your response, but let me start with the 4 above) #1 I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? There's two things here. 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. #2 This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? #3 One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). #4 The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: - I define the container hierarchy (VBox, HBox, which children go where) - I set a style name - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? -- There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. Also I think this can be implemented gradually. Here's a potential plan: 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... Public API: Limited to a new Event 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys Public API: none 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are Public API: none Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. 4. Expose policy property/properties on Parent Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. Public API: new properties on Parent 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. Benefit: less work for control implementors (although they could just "copy" said code) Public API: Maybe some methods in Node, or some kind of static helper. 6. CSS styleable properties If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). Public API: Nothing in Java, but document as CSS properties --John Thank you, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, September 11, 2024 at 19:05 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Focus Traversal API Hi Andy / List, I've given this some thought first, without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ## KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: - OPEN This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: Node from = ... switch (((KeyEvent)event).getCode()) { case UP: FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); event.consume(); break; case DOWN: // or use the convenience method FocusTraversal.traverseDown(from); event.consume(); break; } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: Node from = ... Node result = switch(traversalEvent.getEventType()) { case TraversalEvent.UP -> FocusTraversals.findUp(from); case TraversalEvent.DOWN -> FocusTraversals.findDown(from); // etc } if (result != null) { result.requestFocus(); traversalEvent.consume(); } Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Wed Sep 25 02:16:27 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 25 Sep 2024 02:16:27 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v40] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: - fix merge conflicts - Merge branch 'master' into feature/interpolatable # Conflicts: # modules/javafx.graphics/src/test/java/test/javafx/geometry/InsetsTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundFillTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundImageTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundPositionTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundSizeTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderStrokeTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderWidthsTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/ColorTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/ImagePatternTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/LinearGradientTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/RadialGradientTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopListTest.java # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopTest.java - javadoc change - javadoc change - javadoc change - small doc changes, copyright header - fixed a bug when null values require discrete transitions - javadoc changes - added tests - javadoc changes - ... and 53 more: https://git.openjdk.org/jfx/compare/29004352...3027caa5 ------------- Changes: https://git.openjdk.org/jfx/pull/1522/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=39 Stats: 6710 lines in 77 files changed: 5843 ins; 371 del; 496 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From arapte at openjdk.org Wed Sep 25 12:48:16 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 25 Sep 2024 12:48:16 GMT Subject: RFR: 8297072: Provide gradle option to test a previously built SDK [v3] In-Reply-To: References: Message-ID: > #### Requirement: > We want to be able to test a JavaFX SDK built somewhere else other than on current machine or current repo on same machine. Which means we should be able to run the unit and system tests with a different JavaFX SDK. > > #### Change: > ##### Run tests using a specified JavaFX SDK: > - Introduce a property `TEST_JAVAFX_SDK_PATH` that points to the JavaFX SDK which was built elsewhere. > - Modify the paths generated by build.gradle to point to the path sepcified by `TEST_JAVAFX_SDK_PATH` > - When a `TEST_JAVAFX_SDK_PATH` is specified `-PTEST_ONLY=true` must also be specified. > > ##### Generate the JavaFX SDK bundle > - Generate the minimal JavaFX SDK bundle that is required to run the tests: We require content of the _build/sdk_ and _build/shims_ directories to achieve the same. > > > #### Verification: > ##### With a single machine: > 1. Create two local copies JavaFX repo, [repo1, repo2] > 2. Build sdk and shims in repo1. `gradle sdk shims` > 3. In repo2, run different tests as, >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**repo1/build** :base:test > 4. In repo1 run `gradle all` > 5. `javafx-sdk-shims.zip` file would be created under repo1/build. unzip it any `unzip-path` on machine > 6. In repo2, run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test > > ##### With 2 machines. > 1. Run `gradle all` on a machine1 > 2. Move build/javafx-sdk-shims.zip to machine2 and unzip to any `unzip-path` > 3. Run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test > > > #### Additional changes: > Additionally we observed that three unit tests failed because they access a specific path. A path that would no exists when JavaFX SDK is not built. > 1. Controls test: test.javafx.scene.control.ControlTest.testRT18097 > It required path: modules/javafx.controls/build/classes/java/main/javafx.controls/javafx > It is fixed by change on line 2811 > > 2. Graphics test: test.javafx.css.CssMetaDataTest.testRT18097 > It required path: modules/javafx.graphics/build/classes/java/main/javafx.graphics/javafx > It is fixed by change on line 2722 > > 3. Base test: test.com.sun.javafx.runtime.VersionInfoTest > It required path: build/module-lib/javafx.properties > VersionInfoTest is specific to the local build of JavaFX. So, It can be safely excluded when TEST_JAVAFX_SDK_PATH is specified. > It is fixed by change on line 2304 t... Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: task for creating run args when -PTEST-ONLY=true ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1577/files - new: https://git.openjdk.org/jfx/pull/1577/files/fca8e6b1..d49a12fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1577&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1577&range=01-02 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1577.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1577/head:pull/1577 PR: https://git.openjdk.org/jfx/pull/1577 From arapte at openjdk.org Wed Sep 25 13:04:44 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 25 Sep 2024 13:04:44 GMT Subject: RFR: 8297072: Provide gradle option to test a previously built SDK [v2] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 13:10:22 GMT, Kevin Rushforth wrote: >> Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision: >> >> - disable swt compileTestJava >> - review: rename vars > > Looks good. I ran the following in a clean repo1 and all tests passes: > > > gradle -PTEST_ONLY=true -PFULL_TEST=true -PTEST_SDK_PATH=repo2/build test @kevinrushforth As you guided offline. Updated the PR to provide an option to generate the run.args and compile.args in cases when needed. Kindly re-review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1577#issuecomment-2374026749 From jcorvel at gmail.com Wed Sep 25 14:12:33 2024 From: jcorvel at gmail.com (Johan Corveleyn) Date: Wed, 25 Sep 2024 16:12:33 +0200 Subject: Dead keys followed by space In-Reply-To: References: Message-ID: Hi Thiago, Thank you for your answer. I am experiencing this issue on Windows (Windows 10 and 11). Now, it dawns on me that: - I have a QWERTY keyboard (standard US layout). - I have my keyboard layout setting in Windows configured to "US International". That way the keys for ~, ^, ', " become "dead keys" (waiting for next keystroke). - If I change my keyboard layout setting to "US" then I can't reproduce anymore because those keystrokes no longer act like dead keys (~, ^, ... immediately give that character). I don't know how this is handled on Linux or Mac. Do they also have something like a "US International" keyboard layout setting so ^ becomes a dead key? Or does it work differently if I want to type ? or ?, or a standalone ^? I'm not sure what you mean by disabling IME or how to know that it's enabled. Can I enable/disable this programmatically in JavaFX? Or is this an OS keyboard layout setting (anyway: just having a standard "US input" makes this non reproducible because I can no longer type dead keys)? If you have a keyboard input with dead keys it's super easy to test this with a simple program like: [[[ public class DeadKeysFX extends Application { @Override public void start(Stage stage) { TextField textField = new TextField(); Scene scene = new Scene(textField); stage.setScene(scene); stage.show(); } } ]]] Just type ^+ and see whether you get one or two characters. In all non-JavaFX programs (including Java Swing) I get a single '^'. In JavaFX I get a '^ '. -- Johan On Tue, Sep 24, 2024 at 5:16?PM Thiago Milczarek Say?o wrote: > > Hi Johan, > > It might vary be platform. Which one are you using? (Windows, Mac, Linux). > > Try disabling IME (Input Method Editor) and see it it works. > > - Thiago > > Em ter., 24 de set. de 2024 11:51, Johan Corveleyn escreveu: >> >> Hi, >> >> (This is my first post here, hope I'm following the right path) >> >> It seems JavaFX TextFields (and friends) do not automatically convert >> + into simply . They make it into >> +, which is very atypical. I would consider >> this behavior a bug, since it is different from any editor I know (and >> makes it very hard to enter a dead key character on its own). We ran >> into this with Java 8, I also reproduced it with openjdk 21 + openjfx >> 23. >> >> For instance if in a JavaFX TextField I type a '^' keystroke, it waits >> for the next keystroke (which is normal since it's a dead key, >> possibly followed by a character on which to put the '^'). But if I >> then type I expect a simple '^' to appear. Instead, in JavaFX, >> '^ ' appears. This does not happen in Swing, nor in any editor or >> shell or ... >> >> Background context: a user of our JavaFX application couldn't >> authenticate with their password (typed in a PasswordField). After an >> awful lot of troubleshooting we found that they used a '^' in their >> password. Of course the user didn't notice that after typing ^+space >> two dots appeared in the PasswordField. Now that user knows they have >> to backspace after typing ^+space ... >> >> I suppose inserting a Swing JPasswordField in our JavaFX app would >> work around this issue, but ... isn't there a better solution? >> Shouldn't this be regarded as a bug? >> >> -- >> Johan From kcr at openjdk.org Wed Sep 25 14:47:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 25 Sep 2024 14:47:43 GMT Subject: RFR: 8297072: Provide gradle option to test a previously built SDK [v3] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 12:48:16 GMT, Ambarish Rapte wrote: >> #### Requirement: >> We want to be able to test a JavaFX SDK built somewhere else other than on current machine or current repo on same machine. Which means we should be able to run the unit and system tests with a different JavaFX SDK. >> >> #### Change: >> ##### Run tests using a specified JavaFX SDK: >> - Introduce a property `TEST_JAVAFX_SDK_PATH` that points to the JavaFX SDK which was built elsewhere. >> - Modify the paths generated by build.gradle to point to the path sepcified by `TEST_JAVAFX_SDK_PATH` >> - When a `TEST_JAVAFX_SDK_PATH` is specified `-PTEST_ONLY=true` must also be specified. >> >> ##### Generate the JavaFX SDK bundle >> - Generate the minimal JavaFX SDK bundle that is required to run the tests: We require content of the _build/sdk_ and _build/shims_ directories to achieve the same. >> >> >> #### Verification: >> ##### With a single machine: >> 1. Create two local copies JavaFX repo, [repo1, repo2] >> 2. Build sdk and shims in repo1. `gradle sdk shims` >> 3. In repo2, run different tests as, >>> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**repo1/build** :base:test >> 4. In repo1 run `gradle all` >> 5. `javafx-sdk-shims.zip` file would be created under repo1/build. unzip it any `unzip-path` on machine >> 6. In repo2, run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >>> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test >> >> ##### With 2 machines. >> 1. Run `gradle all` on a machine1 >> 2. Move build/javafx-sdk-shims.zip to machine2 and unzip to any `unzip-path` >> 3. Run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >>> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test >> >> >> #### Additional changes: >> Additionally we observed that three unit tests failed because they access a specific path. A path that would no exists when JavaFX SDK is not built. >> 1. Controls test: test.javafx.scene.control.ControlTest.testRT18097 >> It required path: modules/javafx.controls/build/classes/java/main/javafx.controls/javafx >> It is fixed by change on line 2811 >> >> 2. Graphics test: test.javafx.css.CssMetaDataTest.testRT18097 >> It required path: modules/javafx.graphics/build/classes/java/main/javafx.graphics/javafx >> It is fixed by change on line 2722 >> >> 3. Base test: test.com.sun.javafx.runtime.VersionInfoTest >> It required path: build/module-lib/javafx.properties >> VersionInfoTest is specific to the local build of JavaFX. So, It can be safely ... > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > task for creating run args when -PTEST-ONLY=true Updated dependency looks good. @lukostyra Can you be the second reviewer? ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1577#pullrequestreview-2328511658 PR Comment: https://git.openjdk.org/jfx/pull/1577#issuecomment-2374307693 From angorya at openjdk.org Wed Sep 25 14:51:50 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 25 Sep 2024 14:51:50 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v40] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 02:16:27 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: > > - fix merge conflicts > - Merge branch 'master' into feature/interpolatable > > # Conflicts: > # modules/javafx.graphics/src/test/java/test/javafx/geometry/InsetsTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundFillTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundImageTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundPositionTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundSizeTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderStrokeTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderWidthsTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/ColorTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/ImagePatternTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/LinearGradientTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/RadialGradientTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopListTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopTest.java > - javadoc change > - javadoc change > - javadoc change > - small doc changes, copyright header > - fixed a bug when null values require discrete transitions > - javadoc changes > - added tests > - javadoc changes > - ... and 53 more: https://git.openjdk.org/jfx/compare/29004352...3027caa5 Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2328528819 From thiago.sayao at gmail.com Wed Sep 25 15:14:52 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 25 Sep 2024 12:14:52 -0300 Subject: Dead keys followed by space In-Reply-To: References: Message-ID: Johan, It's an internal API, but we can use it for testing purposes (I'm not sure if there's a public API for that). SceneHelper.enableInputMethodEvents(scene, false); IME is used for entering complex characters in some languages such as Chinese, Korean, Japanese, etc. On Linux, setting the keyboard to en_US will also add the extra space, except if I choose the en_US with dead keys variation. If you try it on notepad, is it the same behaviour? If not, I think it might be a bug. -- Thiago. Em qua., 25 de set. de 2024 ?s 11:12, Johan Corveleyn escreveu: > Hi Thiago, > > Thank you for your answer. I am experiencing this issue on Windows > (Windows 10 and 11). > > Now, it dawns on me that: > - I have a QWERTY keyboard (standard US layout). > - I have my keyboard layout setting in Windows configured to "US > International". That way the keys for ~, ^, ', " become "dead keys" > (waiting for next keystroke). > - If I change my keyboard layout setting to "US" then I can't > reproduce anymore because those keystrokes no longer act like dead > keys (~, ^, ... immediately give that character). > > I don't know how this is handled on Linux or Mac. Do they also have > something like a "US International" keyboard layout setting so ^ > becomes a dead key? Or does it work differently if I want to type ? or > ?, or a standalone ^? > > I'm not sure what you mean by disabling IME or how to know that it's > enabled. Can I enable/disable this programmatically in JavaFX? Or is > this an OS keyboard layout setting (anyway: just having a standard "US > input" makes this non reproducible because I can no longer type dead > keys)? > > If you have a keyboard input with dead keys it's super easy to test > this with a simple program like: > [[[ > public class DeadKeysFX extends Application { > @Override > public void start(Stage stage) { > TextField textField = new TextField(); > Scene scene = new Scene(textField); > stage.setScene(scene); > stage.show(); > } > } > ]]] > > Just type ^+ and see whether you get one or two characters. In > all non-JavaFX programs (including Java Swing) I get a single '^'. In > JavaFX I get a '^ '. > > -- > Johan > > On Tue, Sep 24, 2024 at 5:16?PM Thiago Milczarek Say?o > wrote: > > > > Hi Johan, > > > > It might vary be platform. Which one are you using? (Windows, Mac, > Linux). > > > > Try disabling IME (Input Method Editor) and see it it works. > > > > - Thiago > > > > Em ter., 24 de set. de 2024 11:51, Johan Corveleyn > escreveu: > >> > >> Hi, > >> > >> (This is my first post here, hope I'm following the right path) > >> > >> It seems JavaFX TextFields (and friends) do not automatically convert > >> + into simply . They make it into > >> +, which is very atypical. I would consider > >> this behavior a bug, since it is different from any editor I know (and > >> makes it very hard to enter a dead key character on its own). We ran > >> into this with Java 8, I also reproduced it with openjdk 21 + openjfx > >> 23. > >> > >> For instance if in a JavaFX TextField I type a '^' keystroke, it waits > >> for the next keystroke (which is normal since it's a dead key, > >> possibly followed by a character on which to put the '^'). But if I > >> then type I expect a simple '^' to appear. Instead, in JavaFX, > >> '^ ' appears. This does not happen in Swing, nor in any editor or > >> shell or ... > >> > >> Background context: a user of our JavaFX application couldn't > >> authenticate with their password (typed in a PasswordField). After an > >> awful lot of troubleshooting we found that they used a '^' in their > >> password. Of course the user didn't notice that after typing ^+space > >> two dots appeared in the PasswordField. Now that user knows they have > >> to backspace after typing ^+space ... > >> > >> I suppose inserting a Swing JPasswordField in our JavaFX app would > >> work around this issue, but ... isn't there a better solution? > >> Shouldn't this be regarded as a bug? > >> > >> -- > >> Johan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Sep 25 15:21:55 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Sep 2024 08:21:55 -0700 Subject: Dead keys followed by space In-Reply-To: References: Message-ID: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> I would not recommend internal APIs, unless someone wants to build JavaFX to help diagnose it. In any case it sounds like Johan has discovered a bug -- at least on Windows -- in the key handler for dead keys. We should test this on macOS and Linux as well. ?-- Kevin On 9/25/2024 8:14 AM, Thiago Milczarek Say?o wrote: > Johan, > > It's an internal API, but we can use it for testing purposes (I'm not > sure if there's a public API for that). > SceneHelper.enableInputMethodEvents(scene, false); > IME is used for entering complex characters in some languages such as > Chinese, Korean, Japanese, etc. > > On Linux, setting the keyboard to en_US will also add the extra space, > except if I choose the en_US with dead keys variation. > > If you try it on notepad, is it the same behaviour? If not, I think it > might be a bug. > > -- Thiago. > > > Em qua., 25 de set. de 2024 ?s 11:12, Johan Corveleyn > escreveu: > > Hi Thiago, > > Thank you for your answer. I am experiencing this issue on Windows > (Windows 10 and 11). > > Now, it dawns on me that: > - I have a QWERTY keyboard (standard US layout). > - I have my keyboard layout setting in Windows configured to "US > International". That way the keys for ~, ^, ', " become "dead keys" > (waiting for next keystroke). > - If I change my keyboard layout setting to "US" then I can't > reproduce anymore because those keystrokes no longer act like dead > keys (~, ^, ... immediately give that character). > > I don't know how this is handled on Linux or Mac. Do they also have > something like a "US International" keyboard layout setting so ^ > becomes a dead key? Or does it work differently if I want to type ? or > ?, or a standalone ^? > > I'm not sure what you mean by disabling IME or how to know that it's > enabled. Can I enable/disable this programmatically in JavaFX? Or is > this an OS keyboard layout setting (anyway: just having a standard "US > input" makes this non reproducible because I can no longer type dead > keys)? > > If you have a keyboard input with dead keys it's super easy to test > this with a simple program like: > [[[ > public class DeadKeysFX extends Application { > ? ? @Override > ? ? public void start(Stage stage) { > ? ? ? ? TextField textField = new TextField(); > ? ? ? ? Scene scene = new Scene(textField); > ? ? ? ? stage.setScene(scene); > ? ? ? ? stage.show(); > ? ? } > } > ]]] > > Just type ^+ and see whether you get one or two characters. In > all non-JavaFX programs (including Java Swing) I get a single '^'. In > JavaFX I get a '^ '. > > -- > Johan > > On Tue, Sep 24, 2024 at 5:16?PM Thiago Milczarek Say?o > wrote: > > > > Hi Johan, > > > > It might vary be platform. Which one are you using? (Windows, > Mac, Linux). > > > > Try disabling IME (Input Method Editor) and see it it works. > > > > - Thiago > > > > Em ter., 24 de set. de 2024 11:51, Johan Corveleyn > escreveu: > >> > >> Hi, > >> > >> (This is my first post here, hope I'm following the right path) > >> > >> It seems JavaFX TextFields (and friends) do not automatically > convert > >> + into simply . They make > it into > >> +, which is very atypical. I would > consider > >> this behavior a bug, since it is different from any editor I > know (and > >> makes it very hard to enter a dead key character on its own). > We ran > >> into this with Java 8, I also reproduced it with openjdk 21 + > openjfx > >> 23. > >> > >> For instance if in a JavaFX TextField I type a '^' keystroke, > it waits > >> for the next keystroke (which is normal since it's a dead key, > >> possibly followed by a character on which to put the '^'). But if I > >> then type I expect a simple '^' to appear. Instead, in > JavaFX, > >> '^ ' appears. This does not happen in Swing, nor in any editor or > >> shell or ... > >> > >> Background context: a user of our JavaFX application couldn't > >> authenticate with their password (typed in a PasswordField). > After an > >> awful lot of troubleshooting we found that they used a '^' in their > >> password. Of course the user didn't notice that after typing > ^+space > >> two dots appeared in the PasswordField. Now that user knows > they have > >> to backspace after typing ^+space ... > >> > >> I suppose inserting a Swing JPasswordField in our JavaFX app would > >> work around this issue, but ... isn't there a better solution? > >> Shouldn't this be regarded as a bug? > >> > >> -- > >> Johan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at martinfox.com Wed Sep 25 16:24:22 2024 From: martin at martinfox.com (Martin Fox) Date: Wed, 25 Sep 2024 09:24:22 -0700 Subject: Dead keys followed by space In-Reply-To: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> References: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> Message-ID: Johan, Thanks for providing all the details. It does sound like a bug. I will take a look. Since this is Windows altering the IME setup probably won?t have any effect. On Mac and Linux dead keys are delivered through the IME pathway and are presented to JavaFX as InputMethod events. On Windows dead keys don?t go through this pathway and are presented as KeyEvents. Martin > On Sep 25, 2024, at 8:21?AM, Kevin Rushforth wrote: > > I would not recommend internal APIs, unless someone wants to build JavaFX to help diagnose it. > > In any case it sounds like Johan has discovered a bug -- at least on Windows -- in the key handler for dead keys. We should test this on macOS and Linux as well. > > -- Kevin > > On 9/25/2024 8:14 AM, Thiago Milczarek Say?o wrote: >> Johan, >> >> It's an internal API, but we can use it for testing purposes (I'm not sure if there's a public API for that). >> SceneHelper.enableInputMethodEvents(scene, false); >> IME is used for entering complex characters in some languages such as Chinese, Korean, Japanese, etc. >> >> On Linux, setting the keyboard to en_US will also add the extra space, except if I choose the en_US with dead keys variation. >> >> If you try it on notepad, is it the same behaviour? If not, I think it might be a bug. >> >> -- Thiago. >> >> >> Em qua., 25 de set. de 2024 ?s 11:12, Johan Corveleyn > escreveu: >>> Hi Thiago, >>> >>> Thank you for your answer. I am experiencing this issue on Windows >>> (Windows 10 and 11). >>> >>> Now, it dawns on me that: >>> - I have a QWERTY keyboard (standard US layout). >>> - I have my keyboard layout setting in Windows configured to "US >>> International". That way the keys for ~, ^, ', " become "dead keys" >>> (waiting for next keystroke). >>> - If I change my keyboard layout setting to "US" then I can't >>> reproduce anymore because those keystrokes no longer act like dead >>> keys (~, ^, ... immediately give that character). >>> >>> I don't know how this is handled on Linux or Mac. Do they also have >>> something like a "US International" keyboard layout setting so ^ >>> becomes a dead key? Or does it work differently if I want to type ? or >>> ?, or a standalone ^? >>> >>> I'm not sure what you mean by disabling IME or how to know that it's >>> enabled. Can I enable/disable this programmatically in JavaFX? Or is >>> this an OS keyboard layout setting (anyway: just having a standard "US >>> input" makes this non reproducible because I can no longer type dead >>> keys)? >>> >>> If you have a keyboard input with dead keys it's super easy to test >>> this with a simple program like: >>> [[[ >>> public class DeadKeysFX extends Application { >>> @Override >>> public void start(Stage stage) { >>> TextField textField = new TextField(); >>> Scene scene = new Scene(textField); >>> stage.setScene(scene); >>> stage.show(); >>> } >>> } >>> ]]] >>> >>> Just type ^+ and see whether you get one or two characters. In >>> all non-JavaFX programs (including Java Swing) I get a single '^'. In >>> JavaFX I get a '^ '. >>> >>> -- >>> Johan >>> >>> On Tue, Sep 24, 2024 at 5:16?PM Thiago Milczarek Say?o >>> > wrote: >>> > >>> > Hi Johan, >>> > >>> > It might vary be platform. Which one are you using? (Windows, Mac, Linux). >>> > >>> > Try disabling IME (Input Method Editor) and see it it works. >>> > >>> > - Thiago >>> > >>> > Em ter., 24 de set. de 2024 11:51, Johan Corveleyn > escreveu: >>> >> >>> >> Hi, >>> >> >>> >> (This is my first post here, hope I'm following the right path) >>> >> >>> >> It seems JavaFX TextFields (and friends) do not automatically convert >>> >> + into simply . They make it into >>> >> +, which is very atypical. I would consider >>> >> this behavior a bug, since it is different from any editor I know (and >>> >> makes it very hard to enter a dead key character on its own). We ran >>> >> into this with Java 8, I also reproduced it with openjdk 21 + openjfx >>> >> 23. >>> >> >>> >> For instance if in a JavaFX TextField I type a '^' keystroke, it waits >>> >> for the next keystroke (which is normal since it's a dead key, >>> >> possibly followed by a character on which to put the '^'). But if I >>> >> then type I expect a simple '^' to appear. Instead, in JavaFX, >>> >> '^ ' appears. This does not happen in Swing, nor in any editor or >>> >> shell or ... >>> >> >>> >> Background context: a user of our JavaFX application couldn't >>> >> authenticate with their password (typed in a PasswordField). After an >>> >> awful lot of troubleshooting we found that they used a '^' in their >>> >> password. Of course the user didn't notice that after typing ^+space >>> >> two dots appeared in the PasswordField. Now that user knows they have >>> >> to backspace after typing ^+space ... >>> >> >>> >> I suppose inserting a Swing JPasswordField in our JavaFX app would >>> >> work around this issue, but ... isn't there a better solution? >>> >> Shouldn't this be regarded as a bug? >>> >> >>> >> -- >>> >> Johan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Wed Sep 25 16:38:39 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 25 Sep 2024 13:38:39 -0300 Subject: Dead keys followed by space In-Reply-To: References: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> Message-ID: Johan, Trust Martin, as I know nothing about Windows :) Sorry for misleading you on the IME subject. Em qua., 25 de set. de 2024 ?s 13:24, Martin Fox escreveu: > Johan, > > Thanks for providing all the details. It does sound like a bug. I will > take a look. > > Since this is Windows altering the IME setup probably won?t have any > effect. On Mac and Linux dead keys are delivered through the IME pathway > and are presented to JavaFX as InputMethod events. On Windows dead keys > don?t go through this pathway and are presented as KeyEvents. > > Martin > > On Sep 25, 2024, at 8:21?AM, Kevin Rushforth > wrote: > > I would not recommend internal APIs, unless someone wants to build JavaFX > to help diagnose it. > > In any case it sounds like Johan has discovered a bug -- at least on > Windows -- in the key handler for dead keys. We should test this on macOS > and Linux as well. > > -- Kevin > > On 9/25/2024 8:14 AM, Thiago Milczarek Say?o wrote: > > Johan, > > It's an internal API, but we can use it for testing purposes (I'm not sure > if there's a public API for that). > SceneHelper.enableInputMethodEvents(scene, false); > IME is used for entering complex characters in some languages such as > Chinese, Korean, Japanese, etc. > > On Linux, setting the keyboard to en_US will also add the extra space, > except if I choose the en_US with dead keys variation. > > If you try it on notepad, is it the same behaviour? If not, I think it > might be a bug. > > -- Thiago. > > > Em qua., 25 de set. de 2024 ?s 11:12, Johan Corveleyn > escreveu: > >> Hi Thiago, >> >> Thank you for your answer. I am experiencing this issue on Windows >> (Windows 10 and 11). >> >> Now, it dawns on me that: >> - I have a QWERTY keyboard (standard US layout). >> - I have my keyboard layout setting in Windows configured to "US >> International". That way the keys for ~, ^, ', " become "dead keys" >> (waiting for next keystroke). >> - If I change my keyboard layout setting to "US" then I can't >> reproduce anymore because those keystrokes no longer act like dead >> keys (~, ^, ... immediately give that character). >> >> I don't know how this is handled on Linux or Mac. Do they also have >> something like a "US International" keyboard layout setting so ^ >> becomes a dead key? Or does it work differently if I want to type ? or >> ?, or a standalone ^? >> >> I'm not sure what you mean by disabling IME or how to know that it's >> enabled. Can I enable/disable this programmatically in JavaFX? Or is >> this an OS keyboard layout setting (anyway: just having a standard "US >> input" makes this non reproducible because I can no longer type dead >> keys)? >> >> If you have a keyboard input with dead keys it's super easy to test >> this with a simple program like: >> [[[ >> public class DeadKeysFX extends Application { >> @Override >> public void start(Stage stage) { >> TextField textField = new TextField(); >> Scene scene = new Scene(textField); >> stage.setScene(scene); >> stage.show(); >> } >> } >> ]]] >> >> Just type ^+ and see whether you get one or two characters. In >> all non-JavaFX programs (including Java Swing) I get a single '^'. In >> JavaFX I get a '^ '. >> >> -- >> Johan >> >> On Tue, Sep 24, 2024 at 5:16?PM Thiago Milczarek Say?o >> wrote: >> > >> > Hi Johan, >> > >> > It might vary be platform. Which one are you using? (Windows, Mac, >> Linux). >> > >> > Try disabling IME (Input Method Editor) and see it it works. >> > >> > - Thiago >> > >> > Em ter., 24 de set. de 2024 11:51, Johan Corveleyn >> escreveu: >> >> >> >> Hi, >> >> >> >> (This is my first post here, hope I'm following the right path) >> >> >> >> It seems JavaFX TextFields (and friends) do not automatically convert >> >> + into simply . They make it into >> >> +, which is very atypical. I would consider >> >> this behavior a bug, since it is different from any editor I know (and >> >> makes it very hard to enter a dead key character on its own). We ran >> >> into this with Java 8, I also reproduced it with openjdk 21 + openjfx >> >> 23. >> >> >> >> For instance if in a JavaFX TextField I type a '^' keystroke, it waits >> >> for the next keystroke (which is normal since it's a dead key, >> >> possibly followed by a character on which to put the '^'). But if I >> >> then type I expect a simple '^' to appear. Instead, in JavaFX, >> >> '^ ' appears. This does not happen in Swing, nor in any editor or >> >> shell or ... >> >> >> >> Background context: a user of our JavaFX application couldn't >> >> authenticate with their password (typed in a PasswordField). After an >> >> awful lot of troubleshooting we found that they used a '^' in their >> >> password. Of course the user didn't notice that after typing ^+space >> >> two dots appeared in the PasswordField. Now that user knows they have >> >> to backspace after typing ^+space ... >> >> >> >> I suppose inserting a Swing JPasswordField in our JavaFX app would >> >> work around this issue, but ... isn't there a better solution? >> >> Shouldn't this be regarded as a bug? >> >> >> >> -- >> >> Johan >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Wed Sep 25 17:29:46 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Wed, 25 Sep 2024 14:29:46 -0300 Subject: About Focus Stealing Prevention on GNOME/Linux Message-ID: Hi, This is just for information, in case someone complains about it. Focus Stealing Prevention currently does affect JavaFX on Linux (on gnome). For example, sometimes an APPLICATION_MODAL error dialog will not get focus, instead, a notification is shown that "Error dialog is ready". This is confusing for users, since the APPLICATION_MODAL will block other windows and at the same time will stay behind, since the focus was "prevented". It's actually hard to simulate, but it does happen. This post explains it with some detail: https://blogs.gnome.org/shell-dev/2024/09/20/understanding-gnome-shells-focus-stealing-prevention/ It might be the case that when the native modality functionality is used, it's taken into account for preventing focus. JavaFX does have native modality implemented, but does not use it (must be a reason). It's on com.sun.glass.ui.Window.enterModal(); -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Sep 25 18:39:45 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 25 Sep 2024 18:39:45 GMT Subject: RFR: 8337280: Include jdk.jsobject module with JavaFX [v3] In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024 17:39:18 GMT, Kevin Rushforth wrote: >> Add the `jdk.jsobject` module to JavaFX. This module is currently delivered by the JDK, but will be terminally-deprecated in JDK 24 by [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530), which is out for review at openjdk/jdk#20555. We therefore plan to start delivering it with JavaFX in JavaFX 24. >> >> ### Testing scenarios >> >> Both JDK and JavaFX for some period of time, so we need to test various scenarios. I built and tested this PR branch with each of the following JDKs: >> >> 1. JDK 23 or earlier (I used the default boot JDK, which is currently JDK 22.0.2); this JDK includes `jdk.jsobject` as a normal, non-upgradable module >> 2. A locally-built JDK 24 from my [8311530-depr-jsobject](https://github.com/kevinrushforth/jdk/tree/8311530-depr-jsobject) branch, which has the fix for [JDK-8311530](https://bugs.openjdk.org/browse/JDK-8311530); this JDK includes `jdk.jsobject` as a terminally-deprecated, upgradable module >> 3. A locally-built JDK 24 from my [WIP-rm-jsobject](https://github.com/kevinrushforth/jdk/tree/WIP-rm-jsobject) branch, which removes the `jdk.jsobject` module, and is therefore a prototype of what will happen in JDK 26 (or later) when it is removed from the JDK >> >> I ran a build and test of JavaFX from this PR branch using each of the above JDKs. All tests pass. >> >> I then took the JavaFX artifacts built by JDK 1 (matching how we will deliver this in JavaFX 24), and ran the following additional tests, all of which match my expectations: >> >> * java --module-path=.../jfx/build/sdk/lib without any additional flags (required for JDK 1; recommended for JDK 3)
    RESULT: JDKs 1 and 2 use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX >> * java --module-path=.../jfx/build/sdk/lib --upgrade-module-path=.../jfx/build/sdk/lib (recommended for JDK 2, OK for 3)
    RESULT: JDK 1 will fail to launch; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX >> * jlink with .../jfx/build/jmods ahead of $JAVA_HOME/jmods (recommended for JDKs 2 and 3)
    RESULT: JDK 1 will fail to link; JDKs 2 and 3 use the `jdk.jsobject` module from JavaFX >> * jlink with $JAVA_HOME/jmods ahead of .../jfx/build/jmods (required for JDK 1)
    RESULT: JDKs 1 and 2 will use the `jdk.jsobject` module from the JDK; JDK 3 uses the `jdk.jsobject` module from JavaFX >> >> I have not verified the maven artifacts, but they are being generated correctly. > > 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 10 additional commits since the last revision: > > - Use --upgrade-module-path when compiling or running tests on JDK 24 or later > - Merge branch 'master' into 8337280-jsobject > - Update copyright year in settings.gradle > - Merge branch 'master' into 8337280-jsobject > - Merge branch 'master' into 8337280-jsobject > - Merge branch 'master' into 8337280-jsobject > - Update copyright years > - Merge branch 'master' into 8337280-jsobject > - Update to pick up latest version from jdk master > - 8337280: Include jdk.jsobject module with JavaFX After merging in the latest master yesterday, I discovered that the recently-enabled javac lint warnings and `-Werror` when compiling the test classes will fail the build with "removal" warnings for those tests that use JSObject, when I run using my JDK 24 build with the patch from openjdk/jdk#20555. This is a good thing, since it means that those tests were not using the version of jdk.jsojbect from JavaFX. This highlights the needs to use `--upgradle-module-path` in our unit tests when running with JDK 24, so I pushed a commit that does that. I'm done with my testing, and will switch to creating the CSRs. Reviewers: @arapte @jaybhaskar ------------- PR Comment: https://git.openjdk.org/jfx/pull/1529#issuecomment-2374880515 From angorya at openjdk.org Wed Sep 25 20:38:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 25 Sep 2024 20:38:16 GMT Subject: RFR: 8090456: Focus Management [v5] In-Reply-To: References: Message-ID: > Public APIs for focus traversal and the focus traversal policy: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > This work is loosely based on the patch > https://cr.openjdk.org/~jgiles/8061673/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: remove bounds ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1555/files - new: https://git.openjdk.org/jfx/pull/1555/files/02a8d261..de70ad46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=03-04 Stats: 51 lines in 5 files changed: 16 ins; 22 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/1555.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1555/head:pull/1555 PR: https://git.openjdk.org/jfx/pull/1555 From angorya at openjdk.org Wed Sep 25 20:45:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 25 Sep 2024 20:45:56 GMT Subject: RFR: 8090456: Focus Management [v6] In-Reply-To: References: Message-ID: <7TL2uHmVXx-lUIHzmzyTH8k6A8Wz_x4YhiwAAQhelbM=.219cfa8d-273b-4515-bea9-3e4604a97a81@github.com> > Public APIs for focus traversal and the focus traversal policy: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > This work is loosely based on the patch > https://cr.openjdk.org/~jgiles/8061673/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1555/files - new: https://git.openjdk.org/jfx/pull/1555/files/de70ad46..98af7a6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=04-05 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1555.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1555/head:pull/1555 PR: https://git.openjdk.org/jfx/pull/1555 From kcr at openjdk.org Wed Sep 25 21:12:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 25 Sep 2024 21:12:55 GMT Subject: RFR: 8340954: Add SECURITY.md file Message-ID: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> A `SECURITY.md` file was recently added to the jdk repo. GitHub will show that policy if you click on the ["Security" tab](https://github.com/openjdk/jdk/security) of the jdk repo -- If you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jdk/security/policy). We need a copy of this file in the jfx repo, so that similarly, you will see the policy if you click on the ["Security" tab](https://github.com/openjdk/jfx/security) of the jfx repo -- if you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jfx/security/policy). The `SECURITY.md` file in this PR is identical to the one in the jdk repo, with "JDK" replaced by "JavaFX" in two places (the section header and the name of the software). See openjdk/jdk#21155 for more details. ------------- Commit messages: - 8340954: Add SECURITY.md file Changes: https://git.openjdk.org/jfx/pull/1578/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1578&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340954 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1578.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1578/head:pull/1578 PR: https://git.openjdk.org/jfx/pull/1578 From angorya at openjdk.org Wed Sep 25 21:21:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 25 Sep 2024 21:21:40 GMT Subject: RFR: 8340954: Add SECURITY.md file In-Reply-To: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> References: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> Message-ID: <_amSq_q6YKxU0hkSljSduv4GzrUS7tKxMCMn-zDdHKE=.66210088-4708-4bf3-93b2-a6051be39e1c@github.com> On Wed, 25 Sep 2024 21:08:41 GMT, Kevin Rushforth wrote: > A `SECURITY.md` file was recently added to the jdk repo. GitHub will show that policy if you click on the ["Security" tab](https://github.com/openjdk/jdk/security) of the jdk repo -- If you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jdk/security/policy). > > We need a copy of this file in the jfx repo, so that similarly, you will see the policy if you click on the ["Security" tab](https://github.com/openjdk/jfx/security) of the jfx repo -- if you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jfx/security/policy). > > The `SECURITY.md` file in this PR is identical to the one in the jdk repo, with "JDK" replaced by "JavaFX" in two places (the section header and the name of the software). > > See openjdk/jdk#21155 for more details. SECURITY.md line 3: > 1: # JavaFX Vulnerabilities > 2: > 3: Please follow the process outlined in the [OpenJDK Vulnerability Policy](https://openjdk.org/groups/vulnerability/report) to disclose vulnerabilities in JavaFX. since FX is not technically a part of JDK, should it point to a separate (new) page instead of https://openjdk.org/groups/vulnerability/report ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1578#discussion_r1776005344 From angorya at openjdk.org Wed Sep 25 21:27:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 25 Sep 2024 21:27:40 GMT Subject: RFR: 8340954: Add SECURITY.md file In-Reply-To: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> References: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> Message-ID: On Wed, 25 Sep 2024 21:08:41 GMT, Kevin Rushforth wrote: > A `SECURITY.md` file was recently added to the jdk repo. GitHub will show that policy if you click on the ["Security" tab](https://github.com/openjdk/jdk/security) of the jdk repo -- If you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jdk/security/policy). > > We need a copy of this file in the jfx repo, so that similarly, you will see the policy if you click on the ["Security" tab](https://github.com/openjdk/jfx/security) of the jfx repo -- if you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jfx/security/policy). > > The `SECURITY.md` file in this PR is identical to the one in the jdk repo, with "JDK" replaced by "JavaFX" in two places (the section header and the name of the software). > > See openjdk/jdk#21155 for more details. Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1578#pullrequestreview-2329565909 From kcr at openjdk.org Wed Sep 25 21:27:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 25 Sep 2024 21:27:41 GMT Subject: RFR: 8340954: Add SECURITY.md file In-Reply-To: <_amSq_q6YKxU0hkSljSduv4GzrUS7tKxMCMn-zDdHKE=.66210088-4708-4bf3-93b2-a6051be39e1c@github.com> References: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> <_amSq_q6YKxU0hkSljSduv4GzrUS7tKxMCMn-zDdHKE=.66210088-4708-4bf3-93b2-a6051be39e1c@github.com> Message-ID: On Wed, 25 Sep 2024 21:19:25 GMT, Andy Goryachev wrote: >> A `SECURITY.md` file was recently added to the jdk repo. GitHub will show that policy if you click on the ["Security" tab](https://github.com/openjdk/jdk/security) of the jdk repo -- If you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jdk/security/policy). >> >> We need a copy of this file in the jfx repo, so that similarly, you will see the policy if you click on the ["Security" tab](https://github.com/openjdk/jfx/security) of the jfx repo -- if you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jfx/security/policy). >> >> The `SECURITY.md` file in this PR is identical to the one in the jdk repo, with "JDK" replaced by "JavaFX" in two places (the section header and the name of the software). >> >> See openjdk/jdk#21155 for more details. > > SECURITY.md line 3: > >> 1: # JavaFX Vulnerabilities >> 2: >> 3: Please follow the process outlined in the [OpenJDK Vulnerability Policy](https://openjdk.org/groups/vulnerability/report) to disclose vulnerabilities in JavaFX. > > since FX is not technically a part of JDK, should it point to a separate (new) page instead of https://openjdk.org/groups/vulnerability/report ? No. JavaFX _is_ part of OpenJDK. It is irrelevant whether or not it happens to be bundled with the JDK. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1578#discussion_r1776009562 From angorya at openjdk.org Wed Sep 25 21:27:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 25 Sep 2024 21:27:41 GMT Subject: RFR: 8340954: Add SECURITY.md file In-Reply-To: References: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> <_amSq_q6YKxU0hkSljSduv4GzrUS7tKxMCMn-zDdHKE=.66210088-4708-4bf3-93b2-a6051be39e1c@github.com> Message-ID: On Wed, 25 Sep 2024 21:24:03 GMT, Kevin Rushforth wrote: >> SECURITY.md line 3: >> >>> 1: # JavaFX Vulnerabilities >>> 2: >>> 3: Please follow the process outlined in the [OpenJDK Vulnerability Policy](https://openjdk.org/groups/vulnerability/report) to disclose vulnerabilities in JavaFX. >> >> since FX is not technically a part of JDK, should it point to a separate (new) page instead of https://openjdk.org/groups/vulnerability/report ? > > No. JavaFX _is_ part of OpenJDK. It is irrelevant whether or not it happens to be bundled with the JDK. +1 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1578#discussion_r1776010566 From mhanl at openjdk.org Wed Sep 25 21:46:44 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 25 Sep 2024 21:46:44 GMT Subject: RFR: 8340954: Add SECURITY.md file In-Reply-To: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> References: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> Message-ID: <1YDpVpc53zFkgCTBRPXFeBNdt3b-bhBJZw2brCZd_-I=.c01e5133-03a1-4f5f-9077-bf5c0446520a@github.com> On Wed, 25 Sep 2024 21:08:41 GMT, Kevin Rushforth wrote: > A `SECURITY.md` file was recently added to the jdk repo. GitHub will show that policy if you click on the ["Security" tab](https://github.com/openjdk/jdk/security) of the jdk repo -- If you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jdk/security/policy). > > We need a copy of this file in the jfx repo, so that similarly, you will see the policy if you click on the ["Security" tab](https://github.com/openjdk/jfx/security) of the jfx repo -- if you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jfx/security/policy). > > The `SECURITY.md` file in this PR is identical to the one in the jdk repo, with "JDK" replaced by "JavaFX" in two places (the section header and the name of the software). > > See openjdk/jdk#21155 for more details. +1, I think this is a good idea for both the JDK and JavaFX, as people who work primarily with Github will immediately find relevant security information in the relevant project. ------------- Marked as reviewed by mhanl (Committer). PR Review: https://git.openjdk.org/jfx/pull/1578#pullrequestreview-2329589712 From martin at martinfox.com Wed Sep 25 23:28:50 2024 From: martin at martinfox.com (Martin Fox) Date: Wed, 25 Sep 2024 16:28:50 -0700 Subject: Dead keys followed by space In-Reply-To: References: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> Message-ID: <8D149CE3-4975-46A8-B615-A27E958E5584@martinfox.com> Johan, I?ve entered a bug, https://bugs.openjdk.org/browse/JDK-8340982. In general if you type a dead key followed by a character that can?t combine with it you get two characters. For example, if you type a dead key circumflex followed by a ?q? you should see ?^q?. The Space character is an exception, on all platforms a dead key followed by a Space should yield just one character. The Windows platform code is mishandling this case. Thanks for bringing this up. Martin > On Sep 25, 2024, at 9:38?AM, Thiago Milczarek Say?o wrote: > > Johan, > > Trust Martin, as I know nothing about Windows :) > Sorry for misleading you on the IME subject. > > Em qua., 25 de set. de 2024 ?s 13:24, Martin Fox > escreveu: >> Johan, >> >> Thanks for providing all the details. It does sound like a bug. I will take a look. >> >> Since this is Windows altering the IME setup probably won?t have any effect. On Mac and Linux dead keys are delivered through the IME pathway and are presented to JavaFX as InputMethod events. On Windows dead keys don?t go through this pathway and are presented as KeyEvents. >> >> Martin >> >>> On Sep 25, 2024, at 8:21?AM, Kevin Rushforth > wrote: >>> >>> I would not recommend internal APIs, unless someone wants to build JavaFX to help diagnose it. >>> >>> In any case it sounds like Johan has discovered a bug -- at least on Windows -- in the key handler for dead keys. We should test this on macOS and Linux as well. >>> >>> -- Kevin >>> >>> On 9/25/2024 8:14 AM, Thiago Milczarek Say?o wrote: >>>> Johan, >>>> >>>> It's an internal API, but we can use it for testing purposes (I'm not sure if there's a public API for that). >>>> SceneHelper.enableInputMethodEvents(scene, false); >>>> IME is used for entering complex characters in some languages such as Chinese, Korean, Japanese, etc. >>>> >>>> On Linux, setting the keyboard to en_US will also add the extra space, except if I choose the en_US with dead keys variation. >>>> >>>> If you try it on notepad, is it the same behaviour? If not, I think it might be a bug. >>>> >>>> -- Thiago. >>>> >>>> >>>> Em qua., 25 de set. de 2024 ?s 11:12, Johan Corveleyn > escreveu: >>>>> Hi Thiago, >>>>> >>>>> Thank you for your answer. I am experiencing this issue on Windows >>>>> (Windows 10 and 11). >>>>> >>>>> Now, it dawns on me that: >>>>> - I have a QWERTY keyboard (standard US layout). >>>>> - I have my keyboard layout setting in Windows configured to "US >>>>> International". That way the keys for ~, ^, ', " become "dead keys" >>>>> (waiting for next keystroke). >>>>> - If I change my keyboard layout setting to "US" then I can't >>>>> reproduce anymore because those keystrokes no longer act like dead >>>>> keys (~, ^, ... immediately give that character). >>>>> >>>>> I don't know how this is handled on Linux or Mac. Do they also have >>>>> something like a "US International" keyboard layout setting so ^ >>>>> becomes a dead key? Or does it work differently if I want to type ? or >>>>> ?, or a standalone ^? >>>>> >>>>> I'm not sure what you mean by disabling IME or how to know that it's >>>>> enabled. Can I enable/disable this programmatically in JavaFX? Or is >>>>> this an OS keyboard layout setting (anyway: just having a standard "US >>>>> input" makes this non reproducible because I can no longer type dead >>>>> keys)? >>>>> >>>>> If you have a keyboard input with dead keys it's super easy to test >>>>> this with a simple program like: >>>>> [[[ >>>>> public class DeadKeysFX extends Application { >>>>> @Override >>>>> public void start(Stage stage) { >>>>> TextField textField = new TextField(); >>>>> Scene scene = new Scene(textField); >>>>> stage.setScene(scene); >>>>> stage.show(); >>>>> } >>>>> } >>>>> ]]] >>>>> >>>>> Just type ^+ and see whether you get one or two characters. In >>>>> all non-JavaFX programs (including Java Swing) I get a single '^'. In >>>>> JavaFX I get a '^ '. >>>>> >>>>> -- >>>>> Johan >>>>> >>>>> On Tue, Sep 24, 2024 at 5:16?PM Thiago Milczarek Say?o >>>>> > wrote: >>>>> > >>>>> > Hi Johan, >>>>> > >>>>> > It might vary be platform. Which one are you using? (Windows, Mac, Linux). >>>>> > >>>>> > Try disabling IME (Input Method Editor) and see it it works. >>>>> > >>>>> > - Thiago >>>>> > >>>>> > Em ter., 24 de set. de 2024 11:51, Johan Corveleyn > escreveu: >>>>> >> >>>>> >> Hi, >>>>> >> >>>>> >> (This is my first post here, hope I'm following the right path) >>>>> >> >>>>> >> It seems JavaFX TextFields (and friends) do not automatically convert >>>>> >> + into simply . They make it into >>>>> >> +, which is very atypical. I would consider >>>>> >> this behavior a bug, since it is different from any editor I know (and >>>>> >> makes it very hard to enter a dead key character on its own). We ran >>>>> >> into this with Java 8, I also reproduced it with openjdk 21 + openjfx >>>>> >> 23. >>>>> >> >>>>> >> For instance if in a JavaFX TextField I type a '^' keystroke, it waits >>>>> >> for the next keystroke (which is normal since it's a dead key, >>>>> >> possibly followed by a character on which to put the '^'). But if I >>>>> >> then type I expect a simple '^' to appear. Instead, in JavaFX, >>>>> >> '^ ' appears. This does not happen in Swing, nor in any editor or >>>>> >> shell or ... >>>>> >> >>>>> >> Background context: a user of our JavaFX application couldn't >>>>> >> authenticate with their password (typed in a PasswordField). After an >>>>> >> awful lot of troubleshooting we found that they used a '^' in their >>>>> >> password. Of course the user didn't notice that after typing ^+space >>>>> >> two dots appeared in the PasswordField. Now that user knows they have >>>>> >> to backspace after typing ^+space ... >>>>> >> >>>>> >> I suppose inserting a Swing JPasswordField in our JavaFX app would >>>>> >> work around this issue, but ... isn't there a better solution? >>>>> >> Shouldn't this be regarded as a bug? >>>>> >> >>>>> >> -- >>>>> >> Johan >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Thu Sep 26 01:48:52 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 26 Sep 2024 01:48:52 GMT Subject: RFR: 8340980: Cannot build on Windows ARM Message-ID: Restored some behavior in genVSproperties that enabled ARM builds and cross-compilation on Windows. Verified that I can build on ARM but have no way of testing other architectures. ------------- Commit messages: - Restored some lost behavior that enabled ARM builds on Windows Changes: https://git.openjdk.org/jfx/pull/1580/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1580&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340980 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1580.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1580/head:pull/1580 PR: https://git.openjdk.org/jfx/pull/1580 From jcorvel at gmail.com Thu Sep 26 08:37:27 2024 From: jcorvel at gmail.com (Johan Corveleyn) Date: Thu, 26 Sep 2024 10:37:27 +0200 Subject: Dead keys followed by space In-Reply-To: References: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> Message-ID: Thanks, and thank you Martin for filing the issue https://bugs.openjdk.org/browse/JDK-8340982. I'll try to create an account on openjdk.org to be able to watch the issue :-). Tangentially: For some reason mails on the openjfx-dev mailinglist coming from martin at martinfox.com are not coming through to me. I only saw this thanks to Thiago's reply below (which prompted me to realize that I have missed Martin's mail). It's in the archives on https://mail.openjdk.org/pipermail/openjfx-dev/2024-September/thread.html alright, which is where I saw Martin's latest reply about filing the issue. It seems mails from mfox at openjdk.org are coming through to me, but from martin at martinfox.com not. Maybe some overzealous filtering by Gmail (not sure whether it's only an issue for me, or also for other gmail users). I'll try to investigate a bit more why gmail seems to be dropping these mails for me :-/. -- Johan On Wed, Sep 25, 2024 at 6:38?PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Johan, > > Trust Martin, as I know nothing about Windows :) > Sorry for misleading you on the IME subject. > > Em qua., 25 de set. de 2024 ?s 13:24, Martin Fox > escreveu: > >> Johan, >> >> Thanks for providing all the details. It does sound like a bug. I will >> take a look. >> >> Since this is Windows altering the IME setup probably won?t have any >> effect. On Mac and Linux dead keys are delivered through the IME pathway >> and are presented to JavaFX as InputMethod events. On Windows dead keys >> don?t go through this pathway and are presented as KeyEvents. >> >> Martin >> >> On Sep 25, 2024, at 8:21?AM, Kevin Rushforth >> wrote: >> >> I would not recommend internal APIs, unless someone wants to build JavaFX >> to help diagnose it. >> >> In any case it sounds like Johan has discovered a bug -- at least on >> Windows -- in the key handler for dead keys. We should test this on macOS >> and Linux as well. >> >> -- Kevin >> >> On 9/25/2024 8:14 AM, Thiago Milczarek Say?o wrote: >> >> Johan, >> >> It's an internal API, but we can use it for testing purposes (I'm not >> sure if there's a public API for that). >> SceneHelper.enableInputMethodEvents(scene, false); >> IME is used for entering complex characters in some languages such as >> Chinese, Korean, Japanese, etc. >> >> On Linux, setting the keyboard to en_US will also add the extra space, >> except if I choose the en_US with dead keys variation. >> >> If you try it on notepad, is it the same behaviour? If not, I think it >> might be a bug. >> >> -- Thiago. >> >> >> Em qua., 25 de set. de 2024 ?s 11:12, Johan Corveleyn >> escreveu: >> >>> Hi Thiago, >>> >>> Thank you for your answer. I am experiencing this issue on Windows >>> (Windows 10 and 11). >>> >>> Now, it dawns on me that: >>> - I have a QWERTY keyboard (standard US layout). >>> - I have my keyboard layout setting in Windows configured to "US >>> International". That way the keys for ~, ^, ', " become "dead keys" >>> (waiting for next keystroke). >>> - If I change my keyboard layout setting to "US" then I can't >>> reproduce anymore because those keystrokes no longer act like dead >>> keys (~, ^, ... immediately give that character). >>> >>> I don't know how this is handled on Linux or Mac. Do they also have >>> something like a "US International" keyboard layout setting so ^ >>> becomes a dead key? Or does it work differently if I want to type ? or >>> ?, or a standalone ^? >>> >>> I'm not sure what you mean by disabling IME or how to know that it's >>> enabled. Can I enable/disable this programmatically in JavaFX? Or is >>> this an OS keyboard layout setting (anyway: just having a standard "US >>> input" makes this non reproducible because I can no longer type dead >>> keys)? >>> >>> If you have a keyboard input with dead keys it's super easy to test >>> this with a simple program like: >>> [[[ >>> public class DeadKeysFX extends Application { >>> @Override >>> public void start(Stage stage) { >>> TextField textField = new TextField(); >>> Scene scene = new Scene(textField); >>> stage.setScene(scene); >>> stage.show(); >>> } >>> } >>> ]]] >>> >>> Just type ^+ and see whether you get one or two characters. In >>> all non-JavaFX programs (including Java Swing) I get a single '^'. In >>> JavaFX I get a '^ '. >>> >>> -- >>> Johan >>> >>> On Tue, Sep 24, 2024 at 5:16?PM Thiago Milczarek Say?o >>> wrote: >>> > >>> > Hi Johan, >>> > >>> > It might vary be platform. Which one are you using? (Windows, Mac, >>> Linux). >>> > >>> > Try disabling IME (Input Method Editor) and see it it works. >>> > >>> > - Thiago >>> > >>> > Em ter., 24 de set. de 2024 11:51, Johan Corveleyn >>> escreveu: >>> >> >>> >> Hi, >>> >> >>> >> (This is my first post here, hope I'm following the right path) >>> >> >>> >> It seems JavaFX TextFields (and friends) do not automatically convert >>> >> + into simply . They make it into >>> >> +, which is very atypical. I would consider >>> >> this behavior a bug, since it is different from any editor I know (and >>> >> makes it very hard to enter a dead key character on its own). We ran >>> >> into this with Java 8, I also reproduced it with openjdk 21 + openjfx >>> >> 23. >>> >> >>> >> For instance if in a JavaFX TextField I type a '^' keystroke, it waits >>> >> for the next keystroke (which is normal since it's a dead key, >>> >> possibly followed by a character on which to put the '^'). But if I >>> >> then type I expect a simple '^' to appear. Instead, in JavaFX, >>> >> '^ ' appears. This does not happen in Swing, nor in any editor or >>> >> shell or ... >>> >> >>> >> Background context: a user of our JavaFX application couldn't >>> >> authenticate with their password (typed in a PasswordField). After an >>> >> awful lot of troubleshooting we found that they used a '^' in their >>> >> password. Of course the user didn't notice that after typing ^+space >>> >> two dots appeared in the PasswordField. Now that user knows they have >>> >> to backspace after typing ^+space ... >>> >> >>> >> I suppose inserting a Swing JPasswordField in our JavaFX app would >>> >> work around this issue, but ... isn't there a better solution? >>> >> Shouldn't this be regarded as a bug? >>> >> >>> >> -- >>> >> Johan >>> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvos at openjdk.org Thu Sep 26 09:56:43 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 26 Sep 2024 09:56:43 GMT Subject: RFR: 8340980: Cannot build on Windows ARM In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 01:45:14 GMT, Martin Fox wrote: > Restored some behavior in genVSproperties that enabled ARM builds and cross-compilation on Windows. Verified that I can build on ARM but have no way of testing other architectures. Thanks for this. @tiainen can you review? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1580#issuecomment-2376485031 From sykora at openjdk.org Thu Sep 26 10:24:41 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Thu, 26 Sep 2024 10:24:41 GMT Subject: RFR: 8340980: Cannot build on Windows ARM In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 01:45:14 GMT, Martin Fox wrote: > Restored some behavior in genVSproperties that enabled ARM builds and cross-compilation on Windows. Verified that I can build on ARM but have no way of testing other architectures. The change looks good to me. I've done a build on our build machine and it still correctly selected the x64 build environment. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1580#pullrequestreview-2330779129 From fkirmaier at openjdk.org Thu Sep 26 10:36:18 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 26 Sep 2024 10:36:18 GMT Subject: RFR: 8341010: JavaFX - TriangleMesh.vertexFormat Property default value is wrong. Message-ID: <8PwzHQYbasTevmCgkAAobfWbsoimHST9ISMdiVZU2EA=.fa854923-b1ea-4e5a-8874-7157e1512e5a@github.com> Fixing the wrong TriangleMesh.vertexFormat property. TriangleMesh.getVertexFormat() and TriangleMesh.vertexProperty().get() initially returned different values, which are now fixed. ------------- Commit messages: - JDK-8341010 Changes: https://git.openjdk.org/jfx/pull/1581/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1581&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341010 Stats: 10 lines in 2 files changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1581.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1581/head:pull/1581 PR: https://git.openjdk.org/jfx/pull/1581 From thiago.sayao at gmail.com Thu Sep 26 11:14:25 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 26 Sep 2024 08:14:25 -0300 Subject: Possible leak on prism es2 In-Reply-To: References: Message-ID: Hi, I'm investigating the code, and for someone not familiar with it, it's very complex. On com.sun.javafx.tk.quantum.WindowStage it will do this when changing scene: if (oldScene != null) { ViewPainter painter = ((ViewScene)oldScene).getPainter(); QuantumRenderer.getInstance().disposePresentable(painter.presentable); // latched on RT } But not when closing the Sage (possible problem #1). When changing scenes, ES2SwapChain dispose will be called: public void dispose() { if (stableBackbuffer != null) { stableBackbuffer.dispose(); stableBackbuffer = null; } } But it does not dispose the drawable that should clear the native struc DrawableInfo created, I think (possible problem #2). Does it make sense? -- Thiago. Em ter., 24 de set. de 2024 ?s 14:10, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > I might be mistaken, but it seems deleteDrawableInfo is never called. > > I think it should be called when the platform View is replaced or when the > window is closed. > > Github search for deleteDrawableInfo > > https://github.com/search?q=repo%3Aopenjdk%2Fjfx%20deleteDrawableInfo&type=code > > Em ter., 24 de set. de 2024 ?s 09:07, Thiago Milczarek Say?o < > thiago.sayao at gmail.com> escreveu: > >> Hi, >> >> While doing some work on replacing GLX with EGL I discovered a possible >> leak. >> >> Running this test: >> gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests >> SetSceneScalingTest >> >> will result in X11GLDrawable -> nCreateDrawable to be called multiple >> times on the same test, while GLDrawable -> deleteDrawableInfo is never >> called, generating a leak (I think). >> >> I can probably fix this, but I still have little knowledge on the es2 >> part, so any help would be appreciated. >> >> -- Thiago. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Sep 26 11:59:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 26 Sep 2024 11:59:38 GMT Subject: RFR: 8340980: Cannot build on Windows ARM In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 01:45:14 GMT, Martin Fox wrote: > Restored some behavior in genVSproperties that enabled ARM builds and cross-compilation on Windows. Verified that I can build on ARM but have no way of testing other architectures. The change looks good to me, and I see a successful GHA build. I'll do a CI build and a local build and then approve if there are no problems. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1580#issuecomment-2376732667 From lkostyra at openjdk.org Thu Sep 26 12:29:44 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 26 Sep 2024 12:29:44 GMT Subject: RFR: 8297072: Provide gradle option to test a previously built SDK [v3] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 12:48:16 GMT, Ambarish Rapte wrote: >> #### Requirement: >> We want to be able to test a JavaFX SDK built somewhere else other than on current machine or current repo on same machine. Which means we should be able to run the unit and system tests with a different JavaFX SDK. >> >> #### Change: >> ##### Run tests using a specified JavaFX SDK: >> - Introduce a property `TEST_JAVAFX_SDK_PATH` that points to the JavaFX SDK which was built elsewhere. >> - Modify the paths generated by build.gradle to point to the path sepcified by `TEST_JAVAFX_SDK_PATH` >> - When a `TEST_JAVAFX_SDK_PATH` is specified `-PTEST_ONLY=true` must also be specified. >> >> ##### Generate the JavaFX SDK bundle >> - Generate the minimal JavaFX SDK bundle that is required to run the tests: We require content of the _build/sdk_ and _build/shims_ directories to achieve the same. >> >> >> #### Verification: >> ##### With a single machine: >> 1. Create two local copies JavaFX repo, [repo1, repo2] >> 2. Build sdk and shims in repo1. `gradle sdk shims` >> 3. In repo2, run different tests as, >>> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**repo1/build** :base:test >> 4. In repo1 run `gradle all` >> 5. `javafx-sdk-shims.zip` file would be created under repo1/build. unzip it any `unzip-path` on machine >> 6. In repo2, run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >>> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test >> >> ##### With 2 machines. >> 1. Run `gradle all` on a machine1 >> 2. Move build/javafx-sdk-shims.zip to machine2 and unzip to any `unzip-path` >> 3. Run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >>> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test >> >> >> #### Additional changes: >> Additionally we observed that three unit tests failed because they access a specific path. A path that would no exists when JavaFX SDK is not built. >> 1. Controls test: test.javafx.scene.control.ControlTest.testRT18097 >> It required path: modules/javafx.controls/build/classes/java/main/javafx.controls/javafx >> It is fixed by change on line 2811 >> >> 2. Graphics test: test.javafx.css.CssMetaDataTest.testRT18097 >> It required path: modules/javafx.graphics/build/classes/java/main/javafx.graphics/javafx >> It is fixed by change on line 2722 >> >> 3. Base test: test.com.sun.javafx.runtime.VersionInfoTest >> It required path: build/module-lib/javafx.properties >> VersionInfoTest is specific to the local build of JavaFX. So, It can be safely ... > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > task for creating run args when -PTEST-ONLY=true LGTM, tested single-machine on Windows with sdk-shims zip exported out. Good work! ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1577#pullrequestreview-2331084280 From kcr at openjdk.org Thu Sep 26 13:35:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 26 Sep 2024 13:35:44 GMT Subject: Integrated: 8340954: Add SECURITY.md file In-Reply-To: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> References: <0T91IdYZFFtOqQdG250EFc9Sm3k51fKN3wM8dgrwPyI=.78824343-69ff-40e6-b560-bf3e9a03788a@github.com> Message-ID: On Wed, 25 Sep 2024 21:08:41 GMT, Kevin Rushforth wrote: > A `SECURITY.md` file was recently added to the jdk repo. GitHub will show that policy if you click on the ["Security" tab](https://github.com/openjdk/jdk/security) of the jdk repo -- If you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jdk/security/policy). > > We need a copy of this file in the jfx repo, so that similarly, you will see the policy if you click on the ["Security" tab](https://github.com/openjdk/jfx/security) of the jfx repo -- if you are logged in, you may need to further click on the ["Policy" tab](https://github.com/openjdk/jfx/security/policy). > > The `SECURITY.md` file in this PR is identical to the one in the jdk repo, with "JDK" replaced by "JavaFX" in two places (the section header and the name of the software). > > See openjdk/jdk#21155 for more details. This pull request has now been integrated. Changeset: 0dd0c794 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/0dd0c794c3b08f816e7618026d5c90deaf952046 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8340954: Add SECURITY.md file Reviewed-by: angorya, mhanl ------------- PR: https://git.openjdk.org/jfx/pull/1578 From tsayao at openjdk.org Thu Sep 26 13:45:51 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 26 Sep 2024 13:45:51 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v25] In-Reply-To: References: Message-ID: On Wed, 21 Aug 2024 09:58:53 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 incrementally with one additional commit since the last revision: > > Remove negative checks Recently on the mail list, a bug was discovered on Windows that when ^ followed by space on a US deadkey keyboard configuration resulted on a ^ followed by a space. It should just output the ^. I tested this on this PR and it works as expected, with US and US with deadkeys. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2377017149 From kcr at openjdk.org Thu Sep 26 14:19:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 26 Sep 2024 14:19:10 GMT Subject: [jfx23u] RFR: 8340954: Add SECURITY.md file Message-ID: Clean backport of new `SECURITY.md` file to the `jfx23u` repo. ------------- Commit messages: - Backport 0dd0c794c3b08f816e7618026d5c90deaf952046 Changes: https://git.openjdk.org/jfx23u/pull/23/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=23&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340954 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx23u/pull/23.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/23/head:pull/23 PR: https://git.openjdk.org/jfx23u/pull/23 From kcr at openjdk.org Thu Sep 26 14:21:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 26 Sep 2024 14:21:43 GMT Subject: [jfx23u] RFR: 8340954: Add SECURITY.md file In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 14:13:40 GMT, Kevin Rushforth wrote: > Clean backport of new `SECURITY.md` file to the `jfx23u` repo. @johanvos Can you approve this? (it doesn't require review, but does require approval) ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/23#issuecomment-2377115668 From codebangusllc at gmail.com Thu Sep 26 14:27:07 2024 From: codebangusllc at gmail.com (David Kopp) Date: Thu, 26 Sep 2024 09:27:07 -0500 Subject: Missing macOS integration points Message-ID: Hello everyone. JavaFX is missing methods that are the equivalent of the macOS integration methods in java.awt.Desktop. I have experimented with calling these methods in a JavaFX application, but they do nothing. Is there any interest in adding something similar to either the HostServices, Platform, or Application classes? My first thought is they should be added to the Application class because they are for the application?s About, Settings and Quit handling. Thanks for your time, David Kopp -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Sep 26 15:26:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 26 Sep 2024 15:26:44 GMT Subject: [jfx23u] Integrated: 8340954: Add SECURITY.md file In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 14:13:40 GMT, Kevin Rushforth wrote: > Clean backport of new `SECURITY.md` file to the `jfx23u` repo. This pull request has now been integrated. Changeset: bd99f722 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx23u/commit/bd99f722effb799ae4b3023264c05b2d0f1361c1 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8340954: Add SECURITY.md file Backport-of: 0dd0c794c3b08f816e7618026d5c90deaf952046 ------------- PR: https://git.openjdk.org/jfx23u/pull/23 From angorya at openjdk.org Thu Sep 26 15:36:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 26 Sep 2024 15:36:02 GMT Subject: RFR: 8090456: Focus Management [v7] In-Reply-To: References: Message-ID: > Public APIs for focus traversal and the focus traversal policy: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > This work is loosely based on the patch > https://cr.openjdk.org/~jgiles/8061673/ Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: removed traversal event ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1555/files - new: https://git.openjdk.org/jfx/pull/1555/files/98af7a6e..d1f3152a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1555&range=05-06 Stats: 234 lines in 7 files changed: 71 ins; 156 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1555.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1555/head:pull/1555 PR: https://git.openjdk.org/jfx/pull/1555 From kcr at openjdk.org Thu Sep 26 16:38:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 26 Sep 2024 16:38:39 GMT Subject: RFR: 8341010: JavaFX - TriangleMesh.vertexFormat Property default value is wrong. In-Reply-To: <8PwzHQYbasTevmCgkAAobfWbsoimHST9ISMdiVZU2EA=.fa854923-b1ea-4e5a-8874-7157e1512e5a@github.com> References: <8PwzHQYbasTevmCgkAAobfWbsoimHST9ISMdiVZU2EA=.fa854923-b1ea-4e5a-8874-7157e1512e5a@github.com> Message-ID: On Thu, 26 Sep 2024 10:30:47 GMT, Florian Kirmaier wrote: > Fixing the wrong TriangleMesh.vertexFormat property. TriangleMesh.getVertexFormat() and TriangleMesh.vertexProperty().get() initially returned different values, which are now fixed. I changed the title to `TriangleMesh.vertexFormat Property default value is wrong` -- can you update the title of this PR to match? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1581#issuecomment-2377440866 From andy.goryachev at oracle.com Thu Sep 26 17:22:18 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 26 Sep 2024 17:22:18 +0000 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> References: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> Message-ID: Dear Martin: Thanks again for the comments! These comments, together with the earlier discussion resulted in one change - removal of TraversalEvent. As you and John pointed out, its intended function was quite limited and also created some potential problems. Please check out updated proposal and the draft PR. Let me respond to the rest of comments and questions: > There?s a case in the current control set that this API doesn?t cover. ToggleButtons intercept the arrow keys so they can implement a cyclic traversal policy among buttons in the ToggleGroup. They don?t assume that their Parent will do this for them. To reproduce this behavior this API would have to be extended so it can first ask the focusOwner where to traverse to before moving on to the Parent. I don't think this is correct. The traversal policy API are sufficient to be able to determine the right node because both parent and the node it wants to traverse from are passed as arguments (i.e. select()). When the policy determines it's time to step out of the control, the policy has findXX() methods. > The sample code is problematic since we really don?t want controls to kick off traversal themselves unless they absolutely have to. That caveat should probably precede the code. If you must provide some sample code please make sure it checks the modifier state on the KeyEvent. (There really should be a central API for mapping a KeyEvent to a TraversalDirection but that would be a different proposal.) And you are right. I've updated the example, but a better solution, in my opinion, would be in the context of the InputMap proposal [0], where KeyBindings do a better job of matching modifiers. > If we provide pre-packaged traversal policies we?ll need to provide multiple variants of CYCLIC. A menu bar cycles horizontally with the arrow keys and Tab but not vertically. According to the w3c a toggle button group should cycle with all the arrow keys but not with the Tab key. And there?s probably one or two more combinations in the current control set and w3c accessibility guidelines. Mapping to specific traversal keys is not a part of this proposal. You are probably right about possibly providing additional policies (one I was thinking about is a policy based on the list of Nodes which basically ensures the NEXT/PREVIOUS order). This can be done as a separate enhancement, as the primary goal right now is to enable the ability to create custom policies. Did I provide satisfactory answers, or there are other things that you find problematic? Thanks, -andy References [0] InputMap https://github.com/andy-goryachev-oracle/Test/tree/main/doc/InputMap From: Martin Fox Date: Tuesday, September 24, 2024 at 13:30 To: Andy Goryachev Cc: OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API Andy, Glad to finally see a proposal for opening up traversal. Long overdue. There?s a case in the current control set that this API doesn?t cover. ToggleButtons intercept the arrow keys so they can implement a cyclic traversal policy among buttons in the ToggleGroup. They don?t assume that their Parent will do this for them. To reproduce this behavior this API would have to be extended so it can first ask the focusOwner where to traverse to before moving on to the Parent. (And looking at the code I think there?s yet another bug where events are consumed when they should not be. Sigh). The proposal doesn?t provide any use cases for the TraversalEvent. It also doesn?t specify the initial target of the event or how it should be handled. I had to look in the sources to see what it?s being used for and that (a) it?s being fired at the new focus owner and (b) it?s a bad idea to consume it. It looks more like information you want to broadcast to a set of listeners rather than a message to be acted on. If nothing else the bounds should be removed from this event since that?s a very specific piece of info that only the ScrollPaneSkin wants. I haven?t mapped out the details but I?m pretty sure it can figure out the bounds itself. This proposal should give some quick background on how traversal key events are handled, specifically that controls should let the key events bubble up to the Scene to invoke traversal. And if the traversal keys are always going to be consumed by the Scene that should also be mentioned. There?s been a few comments suggesting the traversal key events should not be consumed if the focusOwner doesn?t change. Unfortunately that would break Popups which have an, um, interesting event architecture. And I don?t want to introduce yet another instance where events need to be consumed under specific conditions or things break down (I?m currently tracking down bugs where ESCAPE is consumed when it shouldn?t be or not consumed when it should be). We should figure out what these clients need and ensure it?s delivered to them in a reliable way. Perhaps when traversal ends we could fire an event at the Scene with all the details? The sample code is problematic since we really don?t want controls to kick off traversal themselves unless they absolutely have to. That caveat should probably precede the code. If you must provide some sample code please make sure it checks the modifier state on the KeyEvent. (There really should be a central API for mapping a KeyEvent to a TraversalDirection but that would be a different proposal.) If we provide pre-packaged traversal policies we?ll need to provide multiple variants of CYCLIC. A menu bar cycles horizontally with the arrow keys and Tab but not vertically. According to the w3c a toggle button group should cycle with all the arrow keys but not with the Tab key. And there?s probably one or two more combinations in the current control set and w3c accessibility guidelines. Martin On Sep 24, 2024, at 11:57?AM, Andy Goryachev wrote: I fully agree with Martin here. -andy From: Martin Fox Date: Wednesday, September 18, 2024 at 11:49 To: John Hendrikx Cc: Andy Goryachev , OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API John, Sorry I didn?t respond to this thread earlier. I?ve been looking at the code and bug database trying to work backward to a problem statement. The bug reports cited in the PR are light on details so I?m trying to come up with a more concrete set of use cases to consider. Currently I?m failing to see the benefit of a traversal event model. - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). It doesn?t really matter whether the control is capturing the key event and invoking the traversal engine directly or firing off a TraversalEvent. The problem is that the control is processing the key event in the first place. You?re talking about something that happens before traversal is even initiated. It?s unfortunate that the code snippet in the proposal shows a control doing a direct mapping from KeyCodes to traversal calls. That?s not how the current system is intended to work. There?s already a dispatcher at the Scene level that processes KeyEvents and invokes the traversal machinery so controls should just let the traversal keys bubble up. There are exceptions to this throughout the code which I would like to get a better handle on since I can?t tell if they?re bugs or truly necessary exceptions. Once the system has determined that it?s time for traversal it needs to map from a KeyEvent to a direction and type. I can see where providing a centralized API for doing this could be of benefit but I?m not sure that has anything to do with this PR or the concept of TraversalEvents. This is also a decision made before traversal is initiated. You give some examples of customizing traversal in various ways. From what I can tell all of them can be accomplished using this PR with maybe one exception that I?ll get to when I respond to Andy?s proposal. In other cases I can?t tell if a TraversalEvent would provide a cleaner implementation because I don?t understand how they would work. For example, one could imagine a system where a TraversalEvent is fired by the Scene and expected to bubble back up to the Scene which will then utilize the existing centralized engines to actually perform the traversal. But one could also imagine a system where the Scene fires a TraversalEvent and the nodes act on them directly as it bubbles up. I?m not sure what you have in mind. It would be nice to see some examples of how a TraversalEvent would move through the system in various scenarios particularly when traversing laterally. Martin On Sep 17, 2024, at 11:05?PM, John Hendrikx wrote: Andy, As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. --John On 18/09/2024 01:09, Andy Goryachev wrote: Dear John: You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. Thank you -andy From: John Hendrikx Date: Saturday, September 14, 2024 at 09:41 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Proposal: Focus Traversal API Hi Andy, First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. On 14/09/2024 00:17, Andy Goryachev wrote: Dear John, Everyone: Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: 1. move the focus traversal logic away from the components and into the Scene 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents 3. (more) standard policies 4. using CSS (there is of course more topics in your response, but let me start with the 4 above) #1 I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? There's two things here. 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. #2 This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? #3 One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). #4 The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: - I define the container hierarchy (VBox, HBox, which children go where) - I set a style name - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? -- There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. Also I think this can be implemented gradually. Here's a potential plan: 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... Public API: Limited to a new Event 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys Public API: none 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are Public API: none Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. 4. Expose policy property/properties on Parent Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. Public API: new properties on Parent 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. Benefit: less work for control implementors (although they could just "copy" said code) Public API: Maybe some methods in Node, or some kind of static helper. 6. CSS styleable properties If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). Public API: Nothing in Java, but document as CSS properties --John Thank you, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, September 11, 2024 at 19:05 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Focus Traversal API Hi Andy / List, I've given this some thought first, without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ## KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: - OPEN This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: Node from = ... switch (((KeyEvent)event).getCode()) { case UP: FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); event.consume(); break; case DOWN: // or use the convenience method FocusTraversal.traverseDown(from); event.consume(); break; } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: Node from = ... Node result = switch(traversalEvent.getEventType()) { case TraversalEvent.UP -> FocusTraversals.findUp(from); case TraversalEvent.DOWN -> FocusTraversals.findDown(from); // etc } if (result != null) { result.requestFocus(); traversalEvent.consume(); } Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Sep 26 18:42:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 26 Sep 2024 18:42:41 GMT Subject: RFR: 8340980: Cannot build on Windows ARM In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 01:45:14 GMT, Martin Fox wrote: > Restored some behavior in genVSproperties that enabled ARM builds and cross-compilation on Windows. Verified that I can build on ARM but have no way of testing other architectures. Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1580#pullrequestreview-2332087640 From mfox at openjdk.org Thu Sep 26 19:54:41 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 26 Sep 2024 19:54:41 GMT Subject: Integrated: 8340980: Cannot build on Windows ARM In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 01:45:14 GMT, Martin Fox wrote: > Restored some behavior in genVSproperties that enabled ARM builds and cross-compilation on Windows. Verified that I can build on ARM but have no way of testing other architectures. This pull request has now been integrated. Changeset: ecab6b6b Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/ecab6b6b0eab288eff1e13173a79a2fa4f4aca80 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8340980: Cannot build on Windows ARM Reviewed-by: sykora, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1580 From john.hendrikx at gmail.com Thu Sep 26 20:21:27 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 26 Sep 2024 22:21:27 +0200 Subject: Dead keys followed by space In-Reply-To: References: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> Message-ID: <69ab6674-b2fa-421b-a713-bf363f7a7d8d@gmail.com> > For some reason mails on the openjfx-dev mailinglist coming from > martin at martinfox.com are not coming through to me I have the same problem. It sometimes takes a while, and sometimes they never get through :/? It may indeed by Gmail, as I use that as well for the mailinglist. --John On 26/09/2024 10:37, Johan Corveleyn wrote: > Thanks, and thank you Martin for filing the issue > https://bugs.openjdk.org/browse/JDK-8340982. I'll try to create an > account on openjdk.org to be able to watch the > issue :-). > > Tangentially: > For some reason mails on the openjfx-dev mailinglist coming from > martin at martinfox.com are not coming through to me. I only saw this > thanks to Thiago's reply below (which prompted me to realize that I > have missed Martin's mail). It's in the archives on > https://mail.openjdk.org/pipermail/openjfx-dev/2024-September/thread.html > alright, which is where I saw Martin's latest reply about filing the > issue. It seems mails from mfox at openjdk.org are coming through to me, > but from martin at martinfox.com not. Maybe some overzealous filtering by > Gmail (not sure whether it's only an issue for me, or also for other > gmail users). I'll try to investigate a bit more why gmail seems to be > dropping these mails for me :-/. > > -- > Johan > > On Wed, Sep 25, 2024 at 6:38?PM Thiago Milczarek Say?o > wrote: > > Johan, > > Trust Martin, as I know nothing about Windows :) > Sorry for misleading you on the IME subject. > > Em qua., 25 de set. de 2024 ?s 13:24, Martin Fox > escreveu: > > Johan, > > Thanks for providing all the details. It does sound like a > bug. I will take a look. > > Since this is Windows altering the IME setup probably won?t > have any effect. On Mac and Linux dead keys are delivered > through the IME pathway and are presented to JavaFX as > InputMethod events. On Windows dead keys don?t go through this > pathway and are presented as KeyEvents. > > Martin > >> On Sep 25, 2024, at 8:21?AM, Kevin Rushforth >> wrote: >> >> I would not recommend internal APIs, unless someone wants to >> build JavaFX to help diagnose it. >> >> In any case it sounds like Johan has discovered a bug -- at >> least on Windows -- in the key handler for dead keys. We >> should test this on macOS and Linux as well. >> >> ?-- Kevin >> >> On 9/25/2024 8:14 AM, Thiago Milczarek Say?o wrote: >>> Johan, >>> >>> It's an internal API, but we can use it for testing purposes >>> (I'm not sure if there's a public API for that). >>> SceneHelper.enableInputMethodEvents(scene, false); >>> IME is used for entering complex characters in some >>> languages such as Chinese, Korean, Japanese, etc. >>> >>> On Linux, setting the keyboard to en_US will also add the >>> extra space, except if I choose the en_US with dead keys >>> variation. >>> >>> If you try it on notepad, is it the same behaviour? If not, >>> I think it might be a bug. >>> >>> -- Thiago. >>> >>> >>> Em qua., 25 de set. de 2024 ?s 11:12, Johan Corveleyn >>> escreveu: >>> >>> Hi Thiago, >>> >>> Thank you for your answer. I am experiencing this issue >>> on Windows >>> (Windows 10 and 11). >>> >>> Now, it dawns on me that: >>> - I have a QWERTY keyboard (standard US layout). >>> - I have my keyboard layout setting in Windows >>> configured to "US >>> International". That way the keys for ~, ^, ', " become >>> "dead keys" >>> (waiting for next keystroke). >>> - If I change my keyboard layout setting to "US" then I >>> can't >>> reproduce anymore because those keystrokes no longer act >>> like dead >>> keys (~, ^, ... immediately give that character). >>> >>> I don't know how this is handled on Linux or Mac. Do >>> they also have >>> something like a "US International" keyboard layout >>> setting so ^ >>> becomes a dead key? Or does it work differently if I >>> want to type ? or >>> ?, or a standalone ^? >>> >>> I'm not sure what you mean by disabling IME or how to >>> know that it's >>> enabled. Can I enable/disable this programmatically in >>> JavaFX? Or is >>> this an OS keyboard layout setting (anyway: just having >>> a standard "US >>> input" makes this non reproducible because I can no >>> longer type dead >>> keys)? >>> >>> If you have a keyboard input with dead keys it's super >>> easy to test >>> this with a simple program like: >>> [[[ >>> public class DeadKeysFX extends Application { >>> ? ? @Override >>> ? ? public void start(Stage stage) { >>> ? ? ? ? TextField textField = new TextField(); >>> ? ? ? ? Scene scene = new Scene(textField); >>> ? ? ? ? stage.setScene(scene); >>> ? ? ? ? stage.show(); >>> ? ? } >>> } >>> ]]] >>> >>> Just type ^+ and see whether you get one or two >>> characters. In >>> all non-JavaFX programs (including Java Swing) I get a >>> single '^'. In >>> JavaFX I get a '^ '. >>> >>> -- >>> Johan >>> >>> On Tue, Sep 24, 2024 at 5:16?PM Thiago Milczarek Say?o >>> wrote: >>> > >>> > Hi Johan, >>> > >>> > It might vary be platform. Which one are you using? >>> (Windows, Mac, Linux). >>> > >>> > Try disabling IME (Input Method Editor) and see it it >>> works. >>> > >>> > - Thiago >>> > >>> > Em ter., 24 de set. de 2024 11:51, Johan Corveleyn >>> escreveu: >>> >> >>> >> Hi, >>> >> >>> >> (This is my first post here, hope I'm following the >>> right path) >>> >> >>> >> It seems JavaFX TextFields (and friends) do not >>> automatically convert >>> >> + into simply . >>> They make it into >>> >> +, which is very atypical. >>> I would consider >>> >> this behavior a bug, since it is different from any >>> editor I know (and >>> >> makes it very hard to enter a dead key character on >>> its own). We ran >>> >> into this with Java 8, I also reproduced it with >>> openjdk 21 + openjfx >>> >> 23. >>> >> >>> >> For instance if in a JavaFX TextField I type a '^' >>> keystroke, it waits >>> >> for the next keystroke (which is normal since it's a >>> dead key, >>> >> possibly followed by a character on which to put the >>> '^'). But if I >>> >> then type I expect a simple '^' to appear. >>> Instead, in JavaFX, >>> >> '^ ' appears. This does not happen in Swing, nor in >>> any editor or >>> >> shell or ... >>> >> >>> >> Background context: a user of our JavaFX application >>> couldn't >>> >> authenticate with their password (typed in a >>> PasswordField). After an >>> >> awful lot of troubleshooting we found that they used >>> a '^' in their >>> >> password. Of course the user didn't notice that after >>> typing ^+space >>> >> two dots appeared in the PasswordField. Now that user >>> knows they have >>> >> to backspace after typing ^+space ... >>> >> >>> >> I suppose inserting a Swing JPasswordField in our >>> JavaFX app would >>> >> work around this issue, but ... isn't there a better >>> solution? >>> >> Shouldn't this be regarded as a bug? >>> >> >>> >> -- >>> >> Johan >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Thu Sep 26 20:31:39 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Thu, 26 Sep 2024 22:31:39 +0200 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> Message-ID: On 24/09/2024 23:58, Andy Goryachev wrote: > > Dear Martin: > > Thank you for a very thoughtful and constructive response!? It will > take me some time to digest, but I do want to mention some thoughts I > had while listening to the discussion earlier. > > 1. TraversalEvent > > You are right, it appears there might be a few or no use cases for > this event as far as app code is concerned.? Looking at the code, it > was a replacement for internal TraversalEngine.TraverseListener > utilized by several skins. It might be possible to remove it and > instead rely on listening to Scene.focusOwnerProperty, at the expense > of complicating the skins.? Is this a good idea?? Will removing the > event make it more difficult to write a custom component/skin? > I think it is worth looking into this.? API to make things "easier" to implement now will bite you later (see CSS and its binary CSS load/save API that didn't really needed to be public...) > > 2. The fact that some policies depend on the state of the control > basically negates the idea of standard set of policies encoded in an enum. > I really think exposing policies is a bit overkill, and should be considered later if at all.? Controls just want to be able to use the standard traversal mechanism, which will not be such a pain to get once https://bugs.openjdk.org/browse/JDK-8340852 is fixed (as you can just let it bubble up).? Controls that really want something different to happen can take the extra steps of adding KeyEvent handlers, consuming those only when they don't want the standard navigation from Scene. I don't think it should be a goal to have all the complex navigation cases possible with FX controls be possible with a new API.? You can already do whatever navigation you want by finding the Node you need and focusing it.? The problem has always been how to get the **default** navigation for your custom control (which will cover the vast majority of cases already) -- this was hard because events wouldn't bubble up to Scene properly, which necessitated installing your own Key handlers, which then necessitates having access to the standard focus changing code... It is a cascade of problems for which we're now building a "workaround", which IMHO is not really needed once the cause of this problem is fixed. > 3. Controls may need to intercept traversal keys and fire off the > traversal, for example, TAB on a read-only TextArea should traverse, > but should insert the tab character into the editable TextArea.? (I > would imagine this can be also implemented by not consuming events if > they effect no change in the control, but that is a different story). > That's really how it should be.? Controls should preferably always delegate so there is no navigation code all over the place. --John > 4. It might be possible for controls like ToggleButton to set its own > traversal policy instead intercepting KeyEvents (which is the current > way of dealing with conditional traversal).? I would imagine this > being done as a separate enhancement though. > > Thanks, > > -andy > > *From: *Martin Fox > *Date: *Tuesday, September 24, 2024 at 13:30 > *To: *Andy Goryachev > *Cc: *OpenJFX > *Subject: *Re: [External] : Re: Proposal: Focus Traversal API > > Andy, > > Glad to finally see a proposal for opening up traversal. Long overdue. > > There?s a case in the current control set that this API doesn?t cover. > ToggleButtons intercept the arrow keys so they can implement a cyclic > traversal policy among buttons in the ToggleGroup. They don?t assume > that their Parent will do this for them. To reproduce this behavior > this API would have to be extended so it can first ask the focusOwner > where to traverse to before moving on to the Parent. (And looking at > the code I think there?s yet another bug where events are consumed > when they should not be. Sigh). > > The proposal doesn?t provide any use cases for the TraversalEvent. It > also doesn?t specify the initial target of the event or how it should > be handled. I had to look in the sources to see what it?s being used > for and that (a) it?s being fired at the new focus owner and (b) it?s > a bad idea to consume it. It looks more like information you want to > broadcast to a set of listeners rather than a message to be acted on. > If nothing else the bounds should be removed from this event since > that?s a very specific piece of info that only the ScrollPaneSkin > wants. I haven?t mapped out the details but I?m pretty sure it can > figure out the bounds itself. > > This proposal should give some quick background on how traversal key > events are handled, specifically that controls should let the key > events bubble up to the Scene to invoke traversal. And if the > traversal keys are always going to be consumed by the Scene that > should also be mentioned. > > There?s been a few comments suggesting the traversal key events should > not be consumed if the focusOwner doesn?t change. Unfortunately that > would break Popups which have an, um, interesting event architecture. > And I don?t want to introduce yet another instance where events need > to be consumed under specific conditions or things break down (I?m > currently tracking down bugs where ESCAPE is consumed when it > shouldn?t be or not consumed when it should be). We should figure out > what these clients need and ensure it?s delivered to them in a > reliable way. Perhaps when traversal ends we could fire an event at > the Scene with all the details? > > The sample code is problematic since we really don?t want controls to > kick off traversal themselves unless they absolutely have to. That > caveat should probably precede the code. If you must provide some > sample code please make sure it checks the modifier state on the > KeyEvent. (There really should be a central API for mapping a KeyEvent > to a TraversalDirection but that would be a different proposal.) > > If we provide pre-packaged traversal policies we?ll need to provide > multiple variants of CYCLIC. A menu bar cycles horizontally with the > arrow keys and Tab but not vertically. According to the w3c a toggle > button group should cycle with all the arrow keys but not with the Tab > key. And there?s probably one or two more combinations in the current > control set and w3c accessibility guidelines. > > Martin > > > > On Sep 24, 2024, at 11:57?AM, Andy Goryachev > wrote: > > I fully agree with Martin here. > > -andy > > *From:*Martin Fox > *Date:*Wednesday, September 18, 2024 at 11:49 > *To:*John Hendrikx > *Cc:*Andy Goryachev , OpenJFX > > *Subject:*Re: [External] : Re: Proposal: Focus Traversal API > > John, > > Sorry I didn?t respond to this thread earlier.?I?ve been looking > at the code and bug database trying to work backward to a problem > statement. The bug reports cited in the PR are light on details so > I?m trying to come up with a more concrete set of use cases to > consider. > > Currently I?m failing to see the benefit of a traversal event model. > > - User can decide to act on **any** key, even navigation > keys, without the system interfering by consuming keys > early, unexpectedly or even consuming these keys without > doing anything (sometimes keys get consumed that don't > actually change focus...). > > It doesn?t really matter whether the control is capturing the key > event and invoking the traversal engine directly or firing off a > TraversalEvent. The problem is that the control is processing the > key event in the first place. You?re talking about something that > happens before traversal is even initiated. > > It?s unfortunate that the code snippet in the proposal shows a > control doing a direct mapping from KeyCodes to traversal calls. > That?s not how the current system is intended to work. There?s > already a dispatcher at the Scene level that processes KeyEvents > and invokes the traversal machinery so controls should just let > the traversal keys bubble up. There are exceptions to this > throughout the code which I would like to get a better handle on > since I can?t tell if they?re bugs or truly necessary exceptions. > > Once the system has determined that it?s time for traversal it > needs to map from a KeyEvent to a direction and type. I can see > where providing a centralized API for doing this could be of > benefit but I?m not sure that has anything to do with this PR or > the concept of TraversalEvents. This is also a decision made > before traversal is initiated. > > You give some examples of customizing traversal in various ways. > From what I can tell all of them can be accomplished using this PR > with maybe one exception that I?ll get to when I respond to Andy?s > proposal. In other cases I can?t tell if a TraversalEvent would > provide a cleaner implementation because I don?t understand how > they would work. For example, one could imagine a system where a > TraversalEvent is fired by the Scene and expected to bubble back > up to the Scene which will then utilize the existing centralized > engines to actually perform the traversal. But one could also > imagine a system where the Scene fires a TraversalEvent and the > nodes act on them directly as it bubbles up. I?m not sure what you > have in mind. It would be nice to see some examples of how a > TraversalEvent would move through the system in various scenarios > particularly when traversing laterally. > > Martin > > On Sep 17, 2024, at 11:05?PM, John Hendrikx > wrote: > > Andy, > > As you're not responding to any of the suggestions or any of > my questions, but are only re-iterating points that I believe > are not going to be a benefit to the long term viability of > FX, I see no point in continuing the discussion further. > > --John > > On 18/09/2024 01:09, Andy Goryachev wrote: > > Dear John: > > You do bring a lot of good points, no doubt.? And I do > agree with a lot of the suggestion, but I still want to > emphasize two points: > > 1. The backward compatibility should not be dismissed that > easily.? There is a number of existing applications out > there and we do not want to break them.? Whether the > behavior is specified or not is irrelevant, we do not want > to cause mayhem from the customers and developers alike > whose keyboard navigation suddenly changed. > > 2. I question the cost benefit analysis of the redesign > idea.? While I agree with you that it might help with some > unusual cases, the overall benefit is rather limited.? The > benefit of the proposed solution is, in my opinion, far > greater: it allows for custom traversal policies (a > feature that has been requested multiple times) and > enables focus traversal from custom components, something > of a lesser value, but still important. Exposing the > existing APIs is a relatively cheap solution that will > give us two features at nearly zero cost.? On the other > hand, I doubt that our team, or yourself, are willing > commit substantial development effort to redesign the > thing to use events.? Which brings me to the choice I > mentioned earlier: realistically, we have a choice of > providing two requested features soon, or never. > > I would also encourage other members of the development > community to voice their opinion on the subject, perhaps > there is something else we can do to move forward. > > Thank you > > -andy > > *From:*John Hendrikx > > *Date:*Saturday, September 14, 2024 at 09:41 > *To:*Andy Goryachev > ,openjfx-dev at openjdk.org > > > *Subject:*[External] : Re: Proposal: Focus Traversal API > > Hi Andy, > > First let me say that when it comes to designing an API, > you really need to take the time to think the solution > through.? The current internal solution was probably kept > internal for exactly that reason, insufficient time to > work out the kinks and look into alternatives. > > An API is almost impossible to change later, so the > general rule is that if you're not sure about an API, then > its better to have no API.? This is why I think it is > important that we first look for what the API should look > like, then worry about how this can be fitted onto > JavaFX.? Making concessions related to the current > implementation before having a clear idea of how the API > should preferably work is not part of that.? You start > making concessions only when it turns out the preferred > design would encounter unresolvable problems in the > current implementation. > > Since I think there is very little public API related to > focus traversal, nor is there any specification of how it > currently works, I think we have a lot of room to > maneuver. This is why I think we should first reach a > consensus on the API, then look how it can be fitted on > top of FX.? Sometimes a well thought out API also is a > natural fit, and may be easier to migrate to than you think. > > On 14/09/2024 00:17, Andy Goryachev wrote: > > Dear John, Everyone: > > Thank you for a thoughtful response! Some of the ideas > you described definitely deserve further > consideration. If I were to summarize: > > 1. move the focus traversal logic away from the > components and into the Scene > > 2. re-implement focus traversal through > TraversalEvents rather than responding directly to > KeyEvents > > 3. (more) standard policies > > 4. using CSS > > (there is of course more topics in your response, but > let me start with the 4 above) > > #1 > > I generally like this idea.? In some sense it is > already how things work internally, but without the > ability to customize that (i.e. by introducing custom > traversal keys, or removing existing ones).? The > downside is substantial: not only we'd need to > re-design the whole of the focus traversal, but also > rework the existing control's behaviors. Did I mention > the risk of regression, given the absence of > comprehensive behavioral tests? > > There's two things here. > > 1. There is no need to re-design the whole focus > traversal.? The old internal system can be gradually > replaced (it works by directly consuming KeyEvents after all). > > 2. Regression.? When nothing is specified, and the fact > that controls **ought** to work like other common controls > in different UI toolkits, is it a regression when focus > traversal works the same as those other platforms, even if > it may be a regression from the point of view of FX?? For > example, a Spinner will currently react to any mouse key, > where as other common toolkits only react to the left > mouse button.? Is it a regression if FX is adjusted to > also only react to the left mouse button?? It's not > specified anywhere. > > I think we have sufficient space to maneuver here as long > as we are not making focus traversal completely different > from how it commonly works in UI's. > > Can there be regressions versus the current (unspecified) > implementation? Sure, there can be. Is that necessarily > bad?? That depends. If the new focus traversal works like > it does on all other toolkits, then no, it is more of a > bug fix.? Did we break something with the new > implementation? That's always possible, but will then be > fixed as soon as it is reported. > > #2 > > This may or may not be an integral part of #1. > Potentially, it allows for injection of events by the > application code, as well as simplifies creation of > complex custom controls.? The latter becomes possible > with the original proposal, so net benefit is limited > to the first part, I think. > > I think TraversalEvents are quite central to making this > an API that will really stand the test of time.? It > leverages the existing event system, giving you all the > power that comes with it.? You did not answer my question > about the TraversalEvents in your design.? Why are the > Events when they can't be triggered, filtered or?consumed? > > #3 > > One obvious possibility is to enable creation of a > simple policy based on a list of Nodes.? I must > mention one use case that is impossible to cover with > pre-defined policy is one where navigation depends on > some state. Such a policy must be implemented > programmatically. I think one property should be > sufficient - I am strongly against adding two > properties here. > > Programmatic escapes can always be achieved by responding > directly to a TraversalEvent. I think however this should > be a rare case, and standard policies should really cover > almost all use cases. It may be a gap that should be > investigated, and the API adjusted for (usually the > "exceptions" are well worth looking into to see if with a > tweak they can't become "standard").? As for being > "strongly against" having two properties -- that's an odd > stance to take without motivating it.? It could also be > rolled into "one" where the Policy is a record with the > two values, but I think we're getting ahead of ourselves > here.? First the API, then the implementation. > > I do think however there is great value in having the > Logical and Directional navigation split. Often you'll > only want to replace one of these with a custom policy (or > a different standard policy), so that the other navigation > method can be used to escape the control.? For example, a > Toolbar could be tabbed in an out of (using Logical > navigation) while the Directional navigation is cyclic > (and thus can't be used to escape the control's context). > > #4 > > The idea of using CSS to specify traversal policy > seems wrong to me: the CSS defines the presentation > aspects (styles) rather than behavioral ones.? I know > it is possible to set custom skins and the > corresponding behavior via CSS, and we know why (skins > define the appearance), but we should not go beyond > that, in my opinion. > > I see no problem styling such properties.? They're FX > properties, and it would be very convenient to style them > to globally alter how focus works, instead of having to > rely on, say, Builders or Factories for controls where > traversal policies can be applied.? There are also already > properties that don't only influence the look of controls. > "-fx-skin" being the most obvious one, but there is also > "-fx-focus-traversable", "-fx-context-menu-enabled", > "-fx-block-increment", "-fx-unit-increment", > "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", > "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", > "-fx-hide-delay", and probably more.? Aside from > "-fx-skin" none of these properties have a visual impact, > but instead alter behavior. > > Note: I'm not saying this needs to be there immediately.? > I just want to make sure we're not closing off this > direction, as again, it would be a huge hassle to do this > programmatically.? In "code" the only things I usually do > on my controls are the following: > > - I define the container hierarchy (VBox, HBox, which > children go where) > - I set a style name > - I set anything that unfortunately cannot be CSS styled > (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid > sizes, etc, things that are clearly "visual" but still > can't be styled). > > All the rest I don't touch, or want to touch.? Having to > select a traversal policy for every control of type X I > create is just cumbersome and unnecessary.? There will be > a call then to set this "globally", and then there will be > the question, do we make something custom with many > limitations because it doesn't fit our conceptions of what > (FX) CSS is for (ie, not?style, but only?*visual* style) > or do we just expose these properties as > Styleable?leveraging an existing powerful system with > almost zero effort? > > -- > > There is one more aspect of the problem that I think > we should consider.? The current proposal does not > change the implementation in any material way, nor > does it change the behavior, thus can be done > quickly.? The benefit everyone gets from it is ability > to trigger focus traversal and to control it via > custom policies.? Any other solution will require > resources and the bandwidth we currently don't have, > which means the/probability/of it being added to FX is > virtually zero.? Let me emphasize, I am not against > attempting to discuss or implement the best possible > solution, but we should be aware of the limitations of > the reality we live in. > > "Quickly" and API's are incompatible with each other.? > There is nothing worse than exposing an API quickly, which > then becomes a burden on the system -- I think the current > CSS API is a prime example of where "quickly" has gone > wrong, costing us tremendous amounts of effort to make > even minor changes to it. > > I urge you to ignore the current implementation, think > thoroughly how (in an ideal world) you would want such an > API to work (from a user perspective, not from an > implementor's perspective) and only then see how this > could be made to fit into JavaFX. > > This is exactly what I did.? I did not look at the > implementation, although I'm aware of some of it.? I > looked at how I as a user of FX am building applications, > the struggles I have?with it currently, (with controls for > example "eating" KeyEvents), and how I would like to be > able to adjust focus traversal.? Do I want to respond to > "KeyCode.LEFT" or do I want to respond to > "TraversalEvent.LEFT"? Do I also need to respond to > "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, > and preferably I should just be able to choose from common > navigation standards.? And when I do want to change such a > standard, in 99% of the cases that will be the case for > all similar controls in my application.? How do I do such > things currently if I want to change something for all > controls in my application?? I use CSS. > > Also I think this can be implemented gradually.? Here's a > potential plan: > > 1. Have Scene listen to unused KeyEvents and translate > them to TraversalEvents > > Benefit:?gives custom controls a way to respond to > keyboard based navigation in a platform agnostic way; this > probably already removes the biggest roadblock for custom > controls... > > Public API: Limited to a new Event > > 2. Start converting existing controls to listen to > TraversalEvent instead of KeyEvent > > This hits a lot of controls, but should be relatively easy > to do, and it can be all kept internal for now.? It can be > done in a few batches. > > Benefit: for each control converted, user can now > programmatically trigger focus changes, and by overriding > things at Scene level can completely change navigation keys > > Public API: none > > 3. Implement a number of standard policies internally > (OPEN, CONFINED, CYCLIC, IGNORED) > > Convert any controls that could use these as their > default, removing any custom logic if it happens to match > one of the defaults. > > Benefit: less code to maintain and debug, gives us > experience with which policies make sense and where the > gaps are > > Public API: none > > Order: It is possible to do this before 2, and so some of > the control conversions could just consist of removing > their custom logic, and selecting a standard policy. > > 4. Expose policy property/properties?on Parent > > Any controls that are not using a custom policy anymore > (of type IGNORED) can now be user adjusted.? We don't have > to guarantee that each policy makes sense for each > control. Changing a default IGNORED policy to a standard > one will change the behavior (as intended) but it need not > be a "complete" behavior that users like.? This is not > FX's problem, and can be improved upon later. > > Benefit: users can now change policies on any existing > control, even ones with a custom policy; many of the > controls may support a switch between OPEN, CONFINED and > CYCLIC out of the box. > > Public API: new properties on Parent > > 5. Perhaps expose some helpful tools to calculate the > "next" Node for a given traversal option. > > This can be done at any stage, and can be considered > completely separate.? It is IMHO a relatively low?priority > need. > > Benefit: less work for control implementors (although they > could just "copy" said code) > > Public API: Maybe some methods in Node, or some kind of > static helper. > > 6. CSS styleable properties > > If we really want to give power to our users, and impress > them with a flexible focus traversal API, then make these > properties styleable. > > Benefit: allow users to pick any control, and set is > policy globally or within a subset of controls (ie. > dialogs, popups, etc). > > Public API: Nothing in Java, but document as CSS properties > > --John > > Thank you, > > -andy > > *From:*openjfx-dev > on behalf of John > Hendrikx > > *Date:*Wednesday, September 11, 2024 at 19:05 > *To:*openjfx-dev at openjdk.org > > > *Subject:*Re: Proposal: Focus Traversal API > > Hi Andy / List, > > I've given this some thought first,?without looking > too much at the proposal. > > In my view, focus traversal should be implemented > using events, and FX should provide standard handling > of these events controlled with properties > (potentially even CSS stylable for easy mass changing > of the default navigation policy). > > ##?KeyEvent and TraversalEvent separation > > I think the cleanest implementation would be to > implement a KeyEvent listener on Scene that takes any > unused KeyEvents, checks if they're considered > navigation keys, and converts these keys to a new type > of event, the TraversalEvent. The TraversalEvent is > then fired at the original target. The TraversalEvent > is structured into Directional and Logical sub types, > and has leaf types UP/DOWN/LEFT/RIGHT and > NEXT/PREVIOUS.? Scene is the logical place to handle > this as without a Scene there is no focus owner, and > so there is no point in doing focus traversal. > > This separation of KeyEvents into TraversalEvents > achieves the following: > > - User can decide to act on **any** key, even > navigation keys, without the system interfering by > consuming keys early, unexpectedly or even consuming > these keys without doing anything (sometimes keys get > consumed that don't actually change focus...). The > navigation keys have many possible dual purposes, and > robbing the user of the opportunity to use them due to > an overzealous component interpreting them as > traversal keys is very annoying. Dual purposes include > for example cursor control in TextField/TextArea, > Scrollbars, etc.? The user should have the same > control here as these FX controls have. > > - Scene is interpreting the KeyEvents, and this > interpretation is now controllable. If I want a > Toolbar (or the whole application) to react to WASD > navigation keys, then installing a KeyEvent handler at > Scene level or at any intermediate Parent level that > converts WASD to UP/LEFT/DOWN/RIGHT Traversal events > would affect this change easily. > > - The separation also allows to block Focus Traversal > only, without blocking the actual Keys involved.? If I > want to stop a Toolbar from reacting to LEFT/RIGHT, > but I need those keys higher up in the hierarchy, then > I'm screwed.? With the separation, the key events are > unaffected, and I can block Toolbars from reacting > specifically to traversal events only. > > ## Traversal Policy Properties on Parent > > I think FX should provide several policies out of the > box, based on common navigation patterns.? The goal > here is to have policies in place that cover all use > cases in current FX provided controls. This will > provide a good base that will cover probably all > realistic work loads that custom controls may have. > The goal is not to support every esoteric form of > navigation, instead an escape hatch will be provided > in the form of disabling the standard navigation. > > In order to achieve this, I think Parent should get > two new properties, which control how it will react to > Directional and Logical navigation. These will have > default values that allow navigation to flow from Node > to Node within a Parent and from Parent to its Parent > when navigation options in a chosen direction are > exhausted within a Parent. Custom controls like Combo > boxes, Toolbars, Button groups, etc, can change the > default provided by a Parent (similar to how some > controls change the mouse transparent flag default). > > These two properties should cover all realistic needs, > and IMHO should be considered to be CSS stylable in > the future to allow easy changing of default policies > of controls (ie. want all Toolbars to react > differently to navigation keys, then just style the > appropriate property for all toolbars in one go). > > Parent will use these properties to install an event > handler that reacts to TraversalEvents (not > KeyEvents).? This handler can be fully disabled, or > overridden (using setOnTraversalEvent). > > - logicalTraversalPolicy > - directionalTraversalPolicy > > The properties can be set with a value from a > TraversalPolicy enum.? I would suggest the following > options: > > - OPEN > > This policy should be the default policy for all > Parents.? It will act and consume a given > TraversalEvent only when there is a suitable target > within its hierarchy.? If there is no suitable target, > or the target would remain unchanged, the event is NOT > consumed and left to bubble up, allowing its parent(s) > to act on it instead. > > - CONFINED > > This policy consumes all TraversalEvents, regardless > of whether there is something to navigate to or not.? > This policy is suitable for controls that have some > kind of substructure that we don't want to > accidentally exit with either Directional or Logical > navigation. In most cases, you only want to set one of > the properties to CONFINED as otherwise there would be > no keyboard supported way to exit your control.? This > is a suitable policy for say button groups, toolbars, > comboboxes, etc. > > - CYCLIC > > Similar to CONFINED but instead of stopping navigation > at the controls logical boundaries, the navigation > wraps around to the logical start.? For example, when > were positioned on the right most button in a button > group, pressing RIGHT again would navigate to the left > most button. > > - IGNORED > > This is similar to the mouseTransparent property, and > basically leaves the TraversalEvent to bubble up. This > policy allows you to completely disable directional > and/or logical navigation for a control. Useful if you > want to install your own handler (the escape hatch) > but still want to keep either the default directional > or logical navigation. > > Possible other options for this enum could include a > version that consumes all TraversalEvents (BLOCK) but > I don't see a use for it at the moment. There may also > be variants of CONFINED and CYCLIC that make an > exception for cases where there is only a single > choice available.? A ButtonGroup for example may want > to react differently depending on whether it has 0, 1 > or more buttons. Whether these should be enshrined > with a custom enum value, or perhaps a flag, or just > left up to a custom implementation is something we'd > need to decide still. > > ## Use Cases > > 1) User wants to change the behavior of a control from > its default to something else (ie. a Control that is > CYCLIC can be changed to OPEN or CONFINED) > > Just call the setters with the appropriate preferred > policy.? This could be done in CSS for maximum > convenience to enable a global change of all similar > controls. > > 2) User wants to act on Traversal events that the > standard policy leaves to bubble up > > Just install a Traversal event handler either on the > control or on its parent (depending on their needs). A > potential action to an unused Traversal event could be > to close a Dialog/Toast popup, or a custom behavior > like selecting the first/last item or next/previous > row (ie. if I press "RIGHT" and there is no further > right item, a user could decide to have this select > the first item again in the current Row or the first > item in the **next** Row). > > 3) User wants to do crazy custom navigation > > Set both policies to?IGNORED, then install your own > event handler (or use the setOnTraversalHandler to > completely override the handler).? Now react on the > Traversal events, consuming them at will and changing > focus to whatever control you desire. > > 4) User wants to change what keys are considered > navigation keys > > Install event handler on Scene (or any intermediate > Parent) for KeyEvents, interpret WASD keys as > UP/LEFT/DOWN/RIGHT and sent out a corresponding > Traversal event > > 5) User wants to use keys that are considered > navigation keys for their own purposes > > Just install a KeyEvent handler as usual, without > having to worry that Skins/Controls eat these events > before you can get to them > > 6) User wants to stop a control from reacting to > traversal events, without filtering navigation keys > completely > > With the separation of unconsumed KeyEvents into > TraversalEvents, a user can now block only the latter > to achieve this goal without having to blanket block > certain KeyEvents. > > ----- > > About the Proposal: > > I think the Goals are fine as stated, although I think > we differ on what the Traversal events signify. > > I think CSS support should be considered a possible > future goal. The proposal should therefore take into > account that we may want to offer this in the future. > > Motivation looks okay. > > > The focus traversal is provided by the FocusTraversal class > which offers static methods for traversing focus in > various directions, determined by the > TraversalDirection enum. > > I think these methods don't need to be exposed with a > good selection of standard TraversalPolicy options. > After all, there are only so many ways that you can do > a sensible navigation action without confusing the > user, and therefore I think these policy options will > cover 99% of the use cases already.? For the left over > 1% we could **consider** providing these focus > traversal functions as a separate public API, but I > would have them return the Node they would suggest, > and leave the final decision to call requestFocus up > to the caller. Initially however I think there is > already more than enough power for custom > implementations to listen to Traversal events and do > their own custom navigation. If it is not similar to > one of the standard navigation options, the > traverseUp/Down functions won't be of much use then > anyway. > > About your typical example: > > Node from = ... > switch (((KeyEvent)event).getCode()) { > case UP: > FocusTraversal.traverse(from, TraversalDirection.UP, > TraversalMethod.KEY); > event.consume(); > break; > case DOWN: > // or use the convenience method > FocusTraversal.traverseDown(from); > event.consume(); > break; > } > > I think this is not a good way to deal with events. > > 1) The event is consumed regardless of the outcome of > traverse. What if focus did not change? Should the > event be consumed? > > 2) This is consuming KeyEvents directly, robbing the > user of the opportunity to act on keys considered > "special" by FX. > > 3) This code is not only consuming KeyEvents directly, > but also deciding what keys are navigation keys. > > So I think this example?code should be different. > However, first I expect that in most cases, > configuring a different traversal policy on your > Parent subclass will already be sufficient in almost > all cases (especially if we look at FX current > controls and see if the suggested policies would cover > those use cases). So this code will almost never be > needed. However, in the event that you need something > even more specific, you may consider handling > Traversal events directly.? In which case the code > should IMHO look something like this: > > Node from = ... > > Node result = switch(traversalEvent.getEventType()) { > case TraversalEvent.UP -> FocusTraversals.findUp(from); > case TraversalEvent.DOWN -> > FocusTraversals.findDown(from); > // etc > } > > if (result != null) { > result.requestFocus(); > traversalEvent.consume(); > } > > Note that the above code leaves the final decision to > call requestFocus up to the caller.? It also allows > the caller to distinguish between the case where there > is no suitable Node in the indicated direction and act > accordingly. > > This allows it to?NOT consume the event if it prefers > its Parent to handle it (if the control doesn't want > CYCLIC or CONFINED style navigation). It also allows > it to further scrutinize the suggested Node, and if it > decides it does not like it (due to some property or > CSS style or whatever) it may follow up with another > findXXX call or some other option to pick the Node it > wants.? It also allows (in the case of no Node being > found) to pick its own preferred Node in those cases.? > In other words, it is just far more flexible. > > I'm not sure yet where to place these static helper > methods (if we decide to expose them at all > initially), or even if they should be static.? Given > that its first parameter is always a Node, a > non-static location for them could simply be on Node > itself, in which case the calling convention would > become "Node result = from.findTraversableUp()" > (suggested name only) > > > Focus traversals generate a new type of event, encapsulated > by the class TraversalEvent which extends > javafx.event.Event, using the event type > TraversalEvent.NODE_TRAVERSED. > > What is the point of this event? If you want to know > that focus changed, you can add a listener to > Scene.focusOwnerProperty. What does it mean if I > filter this event?? What if I consume it?? I don't > think this should be an event at all, unless > implemented as I suggested above, where > consuming/filtering/bubbling can be used to control > how controls will react to navigation events. > > --John > > On 03/09/2024 21:33, Andy Goryachev wrote: > > Dear fellow developers: > > I'd like to propose the public focus traversal API: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > > Draft PR: > > https://github.com/openjdk/jfx/pull/1555 > > > Your comments and suggestions will be warmly > accepted and appreciated. > > Thank you > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Sep 26 21:38:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 26 Sep 2024 21:38:10 GMT Subject: RFR: 8340829: Generated API docs should clearly identify EA builds Message-ID: This PR modifies the header and footer of the javadoc-generated API docs to add "DRAFT $VER-ea+$BLD" to clearly identify an ea build of the docs, and also to make it clear which build number the docs refer to. This matches was the JDK does. For GA builds, there will be no change to what we generate today. Since I had to add logic to filter the javadoc properties defined in `build.javadoc` to add the DRAFT message if not a GA build, I also changed the properties to not hard-code the major version of JavaFX, thus reducing the duplication. I ran three builds to test this, an ordinary developer build, an EA build, and a GA build as follows: #### Developer build Command line: gradle javadoc Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-internal/ #### EA build Command line: gradle -PPROMOTED_BUILD_NUMBER=98 -PHUDSON_BUILD_NUMBER=1234 -PHUDSON_JOB_NAME=jfx-dev javadoc Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-ea/ #### GA build Command line: gradle -PMILESTONE_FCS=true -PPROMOTED_BUILD_NUMBER=99 -PHUDSON_BUILD_NUMBER=4321 -PHUDSON_JOB_NAME=jfx-dev javadoc Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-fcs/ ------------- Commit messages: - 8340829: Generated API docs should clearly identify EA builds Changes: https://git.openjdk.org/jfx/pull/1583/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1583&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340829 Stats: 19 lines in 3 files changed: 11 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1583.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1583/head:pull/1583 PR: https://git.openjdk.org/jfx/pull/1583 From kcr at openjdk.org Thu Sep 26 21:38:11 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 26 Sep 2024 21:38:11 GMT Subject: RFR: 8340829: Generated API docs should clearly identify EA builds In-Reply-To: References: Message-ID: <9FUXuojPm4yzOeXANBtKRNZGr7qRzXl729NcBbqoQhg=.7efb290b-3616-4044-8167-5b578df1b50f@github.com> On Thu, 26 Sep 2024 21:33:10 GMT, Kevin Rushforth wrote: > This PR modifies the header and footer of the javadoc-generated API docs to add "DRAFT $VER-ea+$BLD" to clearly identify an ea build of the docs, and also to make it clear which build number the docs refer to. This matches was the JDK does. For GA builds, there will be no change to what we generate today. Since I had to add logic to filter the javadoc properties defined in `build.javadoc` to add the DRAFT message if not a GA build, I also changed the properties to not hard-code the major version of JavaFX, thus reducing the duplication. > > I ran three builds to test this, an ordinary developer build, an EA build, and a GA build as follows: > > #### Developer build > > Command line: > > gradle javadoc > > > Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-internal/ > > #### EA build > > Command line: > > gradle -PPROMOTED_BUILD_NUMBER=98 -PHUDSON_BUILD_NUMBER=1234 -PHUDSON_JOB_NAME=jfx-dev javadoc > > > Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-ea/ > > #### GA build > > Command line: > > gradle -PMILESTONE_FCS=true -PPROMOTED_BUILD_NUMBER=99 -PHUDSON_BUILD_NUMBER=4321 -PHUDSON_JOB_NAME=jfx-dev javadoc > > > Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-fcs/ Reviewers: @arapte @irisclark ------------- PR Comment: https://git.openjdk.org/jfx/pull/1583#issuecomment-2377978092 From martin at martinfox.com Thu Sep 26 23:29:45 2024 From: martin at martinfox.com (Martin Fox) Date: Thu, 26 Sep 2024 16:29:45 -0700 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> Message-ID: <30F9D967-7FBA-4407-BA0D-44EB691A4FC8@martinfox.com> Hi Andy, Glad to hear the TraversalEvent is gone. I?ll try go take a look at the new implementation next week. > > There?s a case in the current control set that this API doesn?t cover. ToggleButtons intercept the arrow keys so they can implement a cyclic traversal policy among buttons in the ToggleGroup. They don?t assume that their Parent will do this for them. To reproduce this behavior this API would have to be extended so it can first ask the focusOwner where to traverse to before moving on to the Parent. > > I don't think this is correct. The traversal policy API are sufficient to be able to determine the right node because both parent and the node it wants to traverse from are passed as arguments (i.e. select()). When the policy determines it's time to step out of the control, the policy has findXX() methods. Sorry I was so terse in my first message. I?ll try to explain this more clearly. Currently you can create three ToggleButtons, add them to the same ToggleGroup, shove them into any old container (like a VBox), and they will exhibit cyclical traversal behavior using the arrow keys. The ToggleButtonBehavior is directly intercepting the arrow keys and implementing the cycle. The parent VBox knows nothing about any of this. If you add a plain old Button to the same VBox so it?s a sibling of the toggles the ToggleButtons will still cycle among themselves and the plain Button won?t be part of the cycle. If I understand the proposal and code correctly (and that?s a big ?if?) we can?t re-implement this exact behavior with the new API. If one of the ToggleButtons is the focus owner the traversal engine will start by consulting the parent VBox which knows nothing. To get the current cyclic behavior the traversal engine would have to start by asking the ToggleButton itself what to do. And I imagine that would require extending this API. I would be fine just keeping the current implementation and not altering this proposal to cover this case. Since ToggleButtons don?t have children there?s no harm in them intercepting the arrow keys. I thought I should mention it as an interesting traversal behavior in the existing code. > Did I provide satisfactory answers, or there are other things that you find problematic? Nope, I?m good. Many thanks. Martin > > References > > [0] InputMap https://github.com/andy-goryachev-oracle/Test/tree/main/doc/InputMap > > > > > > From: Martin Fox > Date: Tuesday, September 24, 2024 at 13:30 > To: Andy Goryachev > Cc: OpenJFX > Subject: Re: [External] : Re: Proposal: Focus Traversal API > > Andy, > > Glad to finally see a proposal for opening up traversal. Long overdue. > > There?s a case in the current control set that this API doesn?t cover. ToggleButtons intercept the arrow keys so they can implement a cyclic traversal policy among buttons in the ToggleGroup. They don?t assume that their Parent will do this for them. To reproduce this behavior this API would have to be extended so it can first ask the focusOwner where to traverse to before moving on to the Parent. (And looking at the code I think there?s yet another bug where events are consumed when they should not be. Sigh). > > The proposal doesn?t provide any use cases for the TraversalEvent. It also doesn?t specify the initial target of the event or how it should be handled. I had to look in the sources to see what it?s being used for and that (a) it?s being fired at the new focus owner and (b) it?s a bad idea to consume it. It looks more like information you want to broadcast to a set of listeners rather than a message to be acted on. If nothing else the bounds should be removed from this event since that?s a very specific piece of info that only the ScrollPaneSkin wants. I haven?t mapped out the details but I?m pretty sure it can figure out the bounds itself. > > This proposal should give some quick background on how traversal key events are handled, specifically that controls should let the key events bubble up to the Scene to invoke traversal. And if the traversal keys are always going to be consumed by the Scene that should also be mentioned. > > There?s been a few comments suggesting the traversal key events should not be consumed if the focusOwner doesn?t change. Unfortunately that would break Popups which have an, um, interesting event architecture. And I don?t want to introduce yet another instance where events need to be consumed under specific conditions or things break down (I?m currently tracking down bugs where ESCAPE is consumed when it shouldn?t be or not consumed when it should be). We should figure out what these clients need and ensure it?s delivered to them in a reliable way. Perhaps when traversal ends we could fire an event at the Scene with all the details? > > The sample code is problematic since we really don?t want controls to kick off traversal themselves unless they absolutely have to. That caveat should probably precede the code. If you must provide some sample code please make sure it checks the modifier state on the KeyEvent. (There really should be a central API for mapping a KeyEvent to a TraversalDirection but that would be a different proposal.) > > If we provide pre-packaged traversal policies we?ll need to provide multiple variants of CYCLIC. A menu bar cycles horizontally with the arrow keys and Tab but not vertically. According to the w3c a toggle button group should cycle with all the arrow keys but not with the Tab key. And there?s probably one or two more combinations in the current control set and w3c accessibility guidelines. > > Martin > > > On Sep 24, 2024, at 11:57?AM, Andy Goryachev wrote: > > I fully agree with Martin here. > > -andy > > From: Martin Fox > Date: Wednesday, September 18, 2024 at 11:49 > To: John Hendrikx > Cc: Andy Goryachev , OpenJFX > Subject: Re: [External] : Re: Proposal: Focus Traversal API > > John, > > Sorry I didn?t respond to this thread earlier. I?ve been looking at the code and bug database trying to work backward to a problem statement. The bug reports cited in the PR are light on details so I?m trying to come up with a more concrete set of use cases to consider. > > Currently I?m failing to see the benefit of a traversal event model. > > - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). > > It doesn?t really matter whether the control is capturing the key event and invoking the traversal engine directly or firing off a TraversalEvent. The problem is that the control is processing the key event in the first place. You?re talking about something that happens before traversal is even initiated. > > It?s unfortunate that the code snippet in the proposal shows a control doing a direct mapping from KeyCodes to traversal calls. That?s not how the current system is intended to work. There?s already a dispatcher at the Scene level that processes KeyEvents and invokes the traversal machinery so controls should just let the traversal keys bubble up. There are exceptions to this throughout the code which I would like to get a better handle on since I can?t tell if they?re bugs or truly necessary exceptions. > > Once the system has determined that it?s time for traversal it needs to map from a KeyEvent to a direction and type. I can see where providing a centralized API for doing this could be of benefit but I?m not sure that has anything to do with this PR or the concept of TraversalEvents. This is also a decision made before traversal is initiated. > > You give some examples of customizing traversal in various ways. From what I can tell all of them can be accomplished using this PR with maybe one exception that I?ll get to when I respond to Andy?s proposal. In other cases I can?t tell if a TraversalEvent would provide a cleaner implementation because I don?t understand how they would work. For example, one could imagine a system where a TraversalEvent is fired by the Scene and expected to bubble back up to the Scene which will then utilize the existing centralized engines to actually perform the traversal. But one could also imagine a system where the Scene fires a TraversalEvent and the nodes act on them directly as it bubbles up. I?m not sure what you have in mind. It would be nice to see some examples of how a TraversalEvent would move through the system in various scenarios particularly when traversing laterally. > Martin > > On Sep 17, 2024, at 11:05?PM, John Hendrikx wrote: > > Andy, > > As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. > > --John > > On 18/09/2024 01:09, Andy Goryachev wrote: > Dear John: > > You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: > > 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. > > 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. > > I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. > > Thank you > -andy > > > From: John Hendrikx > Date: Saturday, September 14, 2024 at 09:41 > To: Andy Goryachev , openjfx-dev at openjdk.org > Subject: [External] : Re: Proposal: Focus Traversal API > > Hi Andy, > > First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. > > An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. > > Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. > > On 14/09/2024 00:17, Andy Goryachev wrote: > Dear John, Everyone: > > Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: > > 1. move the focus traversal logic away from the components and into the Scene > 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents > 3. (more) standard policies > 4. using CSS > > (there is of course more topics in your response, but let me start with the 4 above) > > #1 > > I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? > There's two things here. > > 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). > > 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. > > I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. > > Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. > > > #2 > > This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. > I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? > > > #3 > > One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. > Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. > > I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). > > > #4 > > The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. > I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. > > Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: > > - I define the container hierarchy (VBox, HBox, which children go where) > - I set a style name > - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). > > All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? > > -- > > There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. > "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. > > I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. > > This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. > > Also I think this can be implemented gradually. Here's a potential plan: > > 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents > > Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... > > Public API: Limited to a new Event > > 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent > > This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. > > Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys > > Public API: none > > 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) > > Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. > > Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are > > Public API: none > > Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. > > 4. Expose policy property/properties on Parent > > Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. > > Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. > > Public API: new properties on Parent > 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. > > This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. > > Benefit: less work for control implementors (although they could just "copy" said code) > > Public API: Maybe some methods in Node, or some kind of static helper. > > 6. CSS styleable properties > > If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. > > Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). > > Public API: Nothing in Java, but document as CSS properties > > --John > > > Thank you, > -andy > > > > > From: openjfx-dev on behalf of John Hendrikx > Date: Wednesday, September 11, 2024 at 19:05 > To: openjfx-dev at openjdk.org > Subject: Re: Proposal: Focus Traversal API > > Hi Andy / List, > > I've given this some thought first, without looking too much at the proposal. > > In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). > > ## KeyEvent and TraversalEvent separation > > I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. > > This separation of KeyEvents into TraversalEvents achieves the following: > > - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. > > - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. > > - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. > > ## Traversal Policy Properties on Parent > > I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. > > In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). > > These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). > > Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). > > - logicalTraversalPolicy > - directionalTraversalPolicy > > The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: > > - OPEN > > This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. > > - CONFINED > > This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. > > - CYCLIC > > Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. > > - IGNORED > > This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. > > Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. > > ## Use Cases > > 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) > Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. > > 2) User wants to act on Traversal events that the standard policy leaves to bubble up > > Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). > > 3) User wants to do crazy custom navigation > > Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. > > 4) User wants to change what keys are considered navigation keys > > Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event > > 5) User wants to use keys that are considered navigation keys for their own purposes > > Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them > > 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely > > With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. > > ----- > > About the Proposal: > > I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. > > I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. > > Motivation looks okay. > > > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. > > I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. > > About your typical example: > > Node from = ... > switch (((KeyEvent)event).getCode()) { > case UP: > FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); > event.consume(); > break; > case DOWN: > // or use the convenience method > FocusTraversal.traverseDown(from); > event.consume(); > break; > } > > I think this is not a good way to deal with events. > > 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? > > 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. > > 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. > > So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: > > Node from = ... > > Node result = switch(traversalEvent.getEventType()) { > case TraversalEvent.UP -> FocusTraversals.findUp(from); > case TraversalEvent.DOWN -> FocusTraversals.findDown(from); > // etc > } > > if (result != null) { > result.requestFocus(); > traversalEvent.consume(); > } > > Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. > > This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. > > I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > > > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. > > What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. > > --John > > > > > > On 03/09/2024 21:33, Andy Goryachev wrote: > > Dear fellow developers: > > I'd like to propose the public focus traversal API: > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md > > Draft PR: > > https://github.com/openjdk/jfx/pull/1555 > > Your comments and suggestions will be warmly accepted and appreciated. > > Thank you > > -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Fri Sep 27 02:10:02 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 27 Sep 2024 02:10:02 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus Message-ID: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> This change modifies `ScrollPaneBehavior` to only consume keys that are targetted at it. As `KeyEvent`s are in almost all cases only intended for the targetted node (as visually that's where the user expects the keyboard input to go, as per normal UI rules) consuming key events that bubble up is simply incorrect. When the `ScrollPane` is focused directly (it has the focused border) then it is fine for it to respond to all kinds of keys. In FX controls normally there is no need to check if a `Control` is focused (although they probably should **all** do this) as they do not have children that could have received the Key Events involved, and Key Events are always sent to the focused Node. When `ScrollPane` was developed this was not taken into account, leading to it consuming keys not intended for it. This fixes several unexpected problems for custom control builders. A custom control normally benefits from standard navigation out of the box (TAB/shift+TAB) and directional keys. However, this breaks down as soon as this custom control is positioned within a `ScrollPane`, which is very surprising behavior and not at all expected. This makes it harder than needed for custom control developers to get the standard navigation for the directional keys, as they would have to specifically capture those keys before they reach the `ScrollPane` and trigger the correct navigation action themselves (for which as of this writing there is no public API). The same goes for all the other keys captured by `ScrollPane` when it does not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys. ------------- Commit messages: - Stop ScrollPane consuming keys that are not directly targetted at it Changes: https://git.openjdk.org/jfx/pull/1582/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1582&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340852 Stats: 15 lines in 1 file changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1582.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1582/head:pull/1582 PR: https://git.openjdk.org/jfx/pull/1582 From kcr at openjdk.org Fri Sep 27 02:10:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 27 Sep 2024 02:10:02 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus In-Reply-To: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> References: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> Message-ID: On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote: > This change modifies `ScrollPaneBehavior` to only consume keys that are targetted at it. As `KeyEvent`s are in almost all cases only intended for the targetted node (as visually that's where the user expects the keyboard input to go, as per normal UI rules) consuming key events that bubble up is simply incorrect. When the `ScrollPane` is focused directly (it has the focused border) then it is fine for it to respond to all kinds of keys. > > In FX controls normally there is no need to check if a `Control` is focused (although they probably should **all** do this) as they do not have children that could have received the Key Events involved, and Key Events are always sent to the focused Node. When `ScrollPane` was developed this was not taken into account, leading to it consuming keys not intended for it. > > This fixes several unexpected problems for custom control builders. A custom control normally benefits from standard navigation out of the box (TAB/shift+TAB) and directional keys. However, this breaks down as soon as this custom control is positioned within a `ScrollPane`, which is very surprising behavior and not at all expected. This makes it harder than needed for custom control developers to get the standard navigation for the directional keys, as they would have to specifically capture those keys before they reach the `ScrollPane` and trigger the correct navigation action themselves (for which as of this writing there is no public API). > > The same goes for all the other keys captured by `ScrollPane` when it does not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys. When this is ready for review, it will need plenty of testing. Since it is a behavioral change (albeit to fix a bug), we might consider whether it needs a CSR and/or a release note. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2378102823 From jhendrikx at openjdk.org Fri Sep 27 02:10:02 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 27 Sep 2024 02:10:02 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus In-Reply-To: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> References: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> Message-ID: <7T7DNc7Bf_ylsfV1Y3YA6pQpFjv9-4rmx6JO6aKQW1M=.e3297649-8854-499e-9861-7f29f17b3a21@github.com> On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote: > This change modifies `ScrollPaneBehavior` to only consume keys that are targetted at it. As `KeyEvent`s are in almost all cases only intended for the targetted node (as visually that's where the user expects the keyboard input to go, as per normal UI rules) consuming key events that bubble up is simply incorrect. When the `ScrollPane` is focused directly (it has the focused border) then it is fine for it to respond to all kinds of keys. > > In FX controls normally there is no need to check if a `Control` is focused (although they probably should **all** do this) as they do not have children that could have received the Key Events involved, and Key Events are always sent to the focused Node. When `ScrollPane` was developed this was not taken into account, leading to it consuming keys not intended for it. > > This fixes several unexpected problems for custom control builders. A custom control normally benefits from standard navigation out of the box (TAB/shift+TAB) and directional keys. However, this breaks down as soon as this custom control is positioned within a `ScrollPane`, which is very surprising behavior and not at all expected. This makes it harder than needed for custom control developers to get the standard navigation for the directional keys, as they would have to specifically capture those keys before they reach the `ScrollPane` and trigger the correct navigation action themselves (for which as of this writing there is no public API). > > The same goes for all the other keys captured by `ScrollPane` when it does not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys. I'm thinking still about what would be a good test. I could probably add a JUnit test for the behavior to see if it handles the keys correctly now, seeing that it acts on keys when it has focus, and leaves keys to bubble up when it doesn't. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2378263852 From arapte at openjdk.org Fri Sep 27 05:49:41 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 27 Sep 2024 05:49:41 GMT Subject: Integrated: 8297072: Provide gradle option to test a previously built SDK In-Reply-To: References: Message-ID: On Mon, 23 Sep 2024 15:48:00 GMT, Ambarish Rapte wrote: > #### Requirement: > We want to be able to test a JavaFX SDK built somewhere else other than on current machine or current repo on same machine. Which means we should be able to run the unit and system tests with a different JavaFX SDK. > > #### Change: > ##### Run tests using a specified JavaFX SDK: > - Introduce a property `TEST_JAVAFX_SDK_PATH` that points to the JavaFX SDK which was built elsewhere. > - Modify the paths generated by build.gradle to point to the path sepcified by `TEST_JAVAFX_SDK_PATH` > - When a `TEST_JAVAFX_SDK_PATH` is specified `-PTEST_ONLY=true` must also be specified. > > ##### Generate the JavaFX SDK bundle > - Generate the minimal JavaFX SDK bundle that is required to run the tests: We require content of the _build/sdk_ and _build/shims_ directories to achieve the same. > > > #### Verification: > ##### With a single machine: > 1. Create two local copies JavaFX repo, [repo1, repo2] > 2. Build sdk and shims in repo1. `gradle sdk shims` > 3. In repo2, run different tests as, >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**repo1/build** :base:test > 4. In repo1 run `gradle all` > 5. `javafx-sdk-shims.zip` file would be created under repo1/build. unzip it any `unzip-path` on machine > 6. In repo2, run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test > > ##### With 2 machines. > 1. Run `gradle all` on a machine1 > 2. Move build/javafx-sdk-shims.zip to machine2 and unzip to any `unzip-path` > 3. Run the tests by providing the `unzip-path` as TEST_JAVAFX_SDK_PATH >> gradle -PTEST_ONLY=true -PTEST_JAVAFX_SDK_PATH=**unzip-path** :base:test > > > #### Additional changes: > Additionally we observed that three unit tests failed because they access a specific path. A path that would no exists when JavaFX SDK is not built. > 1. Controls test: test.javafx.scene.control.ControlTest.testRT18097 > It required path: modules/javafx.controls/build/classes/java/main/javafx.controls/javafx > It is fixed by change on line 2811 > > 2. Graphics test: test.javafx.css.CssMetaDataTest.testRT18097 > It required path: modules/javafx.graphics/build/classes/java/main/javafx.graphics/javafx > It is fixed by change on line 2722 > > 3. Base test: test.com.sun.javafx.runtime.VersionInfoTest > It required path: build/module-lib/javafx.properties > VersionInfoTest is specific to the local build of JavaFX. So, It can be safely excluded when TEST_JAVAFX_SDK_PATH is specified. > It is fixed by change on line 2304 t... This pull request has now been integrated. Changeset: 7870a226 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/7870a226a21826e3979e314c0218d351b3cfb82f Stats: 71 lines in 1 file changed: 61 ins; 0 del; 10 mod 8297072: Provide gradle option to test a previously built SDK Reviewed-by: kcr, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1577 From jcorvel at gmail.com Fri Sep 27 11:42:32 2024 From: jcorvel at gmail.com (Johan Corveleyn) Date: Fri, 27 Sep 2024 13:42:32 +0200 Subject: Dead keys followed by space In-Reply-To: References: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> Message-ID: On Thu, Sep 26, 2024 at 10:37?AM Johan Corveleyn wrote: > > Thanks, and thank you Martin for filing the issue https://bugs.openjdk.org/browse/JDK-8340982. I'll try to create an account on openjdk.org to be able to watch the issue :-). Seems it's not that easy to get an account on bugs.openjdk.org, so never mind that ... I'll check in on the issue from time to time (and of course I keep an eye on this mailinglist anyway). I'm not expecting this to be fixed immediately of course, I suppose everyone here has lots of things on their plate, and lots of other priorities; and I have little to offer as contribution myself at the moment. In the meantime: does anybody have an idea for an elegant workaround for this (to have a TextField and PasswordField where ^+ just yields '^' on Windows + US International keyboard)? Injecting a Swing component for this is an option, but I'd like to know if there are others. Thanks, -- Johan From kcr at openjdk.org Fri Sep 27 13:07:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 27 Sep 2024 13:07:15 GMT Subject: RFR: 8340829: Generated API docs should clearly identify EA builds [v2] In-Reply-To: References: Message-ID: > This PR modifies the header and footer of the javadoc-generated API docs to add "DRAFT $VER-ea+$BLD" to clearly identify an ea build of the docs, and also to make it clear which build number the docs refer to. This matches was the JDK does. For GA builds, there will be no change to what we generate today. Since I had to add logic to filter the javadoc properties defined in `build.javadoc` to add the DRAFT message if not a GA build, I also changed the properties to not hard-code the major version of JavaFX, thus reducing the duplication. > > I ran three builds to test this, an ordinary developer build, an EA build, and a GA build as follows: > > #### Developer build > > Command line: > > gradle javadoc > > > Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-internal/ > > #### EA build > > Command line: > > gradle -PPROMOTED_BUILD_NUMBER=98 -PHUDSON_BUILD_NUMBER=1234 -PHUDSON_JOB_NAME=jfx-dev javadoc > > > Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-ea/ > > #### GA build > > Command line: > > gradle -PMILESTONE_FCS=true -PPROMOTED_BUILD_NUMBER=99 -PHUDSON_BUILD_NUMBER=4321 -PHUDSON_JOB_NAME=jfx-dev javadoc > > > Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-fcs/ Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address feedback ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1583/files - new: https://git.openjdk.org/jfx/pull/1583/files/71a0428b..2da1f291 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1583&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1583&range=00-01 Stats: 9 lines in 2 files changed: 5 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1583.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1583/head:pull/1583 PR: https://git.openjdk.org/jfx/pull/1583 From kcr at openjdk.org Fri Sep 27 13:07:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 27 Sep 2024 13:07:15 GMT Subject: RFR: 8340829: Generated API docs should clearly identify EA builds In-Reply-To: References: Message-ID: On Thu, 26 Sep 2024 21:33:10 GMT, Kevin Rushforth wrote: > This PR modifies the header and footer of the javadoc-generated API docs to add "DRAFT $VER-ea+$BLD" to clearly identify an ea build of the docs, and also to make it clear which build number the docs refer to. This matches was the JDK does. For GA builds, there will be no change to what we generate today. Since I had to add logic to filter the javadoc properties defined in `build.javadoc` to add the DRAFT message if not a GA build, I also changed the properties to not hard-code the major version of JavaFX, thus reducing the duplication. > > I ran three builds to test this, an ordinary developer build, an EA build, and a GA build as follows: > > #### Developer build > > Command line: > > gradle javadoc > > > Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-internal/ > > #### EA build > > Command line: > > gradle -PPROMOTED_BUILD_NUMBER=98 -PHUDSON_BUILD_NUMBER=1234 -PHUDSON_JOB_NAME=jfx-dev javadoc > > > Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-ea/ > > #### GA build > > Command line: > > gradle -PMILESTONE_FCS=true -PPROMOTED_BUILD_NUMBER=99 -PHUDSON_BUILD_NUMBER=4321 -PHUDSON_JOB_NAME=jfx-dev javadoc > > > Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-fcs/ In an offline comment, Iris noted three additional things that could be improved in the JavaFX docs relative to the JDK docs: 1. For EA docs, the JDK has a top "This specification change is not final and is subject to change..." banner, which is missing from the JavaFX EA docs. 2. The JDK docs adds an HTML comment in the bottom section with the full build identifier, which would be useful for the JavaFX docs to clearly identify which build (especially if there is ever a GA respin). 3. For GA docs, the "JavaFX NN" version number in the upper right is not vertically centered in the blue header bar, whereas it is vertically centered in the JDK docs. I have fixed 1 and 2, and will file a follow-on bug for 3 (it wasn't obvious how to do that one). I updated the generated docs on `cr.openjdk.org` in place. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1583#issuecomment-2379236961 From thiago.sayao at gmail.com Fri Sep 27 13:18:33 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 27 Sep 2024 10:18:33 -0300 Subject: Dead keys followed by space In-Reply-To: References: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> Message-ID: Johan, I guess you could use a TextFormatter<> to remove the extra space when there's a dead key character before. It would work as textField.setTextFormatter(new PasswordTextFilter()) public class PasswordTextFilter implements UnaryOperator { @Override public TextFormatter.Change apply(final TextFormatter.Change aT) { //logic to ignore the space if there's a dead key before } } Em sex., 27 de set. de 2024 ?s 09:42, Johan Corveleyn escreveu: > On Thu, Sep 26, 2024 at 10:37?AM Johan Corveleyn > wrote: > > > > Thanks, and thank you Martin for filing the issue > https://bugs.openjdk.org/browse/JDK-8340982. I'll try to create an > account on openjdk.org to be able to watch the issue :-). > > Seems it's not that easy to get an account on bugs.openjdk.org, so > never mind that ... I'll check in on the issue from time to time (and > of course I keep an eye on this mailinglist anyway). I'm not expecting > this to be fixed immediately of course, I suppose everyone here has > lots of things on their plate, and lots of other priorities; and I > have little to offer as contribution myself at the moment. > > In the meantime: does anybody have an idea for an elegant workaround > for this (to have a TextField and PasswordField where ^+ just > yields '^' on Windows + US International keyboard)? Injecting a Swing > component for this is an option, but I'd like to know if there are > others. > > Thanks, > -- > Johan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Fri Sep 27 14:34:16 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 27 Sep 2024 14:34:16 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one Message-ID: The standard across all platforms is: - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. The Windows glass code didn't implement the Space exception. This PR fixes that. On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. For some reason Windows 11 hides this setting well. To install a US International layout: - Go to Settings > Time & Language > Language & Region. - In the entry for English click on the three dots to the far right and select 'Language Options'. - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. - From the list select "United States - International". To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). ------------- Commit messages: - A dead key followed by Space generates a single character, not two Changes: https://git.openjdk.org/jfx/pull/1584/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1584&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340982 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1584.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1584/head:pull/1584 PR: https://git.openjdk.org/jfx/pull/1584 From andy.goryachev at oracle.com Fri Sep 27 15:40:16 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 27 Sep 2024 15:40:16 +0000 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: <30F9D967-7FBA-4407-BA0D-44EB691A4FC8@martinfox.com> References: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> <30F9D967-7FBA-4407-BA0D-44EB691A4FC8@martinfox.com> Message-ID: Hi Martin, Thanks for clarifications. You are right, in the example you provided it is difficult to alter the behavior of toggles in respect to the arrow keys using the traversal policy alone (but it is possible by adding an event filter to the toggle container and using the new FocusTraversal API or the good old requestFocus(), see [0]). I think this extreme example might be out of scope for this PR. It might be possible to eventually allow such scenarios by removing the explicit handling of the traversal keys by the controls' behaviors and instead installing appropriate traversal policies as you and John suggested earlier. The first thing is to enable said APIs. Thanks again for extremely helpful feedback and suggestions! -andy [0] https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/FocusPolicyResearch.java From: Martin Fox Date: Thursday, September 26, 2024 at 16:30 To: Andy Goryachev Cc: OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API Hi Andy, Glad to hear the TraversalEvent is gone. I?ll try go take a look at the new implementation next week. > There?s a case in the current control set that this API doesn?t cover. ToggleButtons intercept the arrow keys so they can implement a cyclic traversal policy among buttons in the ToggleGroup. They don?t assume that their Parent will do this for them. To reproduce this behavior this API would have to be extended so it can first ask the focusOwner where to traverse to before moving on to the Parent. I don't think this is correct. The traversal policy API are sufficient to be able to determine the right node because both parent and the node it wants to traverse from are passed as arguments (i.e. select()). When the policy determines it's time to step out of the control, the policy has findXX() methods. Sorry I was so terse in my first message. I?ll try to explain this more clearly. Currently you can create three ToggleButtons, add them to the same ToggleGroup, shove them into any old container (like a VBox), and they will exhibit cyclical traversal behavior using the arrow keys. The ToggleButtonBehavior is directly intercepting the arrow keys and implementing the cycle. The parent VBox knows nothing about any of this. If you add a plain old Button to the same VBox so it?s a sibling of the toggles the ToggleButtons will still cycle among themselves and the plain Button won?t be part of the cycle. If I understand the proposal and code correctly (and that?s a big ?if?) we can?t re-implement this exact behavior with the new API. If one of the ToggleButtons is the focus owner the traversal engine will start by consulting the parent VBox which knows nothing. To get the current cyclic behavior the traversal engine would have to start by asking the ToggleButton itself what to do. And I imagine that would require extending this API. I would be fine just keeping the current implementation and not altering this proposal to cover this case. Since ToggleButtons don?t have children there?s no harm in them intercepting the arrow keys. I thought I should mention it as an interesting traversal behavior in the existing code. Did I provide satisfactory answers, or there are other things that you find problematic? Nope, I?m good. Many thanks. Martin References [0] InputMap https://github.com/andy-goryachev-oracle/Test/tree/main/doc/InputMap From: Martin Fox Date: Tuesday, September 24, 2024 at 13:30 To: Andy Goryachev Cc: OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API Andy, Glad to finally see a proposal for opening up traversal. Long overdue. There?s a case in the current control set that this API doesn?t cover. ToggleButtons intercept the arrow keys so they can implement a cyclic traversal policy among buttons in the ToggleGroup. They don?t assume that their Parent will do this for them. To reproduce this behavior this API would have to be extended so it can first ask the focusOwner where to traverse to before moving on to the Parent. (And looking at the code I think there?s yet another bug where events are consumed when they should not be. Sigh). The proposal doesn?t provide any use cases for the TraversalEvent. It also doesn?t specify the initial target of the event or how it should be handled. I had to look in the sources to see what it?s being used for and that (a) it?s being fired at the new focus owner and (b) it?s a bad idea to consume it. It looks more like information you want to broadcast to a set of listeners rather than a message to be acted on. If nothing else the bounds should be removed from this event since that?s a very specific piece of info that only the ScrollPaneSkin wants. I haven?t mapped out the details but I?m pretty sure it can figure out the bounds itself. This proposal should give some quick background on how traversal key events are handled, specifically that controls should let the key events bubble up to the Scene to invoke traversal. And if the traversal keys are always going to be consumed by the Scene that should also be mentioned. There?s been a few comments suggesting the traversal key events should not be consumed if the focusOwner doesn?t change. Unfortunately that would break Popups which have an, um, interesting event architecture. And I don?t want to introduce yet another instance where events need to be consumed under specific conditions or things break down (I?m currently tracking down bugs where ESCAPE is consumed when it shouldn?t be or not consumed when it should be). We should figure out what these clients need and ensure it?s delivered to them in a reliable way. Perhaps when traversal ends we could fire an event at the Scene with all the details? The sample code is problematic since we really don?t want controls to kick off traversal themselves unless they absolutely have to. That caveat should probably precede the code. If you must provide some sample code please make sure it checks the modifier state on the KeyEvent. (There really should be a central API for mapping a KeyEvent to a TraversalDirection but that would be a different proposal.) If we provide pre-packaged traversal policies we?ll need to provide multiple variants of CYCLIC. A menu bar cycles horizontally with the arrow keys and Tab but not vertically. According to the w3c a toggle button group should cycle with all the arrow keys but not with the Tab key. And there?s probably one or two more combinations in the current control set and w3c accessibility guidelines. Martin On Sep 24, 2024, at 11:57?AM, Andy Goryachev wrote: I fully agree with Martin here. -andy From: Martin Fox Date: Wednesday, September 18, 2024 at 11:49 To: John Hendrikx Cc: Andy Goryachev , OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API John, Sorry I didn?t respond to this thread earlier. I?ve been looking at the code and bug database trying to work backward to a problem statement. The bug reports cited in the PR are light on details so I?m trying to come up with a more concrete set of use cases to consider. Currently I?m failing to see the benefit of a traversal event model. - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). It doesn?t really matter whether the control is capturing the key event and invoking the traversal engine directly or firing off a TraversalEvent. The problem is that the control is processing the key event in the first place. You?re talking about something that happens before traversal is even initiated. It?s unfortunate that the code snippet in the proposal shows a control doing a direct mapping from KeyCodes to traversal calls. That?s not how the current system is intended to work. There?s already a dispatcher at the Scene level that processes KeyEvents and invokes the traversal machinery so controls should just let the traversal keys bubble up. There are exceptions to this throughout the code which I would like to get a better handle on since I can?t tell if they?re bugs or truly necessary exceptions. Once the system has determined that it?s time for traversal it needs to map from a KeyEvent to a direction and type. I can see where providing a centralized API for doing this could be of benefit but I?m not sure that has anything to do with this PR or the concept of TraversalEvents. This is also a decision made before traversal is initiated. You give some examples of customizing traversal in various ways. From what I can tell all of them can be accomplished using this PR with maybe one exception that I?ll get to when I respond to Andy?s proposal. In other cases I can?t tell if a TraversalEvent would provide a cleaner implementation because I don?t understand how they would work. For example, one could imagine a system where a TraversalEvent is fired by the Scene and expected to bubble back up to the Scene which will then utilize the existing centralized engines to actually perform the traversal. But one could also imagine a system where the Scene fires a TraversalEvent and the nodes act on them directly as it bubbles up. I?m not sure what you have in mind. It would be nice to see some examples of how a TraversalEvent would move through the system in various scenarios particularly when traversing laterally. Martin On Sep 17, 2024, at 11:05?PM, John Hendrikx wrote: Andy, As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. --John On 18/09/2024 01:09, Andy Goryachev wrote: Dear John: You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. Thank you -andy From: John Hendrikx Date: Saturday, September 14, 2024 at 09:41 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Proposal: Focus Traversal API Hi Andy, First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. On 14/09/2024 00:17, Andy Goryachev wrote: Dear John, Everyone: Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: 1. move the focus traversal logic away from the components and into the Scene 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents 3. (more) standard policies 4. using CSS (there is of course more topics in your response, but let me start with the 4 above) #1 I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? There's two things here. 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. #2 This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? #3 One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). #4 The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: - I define the container hierarchy (VBox, HBox, which children go where) - I set a style name - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? -- There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. Also I think this can be implemented gradually. Here's a potential plan: 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... Public API: Limited to a new Event 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys Public API: none 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are Public API: none Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. 4. Expose policy property/properties on Parent Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. Public API: new properties on Parent 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. Benefit: less work for control implementors (although they could just "copy" said code) Public API: Maybe some methods in Node, or some kind of static helper. 6. CSS styleable properties If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). Public API: Nothing in Java, but document as CSS properties --John Thank you, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, September 11, 2024 at 19:05 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Focus Traversal API Hi Andy / List, I've given this some thought first, without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ## KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: - OPEN This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: Node from = ... switch (((KeyEvent)event).getCode()) { case UP: FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); event.consume(); break; case DOWN: // or use the convenience method FocusTraversal.traverseDown(from); event.consume(); break; } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: Node from = ... Node result = switch(traversalEvent.getEventType()) { case TraversalEvent.UP -> FocusTraversals.findUp(from); case TraversalEvent.DOWN -> FocusTraversals.findDown(from); // etc } if (result != null) { result.requestFocus(); traversalEvent.consume(); } Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Sep 27 16:59:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 27 Sep 2024 16:59:11 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v14] In-Reply-To: References: Message-ID: <9SORzV74ISHK7pcJKH-L79slA-bz_1FugfUIvVpC6II=.1add8be3-71fc-451b-8d55-71d1a03a738e@github.com> > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - review comments - fixed directories - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - hide impl. detail - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - removed duplicate files - moved to apps, review comments - bsd license for sample code - ... and 12 more: https://git.openjdk.org/jfx/compare/7870a226...198206f8 ------------- Changes: https://git.openjdk.org/jfx/pull/1524/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=13 Stats: 39692 lines in 207 files changed: 39669 ins; 9 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Fri Sep 27 17:20:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 27 Sep 2024 17:20:44 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus In-Reply-To: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> References: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> Message-ID: On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote: > This change modifies `ScrollPaneBehavior` to only consume keys that are targetted at it. As `KeyEvent`s are in almost all cases only intended for the targetted node (as visually that's where the user expects the keyboard input to go, as per normal UI rules) consuming key events that bubble up is simply incorrect. When the `ScrollPane` is focused directly (it has the focused border) then it is fine for it to respond to all kinds of keys. > > In FX controls normally there is no need to check if a `Control` is focused (although they probably should **all** do this) as they do not have children that could have received the Key Events involved, and Key Events are always sent to the focused Node. When `ScrollPane` was developed this was not taken into account, leading to it consuming keys not intended for it. > > This fixes several unexpected problems for custom control builders. A custom control normally benefits from standard navigation out of the box (TAB/shift+TAB) and directional keys. However, this breaks down as soon as this custom control is positioned within a `ScrollPane`, which is very surprising behavior and not at all expected. This makes it harder than needed for custom control developers to get the standard navigation for the directional keys, as they would have to specifically capture those keys before they reach the `ScrollPane` and trigger the correct navigation action themselves (for which as of this writing there is no public API). > > The same goes for all the other keys captured by `ScrollPane` when it does not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys. Would it be possible to provide an SCCE that clearly illustrates the problem? This can be a base for a unit test in the PR. Another question - do you think it might make sense to wait until we get the traversal policy API #1555 and instead install a policy by default which is identical to the current behavior, but at the same time it can be disabled or changed to a different policy? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2379733523 From andy.goryachev at oracle.com Fri Sep 27 17:24:55 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 27 Sep 2024 17:24:55 +0000 Subject: [External] : Re: Proposal: Focus Traversal API In-Reply-To: References: <4EDE1D14-915E-4CD9-8976-E1B667727C2A@martinfox.com> Message-ID: Dear John: Have I answered all your concerns, or some sticky issues still remain? Wanted to share a couple of thoughts that appeared during the discussion: 1. it might still be possible to set the traversal policy via CSS, accepting either a predefined token (DEFAULT, ...) or use the FQCN class name. 2. speaking of JDK-8340852: instead of modifying key mapping, would it be better instead to simply install the policy on the ScrollPane which is identical to the current behavior, and give the app developers ability to change that? This way we'll preserve the backward compatibility and also enable the new behavior by setting the policy to null? What do you think? -andy From: openjfx-dev on behalf of John Hendrikx Date: Thursday, September 26, 2024 at 13:32 To: openjfx-dev at openjdk.org Subject: Re: [External] : Re: Proposal: Focus Traversal API On 24/09/2024 23:58, Andy Goryachev wrote: Dear Martin: Thank you for a very thoughtful and constructive response! It will take me some time to digest, but I do want to mention some thoughts I had while listening to the discussion earlier. 1. TraversalEvent You are right, it appears there might be a few or no use cases for this event as far as app code is concerned. Looking at the code, it was a replacement for internal TraversalEngine.TraverseListener utilized by several skins. It might be possible to remove it and instead rely on listening to Scene.focusOwnerProperty, at the expense of complicating the skins. Is this a good idea? Will removing the event make it more difficult to write a custom component/skin? I think it is worth looking into this. API to make things "easier" to implement now will bite you later (see CSS and its binary CSS load/save API that didn't really needed to be public...) 2. The fact that some policies depend on the state of the control basically negates the idea of standard set of policies encoded in an enum. I really think exposing policies is a bit overkill, and should be considered later if at all. Controls just want to be able to use the standard traversal mechanism, which will not be such a pain to get once https://bugs.openjdk.org/browse/JDK-8340852 is fixed (as you can just let it bubble up). Controls that really want something different to happen can take the extra steps of adding KeyEvent handlers, consuming those only when they don't want the standard navigation from Scene. I don't think it should be a goal to have all the complex navigation cases possible with FX controls be possible with a new API. You can already do whatever navigation you want by finding the Node you need and focusing it. The problem has always been how to get the **default** navigation for your custom control (which will cover the vast majority of cases already) -- this was hard because events wouldn't bubble up to Scene properly, which necessitated installing your own Key handlers, which then necessitates having access to the standard focus changing code... It is a cascade of problems for which we're now building a "workaround", which IMHO is not really needed once the cause of this problem is fixed. 3. Controls may need to intercept traversal keys and fire off the traversal, for example, TAB on a read-only TextArea should traverse, but should insert the tab character into the editable TextArea. (I would imagine this can be also implemented by not consuming events if they effect no change in the control, but that is a different story). That's really how it should be. Controls should preferably always delegate so there is no navigation code all over the place. --John 4. It might be possible for controls like ToggleButton to set its own traversal policy instead intercepting KeyEvents (which is the current way of dealing with conditional traversal). I would imagine this being done as a separate enhancement though. Thanks, -andy From: Martin Fox Date: Tuesday, September 24, 2024 at 13:30 To: Andy Goryachev Cc: OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API Andy, Glad to finally see a proposal for opening up traversal. Long overdue. There?s a case in the current control set that this API doesn?t cover. ToggleButtons intercept the arrow keys so they can implement a cyclic traversal policy among buttons in the ToggleGroup. They don?t assume that their Parent will do this for them. To reproduce this behavior this API would have to be extended so it can first ask the focusOwner where to traverse to before moving on to the Parent. (And looking at the code I think there?s yet another bug where events are consumed when they should not be. Sigh). The proposal doesn?t provide any use cases for the TraversalEvent. It also doesn?t specify the initial target of the event or how it should be handled. I had to look in the sources to see what it?s being used for and that (a) it?s being fired at the new focus owner and (b) it?s a bad idea to consume it. It looks more like information you want to broadcast to a set of listeners rather than a message to be acted on. If nothing else the bounds should be removed from this event since that?s a very specific piece of info that only the ScrollPaneSkin wants. I haven?t mapped out the details but I?m pretty sure it can figure out the bounds itself. This proposal should give some quick background on how traversal key events are handled, specifically that controls should let the key events bubble up to the Scene to invoke traversal. And if the traversal keys are always going to be consumed by the Scene that should also be mentioned. There?s been a few comments suggesting the traversal key events should not be consumed if the focusOwner doesn?t change. Unfortunately that would break Popups which have an, um, interesting event architecture. And I don?t want to introduce yet another instance where events need to be consumed under specific conditions or things break down (I?m currently tracking down bugs where ESCAPE is consumed when it shouldn?t be or not consumed when it should be). We should figure out what these clients need and ensure it?s delivered to them in a reliable way. Perhaps when traversal ends we could fire an event at the Scene with all the details? The sample code is problematic since we really don?t want controls to kick off traversal themselves unless they absolutely have to. That caveat should probably precede the code. If you must provide some sample code please make sure it checks the modifier state on the KeyEvent. (There really should be a central API for mapping a KeyEvent to a TraversalDirection but that would be a different proposal.) If we provide pre-packaged traversal policies we?ll need to provide multiple variants of CYCLIC. A menu bar cycles horizontally with the arrow keys and Tab but not vertically. According to the w3c a toggle button group should cycle with all the arrow keys but not with the Tab key. And there?s probably one or two more combinations in the current control set and w3c accessibility guidelines. Martin On Sep 24, 2024, at 11:57?AM, Andy Goryachev wrote: I fully agree with Martin here. -andy From: Martin Fox Date: Wednesday, September 18, 2024 at 11:49 To: John Hendrikx Cc: Andy Goryachev , OpenJFX Subject: Re: [External] : Re: Proposal: Focus Traversal API John, Sorry I didn?t respond to this thread earlier. I?ve been looking at the code and bug database trying to work backward to a problem statement. The bug reports cited in the PR are light on details so I?m trying to come up with a more concrete set of use cases to consider. Currently I?m failing to see the benefit of a traversal event model. - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). It doesn?t really matter whether the control is capturing the key event and invoking the traversal engine directly or firing off a TraversalEvent. The problem is that the control is processing the key event in the first place. You?re talking about something that happens before traversal is even initiated. It?s unfortunate that the code snippet in the proposal shows a control doing a direct mapping from KeyCodes to traversal calls. That?s not how the current system is intended to work. There?s already a dispatcher at the Scene level that processes KeyEvents and invokes the traversal machinery so controls should just let the traversal keys bubble up. There are exceptions to this throughout the code which I would like to get a better handle on since I can?t tell if they?re bugs or truly necessary exceptions. Once the system has determined that it?s time for traversal it needs to map from a KeyEvent to a direction and type. I can see where providing a centralized API for doing this could be of benefit but I?m not sure that has anything to do with this PR or the concept of TraversalEvents. This is also a decision made before traversal is initiated. You give some examples of customizing traversal in various ways. From what I can tell all of them can be accomplished using this PR with maybe one exception that I?ll get to when I respond to Andy?s proposal. In other cases I can?t tell if a TraversalEvent would provide a cleaner implementation because I don?t understand how they would work. For example, one could imagine a system where a TraversalEvent is fired by the Scene and expected to bubble back up to the Scene which will then utilize the existing centralized engines to actually perform the traversal. But one could also imagine a system where the Scene fires a TraversalEvent and the nodes act on them directly as it bubbles up. I?m not sure what you have in mind. It would be nice to see some examples of how a TraversalEvent would move through the system in various scenarios particularly when traversing laterally. Martin On Sep 17, 2024, at 11:05?PM, John Hendrikx wrote: Andy, As you're not responding to any of the suggestions or any of my questions, but are only re-iterating points that I believe are not going to be a benefit to the long term viability of FX, I see no point in continuing the discussion further. --John On 18/09/2024 01:09, Andy Goryachev wrote: Dear John: You do bring a lot of good points, no doubt. And I do agree with a lot of the suggestion, but I still want to emphasize two points: 1. The backward compatibility should not be dismissed that easily. There is a number of existing applications out there and we do not want to break them. Whether the behavior is specified or not is irrelevant, we do not want to cause mayhem from the customers and developers alike whose keyboard navigation suddenly changed. 2. I question the cost benefit analysis of the redesign idea. While I agree with you that it might help with some unusual cases, the overall benefit is rather limited. The benefit of the proposed solution is, in my opinion, far greater: it allows for custom traversal policies (a feature that has been requested multiple times) and enables focus traversal from custom components, something of a lesser value, but still important. Exposing the existing APIs is a relatively cheap solution that will give us two features at nearly zero cost. On the other hand, I doubt that our team, or yourself, are willing commit substantial development effort to redesign the thing to use events. Which brings me to the choice I mentioned earlier: realistically, we have a choice of providing two requested features soon, or never. I would also encourage other members of the development community to voice their opinion on the subject, perhaps there is something else we can do to move forward. Thank you -andy From: John Hendrikx Date: Saturday, September 14, 2024 at 09:41 To: Andy Goryachev , openjfx-dev at openjdk.org Subject: [External] : Re: Proposal: Focus Traversal API Hi Andy, First let me say that when it comes to designing an API, you really need to take the time to think the solution through. The current internal solution was probably kept internal for exactly that reason, insufficient time to work out the kinks and look into alternatives. An API is almost impossible to change later, so the general rule is that if you're not sure about an API, then its better to have no API. This is why I think it is important that we first look for what the API should look like, then worry about how this can be fitted onto JavaFX. Making concessions related to the current implementation before having a clear idea of how the API should preferably work is not part of that. You start making concessions only when it turns out the preferred design would encounter unresolvable problems in the current implementation. Since I think there is very little public API related to focus traversal, nor is there any specification of how it currently works, I think we have a lot of room to maneuver. This is why I think we should first reach a consensus on the API, then look how it can be fitted on top of FX. Sometimes a well thought out API also is a natural fit, and may be easier to migrate to than you think. On 14/09/2024 00:17, Andy Goryachev wrote: Dear John, Everyone: Thank you for a thoughtful response! Some of the ideas you described definitely deserve further consideration. If I were to summarize: 1. move the focus traversal logic away from the components and into the Scene 2. re-implement focus traversal through TraversalEvents rather than responding directly to KeyEvents 3. (more) standard policies 4. using CSS (there is of course more topics in your response, but let me start with the 4 above) #1 I generally like this idea. In some sense it is already how things work internally, but without the ability to customize that (i.e. by introducing custom traversal keys, or removing existing ones). The downside is substantial: not only we'd need to re-design the whole of the focus traversal, but also rework the existing control's behaviors. Did I mention the risk of regression, given the absence of comprehensive behavioral tests? There's two things here. 1. There is no need to re-design the whole focus traversal. The old internal system can be gradually replaced (it works by directly consuming KeyEvents after all). 2. Regression. When nothing is specified, and the fact that controls **ought** to work like other common controls in different UI toolkits, is it a regression when focus traversal works the same as those other platforms, even if it may be a regression from the point of view of FX? For example, a Spinner will currently react to any mouse key, where as other common toolkits only react to the left mouse button. Is it a regression if FX is adjusted to also only react to the left mouse button? It's not specified anywhere. I think we have sufficient space to maneuver here as long as we are not making focus traversal completely different from how it commonly works in UI's. Can there be regressions versus the current (unspecified) implementation? Sure, there can be. Is that necessarily bad? That depends. If the new focus traversal works like it does on all other toolkits, then no, it is more of a bug fix. Did we break something with the new implementation? That's always possible, but will then be fixed as soon as it is reported. #2 This may or may not be an integral part of #1. Potentially, it allows for injection of events by the application code, as well as simplifies creation of complex custom controls. The latter becomes possible with the original proposal, so net benefit is limited to the first part, I think. I think TraversalEvents are quite central to making this an API that will really stand the test of time. It leverages the existing event system, giving you all the power that comes with it. You did not answer my question about the TraversalEvents in your design. Why are the Events when they can't be triggered, filtered or consumed? #3 One obvious possibility is to enable creation of a simple policy based on a list of Nodes. I must mention one use case that is impossible to cover with pre-defined policy is one where navigation depends on some state. Such a policy must be implemented programmatically. I think one property should be sufficient - I am strongly against adding two properties here. Programmatic escapes can always be achieved by responding directly to a TraversalEvent. I think however this should be a rare case, and standard policies should really cover almost all use cases. It may be a gap that should be investigated, and the API adjusted for (usually the "exceptions" are well worth looking into to see if with a tweak they can't become "standard"). As for being "strongly against" having two properties -- that's an odd stance to take without motivating it. It could also be rolled into "one" where the Policy is a record with the two values, but I think we're getting ahead of ourselves here. First the API, then the implementation. I do think however there is great value in having the Logical and Directional navigation split. Often you'll only want to replace one of these with a custom policy (or a different standard policy), so that the other navigation method can be used to escape the control. For example, a Toolbar could be tabbed in an out of (using Logical navigation) while the Directional navigation is cyclic (and thus can't be used to escape the control's context). #4 The idea of using CSS to specify traversal policy seems wrong to me: the CSS defines the presentation aspects (styles) rather than behavioral ones. I know it is possible to set custom skins and the corresponding behavior via CSS, and we know why (skins define the appearance), but we should not go beyond that, in my opinion. I see no problem styling such properties. They're FX properties, and it would be very convenient to style them to globally alter how focus works, instead of having to rely on, say, Builders or Factories for controls where traversal policies can be applied. There are also already properties that don't only influence the look of controls. "-fx-skin" being the most obvious one, but there is also "-fx-focus-traversable", "-fx-context-menu-enabled", "-fx-block-increment", "-fx-unit-increment", "-fx-pannable", "-fx-initial-delay", "-fx-repeat-delay", "-fx-collapsible", "-fx-show-delay", "-fx-show-duration", "-fx-hide-delay", and probably more. Aside from "-fx-skin" none of these properties have a visual impact, but instead alter behavior. Note: I'm not saying this needs to be there immediately. I just want to make sure we're not closing off this direction, as again, it would be a huge hassle to do this programmatically. In "code" the only things I usually do on my controls are the following: - I define the container hierarchy (VBox, HBox, which children go where) - I set a style name - I set anything that unfortunately cannot be CSS styled (things like ALWAYS, SOMETIMES, NEVER grow policies, Grid sizes, etc, things that are clearly "visual" but still can't be styled). All the rest I don't touch, or want to touch. Having to select a traversal policy for every control of type X I create is just cumbersome and unnecessary. There will be a call then to set this "globally", and then there will be the question, do we make something custom with many limitations because it doesn't fit our conceptions of what (FX) CSS is for (ie, not style, but only *visual* style) or do we just expose these properties as Styleable leveraging an existing powerful system with almost zero effort? -- There is one more aspect of the problem that I think we should consider. The current proposal does not change the implementation in any material way, nor does it change the behavior, thus can be done quickly. The benefit everyone gets from it is ability to trigger focus traversal and to control it via custom policies. Any other solution will require resources and the bandwidth we currently don't have, which means the probability of it being added to FX is virtually zero. Let me emphasize, I am not against attempting to discuss or implement the best possible solution, but we should be aware of the limitations of the reality we live in. "Quickly" and API's are incompatible with each other. There is nothing worse than exposing an API quickly, which then becomes a burden on the system -- I think the current CSS API is a prime example of where "quickly" has gone wrong, costing us tremendous amounts of effort to make even minor changes to it. I urge you to ignore the current implementation, think thoroughly how (in an ideal world) you would want such an API to work (from a user perspective, not from an implementor's perspective) and only then see how this could be made to fit into JavaFX. This is exactly what I did. I did not look at the implementation, although I'm aware of some of it. I looked at how I as a user of FX am building applications, the struggles I have with it currently, (with controls for example "eating" KeyEvents), and how I would like to be able to adjust focus traversal. Do I want to respond to "KeyCode.LEFT" or do I want to respond to "TraversalEvent.LEFT"? Do I also need to respond to "KeyCode.NUM_PAD_LEFT"? These things should be abstracted, and preferably I should just be able to choose from common navigation standards. And when I do want to change such a standard, in 99% of the cases that will be the case for all similar controls in my application. How do I do such things currently if I want to change something for all controls in my application? I use CSS. Also I think this can be implemented gradually. Here's a potential plan: 1. Have Scene listen to unused KeyEvents and translate them to TraversalEvents Benefit: gives custom controls a way to respond to keyboard based navigation in a platform agnostic way; this probably already removes the biggest roadblock for custom controls... Public API: Limited to a new Event 2. Start converting existing controls to listen to TraversalEvent instead of KeyEvent This hits a lot of controls, but should be relatively easy to do, and it can be all kept internal for now. It can be done in a few batches. Benefit: for each control converted, user can now programmatically trigger focus changes, and by overriding things at Scene level can completely change navigation keys Public API: none 3. Implement a number of standard policies internally (OPEN, CONFINED, CYCLIC, IGNORED) Convert any controls that could use these as their default, removing any custom logic if it happens to match one of the defaults. Benefit: less code to maintain and debug, gives us experience with which policies make sense and where the gaps are Public API: none Order: It is possible to do this before 2, and so some of the control conversions could just consist of removing their custom logic, and selecting a standard policy. 4. Expose policy property/properties on Parent Any controls that are not using a custom policy anymore (of type IGNORED) can now be user adjusted. We don't have to guarantee that each policy makes sense for each control. Changing a default IGNORED policy to a standard one will change the behavior (as intended) but it need not be a "complete" behavior that users like. This is not FX's problem, and can be improved upon later. Benefit: users can now change policies on any existing control, even ones with a custom policy; many of the controls may support a switch between OPEN, CONFINED and CYCLIC out of the box. Public API: new properties on Parent 5. Perhaps expose some helpful tools to calculate the "next" Node for a given traversal option. This can be done at any stage, and can be considered completely separate. It is IMHO a relatively low priority need. Benefit: less work for control implementors (although they could just "copy" said code) Public API: Maybe some methods in Node, or some kind of static helper. 6. CSS styleable properties If we really want to give power to our users, and impress them with a flexible focus traversal API, then make these properties styleable. Benefit: allow users to pick any control, and set is policy globally or within a subset of controls (ie. dialogs, popups, etc). Public API: Nothing in Java, but document as CSS properties --John Thank you, -andy From: openjfx-dev on behalf of John Hendrikx Date: Wednesday, September 11, 2024 at 19:05 To: openjfx-dev at openjdk.org Subject: Re: Proposal: Focus Traversal API Hi Andy / List, I've given this some thought first, without looking too much at the proposal. In my view, focus traversal should be implemented using events, and FX should provide standard handling of these events controlled with properties (potentially even CSS stylable for easy mass changing of the default navigation policy). ## KeyEvent and TraversalEvent separation I think the cleanest implementation would be to implement a KeyEvent listener on Scene that takes any unused KeyEvents, checks if they're considered navigation keys, and converts these keys to a new type of event, the TraversalEvent. The TraversalEvent is then fired at the original target. The TraversalEvent is structured into Directional and Logical sub types, and has leaf types UP/DOWN/LEFT/RIGHT and NEXT/PREVIOUS. Scene is the logical place to handle this as without a Scene there is no focus owner, and so there is no point in doing focus traversal. This separation of KeyEvents into TraversalEvents achieves the following: - User can decide to act on **any** key, even navigation keys, without the system interfering by consuming keys early, unexpectedly or even consuming these keys without doing anything (sometimes keys get consumed that don't actually change focus...). The navigation keys have many possible dual purposes, and robbing the user of the opportunity to use them due to an overzealous component interpreting them as traversal keys is very annoying. Dual purposes include for example cursor control in TextField/TextArea, Scrollbars, etc. The user should have the same control here as these FX controls have. - Scene is interpreting the KeyEvents, and this interpretation is now controllable. If I want a Toolbar (or the whole application) to react to WASD navigation keys, then installing a KeyEvent handler at Scene level or at any intermediate Parent level that converts WASD to UP/LEFT/DOWN/RIGHT Traversal events would affect this change easily. - The separation also allows to block Focus Traversal only, without blocking the actual Keys involved. If I want to stop a Toolbar from reacting to LEFT/RIGHT, but I need those keys higher up in the hierarchy, then I'm screwed. With the separation, the key events are unaffected, and I can block Toolbars from reacting specifically to traversal events only. ## Traversal Policy Properties on Parent I think FX should provide several policies out of the box, based on common navigation patterns. The goal here is to have policies in place that cover all use cases in current FX provided controls. This will provide a good base that will cover probably all realistic work loads that custom controls may have. The goal is not to support every esoteric form of navigation, instead an escape hatch will be provided in the form of disabling the standard navigation. In order to achieve this, I think Parent should get two new properties, which control how it will react to Directional and Logical navigation. These will have default values that allow navigation to flow from Node to Node within a Parent and from Parent to its Parent when navigation options in a chosen direction are exhausted within a Parent. Custom controls like Combo boxes, Toolbars, Button groups, etc, can change the default provided by a Parent (similar to how some controls change the mouse transparent flag default). These two properties should cover all realistic needs, and IMHO should be considered to be CSS stylable in the future to allow easy changing of default policies of controls (ie. want all Toolbars to react differently to navigation keys, then just style the appropriate property for all toolbars in one go). Parent will use these properties to install an event handler that reacts to TraversalEvents (not KeyEvents). This handler can be fully disabled, or overridden (using setOnTraversalEvent). - logicalTraversalPolicy - directionalTraversalPolicy The properties can be set with a value from a TraversalPolicy enum. I would suggest the following options: - OPEN This policy should be the default policy for all Parents. It will act and consume a given TraversalEvent only when there is a suitable target within its hierarchy. If there is no suitable target, or the target would remain unchanged, the event is NOT consumed and left to bubble up, allowing its parent(s) to act on it instead. - CONFINED This policy consumes all TraversalEvents, regardless of whether there is something to navigate to or not. This policy is suitable for controls that have some kind of substructure that we don't want to accidentally exit with either Directional or Logical navigation. In most cases, you only want to set one of the properties to CONFINED as otherwise there would be no keyboard supported way to exit your control. This is a suitable policy for say button groups, toolbars, comboboxes, etc. - CYCLIC Similar to CONFINED but instead of stopping navigation at the controls logical boundaries, the navigation wraps around to the logical start. For example, when were positioned on the right most button in a button group, pressing RIGHT again would navigate to the left most button. - IGNORED This is similar to the mouseTransparent property, and basically leaves the TraversalEvent to bubble up. This policy allows you to completely disable directional and/or logical navigation for a control. Useful if you want to install your own handler (the escape hatch) but still want to keep either the default directional or logical navigation. Possible other options for this enum could include a version that consumes all TraversalEvents (BLOCK) but I don't see a use for it at the moment. There may also be variants of CONFINED and CYCLIC that make an exception for cases where there is only a single choice available. A ButtonGroup for example may want to react differently depending on whether it has 0, 1 or more buttons. Whether these should be enshrined with a custom enum value, or perhaps a flag, or just left up to a custom implementation is something we'd need to decide still. ## Use Cases 1) User wants to change the behavior of a control from its default to something else (ie. a Control that is CYCLIC can be changed to OPEN or CONFINED) Just call the setters with the appropriate preferred policy. This could be done in CSS for maximum convenience to enable a global change of all similar controls. 2) User wants to act on Traversal events that the standard policy leaves to bubble up Just install a Traversal event handler either on the control or on its parent (depending on their needs). A potential action to an unused Traversal event could be to close a Dialog/Toast popup, or a custom behavior like selecting the first/last item or next/previous row (ie. if I press "RIGHT" and there is no further right item, a user could decide to have this select the first item again in the current Row or the first item in the **next** Row). 3) User wants to do crazy custom navigation Set both policies to IGNORED, then install your own event handler (or use the setOnTraversalHandler to completely override the handler). Now react on the Traversal events, consuming them at will and changing focus to whatever control you desire. 4) User wants to change what keys are considered navigation keys Install event handler on Scene (or any intermediate Parent) for KeyEvents, interpret WASD keys as UP/LEFT/DOWN/RIGHT and sent out a corresponding Traversal event 5) User wants to use keys that are considered navigation keys for their own purposes Just install a KeyEvent handler as usual, without having to worry that Skins/Controls eat these events before you can get to them 6) User wants to stop a control from reacting to traversal events, without filtering navigation keys completely With the separation of unconsumed KeyEvents into TraversalEvents, a user can now block only the latter to achieve this goal without having to blanket block certain KeyEvents. ----- About the Proposal: I think the Goals are fine as stated, although I think we differ on what the Traversal events signify. I think CSS support should be considered a possible future goal. The proposal should therefore take into account that we may want to offer this in the future. Motivation looks okay. > The focus traversal is provided by the FocusTraversal class which offers static methods for traversing focus in various directions, determined by the TraversalDirection enum. I think these methods don't need to be exposed with a good selection of standard TraversalPolicy options. After all, there are only so many ways that you can do a sensible navigation action without confusing the user, and therefore I think these policy options will cover 99% of the use cases already. For the left over 1% we could **consider** providing these focus traversal functions as a separate public API, but I would have them return the Node they would suggest, and leave the final decision to call requestFocus up to the caller. Initially however I think there is already more than enough power for custom implementations to listen to Traversal events and do their own custom navigation. If it is not similar to one of the standard navigation options, the traverseUp/Down functions won't be of much use then anyway. About your typical example: Node from = ... switch (((KeyEvent)event).getCode()) { case UP: FocusTraversal.traverse(from, TraversalDirection.UP, TraversalMethod.KEY); event.consume(); break; case DOWN: // or use the convenience method FocusTraversal.traverseDown(from); event.consume(); break; } I think this is not a good way to deal with events. 1) The event is consumed regardless of the outcome of traverse. What if focus did not change? Should the event be consumed? 2) This is consuming KeyEvents directly, robbing the user of the opportunity to act on keys considered "special" by FX. 3) This code is not only consuming KeyEvents directly, but also deciding what keys are navigation keys. So I think this example code should be different. However, first I expect that in most cases, configuring a different traversal policy on your Parent subclass will already be sufficient in almost all cases (especially if we look at FX current controls and see if the suggested policies would cover those use cases). So this code will almost never be needed. However, in the event that you need something even more specific, you may consider handling Traversal events directly. In which case the code should IMHO look something like this: Node from = ... Node result = switch(traversalEvent.getEventType()) { case TraversalEvent.UP -> FocusTraversals.findUp(from); case TraversalEvent.DOWN -> FocusTraversals.findDown(from); // etc } if (result != null) { result.requestFocus(); traversalEvent.consume(); } Note that the above code leaves the final decision to call requestFocus up to the caller. It also allows the caller to distinguish between the case where there is no suitable Node in the indicated direction and act accordingly. This allows it to NOT consume the event if it prefers its Parent to handle it (if the control doesn't want CYCLIC or CONFINED style navigation). It also allows it to further scrutinize the suggested Node, and if it decides it does not like it (due to some property or CSS style or whatever) it may follow up with another findXXX call or some other option to pick the Node it wants. It also allows (in the case of no Node being found) to pick its own preferred Node in those cases. In other words, it is just far more flexible. I'm not sure yet where to place these static helper methods (if we decide to expose them at all initially), or even if they should be static. Given that its first parameter is always a Node, a non-static location for them could simply be on Node itself, in which case the calling convention would become "Node result = from.findTraversableUp()" (suggested name only) > Focus traversals generate a new type of event, encapsulated by the class TraversalEvent which extends javafx.event.Event, using the event type TraversalEvent.NODE_TRAVERSED. What is the point of this event? If you want to know that focus changed, you can add a listener to Scene.focusOwnerProperty. What does it mean if I filter this event? What if I consume it? I don't think this should be an event at all, unless implemented as I suggested above, where consuming/filtering/bubbling can be used to control how controls will react to navigation events. --John On 03/09/2024 21:33, Andy Goryachev wrote: Dear fellow developers: I'd like to propose the public focus traversal API: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal.md Draft PR: https://github.com/openjdk/jfx/pull/1555 Your comments and suggestions will be warmly accepted and appreciated. Thank you -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpereda at openjdk.org Fri Sep 27 17:48:39 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Fri, 27 Sep 2024 17:48:39 GMT Subject: RFR: 8339068: [Linux] NPE: Cannot read field "firstFont" because "" is null In-Reply-To: <-JXCs7mp2rJhDUKB5Nh-EiGbTvcCJTW2mc_xf2KJdIU=.1666827e-cc7f-4758-8c11-b9b62e520e50@github.com> References: <-JXCs7mp2rJhDUKB5Nh-EiGbTvcCJTW2mc_xf2KJdIU=.1666827e-cc7f-4758-8c11-b9b62e520e50@github.com> Message-ID: On Wed, 28 Aug 2024 22:33:47 GMT, Phil Race wrote: >> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that make use of `FontConfigManager::getFontConfigFont`, which under certain cases, can return null. >> >> I've tested this PR on both Linux (Ubuntu 22.04.4) and Android, just using `-Dprism.useFontConfig=false`. >> >> On Ubuntu, I've manually added some font files to the JDK path `$JAVA_HOME/lib/fonts` (which didn't exist), and the test passes now, though this message is still printed out: >> >> Error: JavaFX detected no fonts! Please refer to release notes for proper font configuration >> >> which is confusing to me, because fonts where found in the JDK path after all, and even in the case that there were no fonts found, "the release notes" is an ambiguous reference for the user. >> >> Also, instead of adding fonts to the JDK, I tested adding a `logicalfonts.properties` file with `-Dprism.fontdir` and without `fontConfig`, but this case was already working before the patch for this PR, and still works after it. >> >> Note that if there are no fonts in the JDK path, and `prism.fontdir` is not provided, without `fontConfig`, after this PR, there will still be an exception: >> >> >> Caused by: java.lang.NullPointerException: Cannot invoke "com.sun.javafx.font.FontResource.getDefaultAAMode()" because the return value of "com.sun.javafx.font.LogicalFont.getSlot0Resource()" is null >> at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getDefaultAAMode(LogicalFont.java:456) >> at javafx.graphics at 24-internal/com.sun.javafx.font.LogicalFont.getStrike(LogicalFont.java:461) >> at javafx.graphics at 24-internal/com.sun.javafx.font.PrismFont.getStrike(PrismFont.java:79) >> at javafx.graphics at 24-internal/com.sun.javafx.text.PrismTextLayout.setContent(PrismTextLayout.java:139) >> at javafx.graphics at 24-internal/javafx.scene.text.Text.getTextLayout(Text.java:303) >> at javafx.graphics at 24-internal/javafx.scene.text.Text.needsFullTextLayout(Text.java:258) >> at javafx.graphics at 24-internal/javafx.scene.text.Text$6.invalidated(Text.java:576) >> ... >> >> >> because `LogicalFont::getSlot0Resource` will return null. Adding null checks after this point will require many changes (`LogicalFont::getSlotResource(0)` is used in many places). Shouldn't we fail gracefully after `LogicalFont::getSlot0Resource` if `slot0FontResource` is finally null? > > I don't understand why this change is needed. > > Perhaps I'm misunderstanding, but if usefontconfig is false, that means "I have supplied embedded fonts instead". > In which case the API calls where the null checks are added should not be returning null. > > In other words, setting this to false, and not supplying fonts is a misconfiguration. > Arguably we should disable this property and always look for fontconfig. > But one would only know how to misconfigure it by reading the sources to discover this property. @prrace could you have another look at this PR, after my change and comments? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1546#issuecomment-2379775064 From martin at martinfox.com Fri Sep 27 18:43:10 2024 From: martin at martinfox.com (Martin Fox) Date: Fri, 27 Sep 2024 11:43:10 -0700 Subject: Dead keys followed by space In-Reply-To: References: <9823d130-fa18-4286-b031-95eccc4af18d@oracle.com> Message-ID: <450CC930-5BA4-4F19-86AC-337CDCC0E4CC@martinfox.com> I don?t think a TextFormatter would work. The formatter would just see a caret arrive and then a space character. It would look just like the user typed those characters separately. The unexpected sequence is: - a PRESSED event arrives for the SPACE key - a TYPED event arrives for the dead key character - a TYPED event arrives for the space character - a RELEASED event arrives for the SPACE key You would have to register some filters that track state to detect this sequence and discard the second TYPED event. I can?t think of another way of doing this. You can?t track the dead key state reliably or know for sure that a TYPED event occurred while a dead key sequence was ending. I?ve submitted a PR (it?s a very small change to the code). Martin > On Sep 27, 2024, at 6:18?AM, Thiago Milczarek Say?o wrote: > > Johan, > > I guess you could use a TextFormatter<> to remove the extra space when there's a dead key character before. It would work as > > textField.setTextFormatter(new PasswordTextFilter()) > > public class PasswordTextFilter implements UnaryOperator { > > @Override > public TextFormatter.Change apply(final TextFormatter.Change aT) { > //logic to ignore the space if there's a dead key before > } > } > > > > > > Em sex., 27 de set. de 2024 ?s 09:42, Johan Corveleyn > escreveu: >> On Thu, Sep 26, 2024 at 10:37?AM Johan Corveleyn > wrote: >> > >> > Thanks, and thank you Martin for filing the issue https://bugs.openjdk.org/browse/JDK-8340982. I'll try to create an account on openjdk.org to be able to watch the issue :-). >> >> Seems it's not that easy to get an account on bugs.openjdk.org , so >> never mind that ... I'll check in on the issue from time to time (and >> of course I keep an eye on this mailinglist anyway). I'm not expecting >> this to be fixed immediately of course, I suppose everyone here has >> lots of things on their plate, and lots of other priorities; and I >> have little to offer as contribution myself at the moment. >> >> In the meantime: does anybody have an idea for an elegant workaround >> for this (to have a TextField and PasswordField where ^+ just >> yields '^' on Windows + US International keyboard)? Injecting a Swing >> component for this is an option, but I'd like to know if there are >> others. >> >> Thanks, >> -- >> Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Fri Sep 27 20:07:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 27 Sep 2024 20:07:41 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: > The standard across all platforms is: > > - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. > - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. > - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. > > The Windows glass code didn't implement the Space exception. This PR fixes that. > > On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. > > For some reason Windows 11 hides this setting well. To install a US International layout: > - Go to Settings > Time & Language > Language & Region. > - In the entry for English click on the three dots to the far right and select 'Language Options'. > - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. > - From the list select "United States - International". > To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). Thank you for logging the ticket! Do you think it is possible to write a unit test? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1584#issuecomment-2379972872 From kcr at openjdk.org Fri Sep 27 20:54:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 27 Sep 2024 20:54:00 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v40] In-Reply-To: References: Message-ID: On Wed, 25 Sep 2024 02:16:27 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits: > > - fix merge conflicts > - Merge branch 'master' into feature/interpolatable > > # Conflicts: > # modules/javafx.graphics/src/test/java/test/javafx/geometry/InsetsTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundFillTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundImageTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundPositionTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundSizeTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderStrokeTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderWidthsTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/ColorTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/ImagePatternTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/LinearGradientTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/RadialGradientTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopListTest.java > # modules/javafx.graphics/src/test/java/test/javafx/scene/paint/StopTest.java > - javadoc change > - javadoc change > - javadoc change > - small doc changes, copyright header > - fixed a bug when null values require discrete transitions > - javadoc changes > - added tests > - javadoc changes > - ... and 53 more: https://git.openjdk.org/jfx/compare/29004352...3027caa5 This looks really good and is almost ready to go in. Since the implementation has been heavily reviewed already, I'll limit my review to the API and do some light testing. I left a few comments on the API and docs inline. In addition, should `ImagePattern::getImage` specify an interpolation type of "discrete"? The docs for that method weren't updated. As soon as these issues are addressed, I'll re-review and also Review the CSR. modules/javafx.graphics/src/main/java/javafx/animation/Interpolatable.java line 43: > 41: * linear > 42: * Two components are combined by linear interpolation such that {@code t = 0} produces > 43: * the start value, and {@code t = 1} produces the end value. This interpolation type Minor: I might add something like: `and {@code 0 < t < 1} produces {@code (1 - t) * start + t * end}`, to clearly define what linear means. This would be OK to add in a follow-up. modules/javafx.graphics/src/main/java/javafx/scene/layout/BackgroundFill.java line 53: > 51: * > 52: * @return the Paint to use for filling the background of the {@link Region} > 53: * @interpolationType see {@link BackgroundFill} There isn't any mention of how interpolation is done in the class docs of this class. Did you mean to add something to the class docs, or should it link to `Paint` instead? ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2334313772 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1779022695 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1778964247 From kcr at openjdk.org Fri Sep 27 20:54:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 27 Sep 2024 20:54:00 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v36] In-Reply-To: References: Message-ID: On Sat, 14 Sep 2024 06:54:53 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 109: >> >>> 107: public TransitionEvent(EventType eventType, >>> 108: StyleableProperty property, >>> 109: String propertyName, >> >> Does this break backwards compatibility? > > Sure, but I don't really mind: > 1. `TransitionEvent` is a CSS event, it can not usefully be created by application developers. > 2. This API (without `propertyName`) will be introduced with JFX 23, so developers will need to hurry if they intend to misuse it until JFX 24 rolls around... > > I wouldn't mind removing the public constructor altogether, but this is not something that we usually do for JavaFX events. It might be best to leave the original constructor, deprecate it for removal, and set the default value of `name` to the empty string. We could then remove it in JavaFX 25. Either way, this new constructor will need an `@since 24` tag. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1779031210 From thiago.sayao at gmail.com Fri Sep 27 21:07:10 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Fri, 27 Sep 2024 18:07:10 -0300 Subject: Possible leak on prism es2 In-Reply-To: References: Message-ID: Hi, Pardon me If I'm bothering with nonsense, but I really think there's a leak, mainly because DrawableInfo is never freed (I did not find any code that frees it). Using valgrind, I see *many* entries like this: ==28403== 1,464 bytes in 61 blocks are still reachable in loss record 15,444 of 16,301 ==28403== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==28403== by 0x2BF83E5C: Java_com_sun_prism_es2_X11GLDrawable_nCreateDrawable (in /home/tsayao/IdeaProjects/jfx/build/sdk/lib/libprism_es2.so) ==28403== by 0x15E9FB3B: ??? ==28403== by 0x15E9B2D5: ??? ==28403== by 0x15E9B1DF: ??? ==28403== by 0x15E9B379: ??? ==28403== by 0xED02F83: ??? ==28403== by 0xED267B3: ??? ==28403== by 0x15E9B1DF: ??? ==28403== by 0x15E9B6E5: ??? ==28403== by 0x15E9B6E5: ??? ==28403== by 0x15E9B1DF: ??? Valgrind command: valgrind --leak-check=full --track-origins=yes --show-leak-kinds=all --suppressions=java.supp --log-file=valgrind.log java @/home/tsayao/IdeaProjects/jfx/build/run.args TestScenes.java Suppression file (java.supp): { # Suppress Java's native code memory allocations Memcheck:Leak obj:/usr/lib/jvm/jdk-22-oracle-x64/lib/server/libjvm.so fun:malloc fun:calloc fun:realloc fun:free } TestScenes.java: public class TestScenes extends Application { @Override public void start(Stage stage) { // Create a timeline animation to switch between scenes Timeline timeline = new Timeline( new KeyFrame(Duration.millis(100), e -> stage.setScene(createScene("Scene 1", Color.RED))), new KeyFrame(Duration.millis(200), e -> stage.setScene(createScene("Scene 2", Color.BLUE))), new KeyFrame(Duration.millis(300), e -> stage.setScene(createScene("Scene 3", Color.GREEN))) ); timeline.setCycleCount(Animation.INDEFINITE); timeline.play(); stage.show(); } private Scene createScene(String text, Color color) { return new Scene(new StackPane(), 400, 300, color); } public static void main(String[] args) { launch(TestScenes.class, args); } } Em qui., 26 de set. de 2024 ?s 08:14, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > Hi, > > I'm investigating the code, and for someone not familiar with it, it's > very complex. > > On com.sun.javafx.tk.quantum.WindowStage it will do this when changing > scene: > > if (oldScene != null) { > ViewPainter painter = ((ViewScene)oldScene).getPainter(); > QuantumRenderer.getInstance().disposePresentable(painter.presentable); // latched on RT > } > > But not when closing the Sage (possible problem #1). > > When changing scenes, ES2SwapChain dispose will be called: > > public void dispose() { > if (stableBackbuffer != null) { > stableBackbuffer.dispose(); > stableBackbuffer = null; > } > } > > > But it does not dispose the drawable that should clear the native struc > DrawableInfo created, I think (possible problem #2). > > Does it make sense? > > -- Thiago. > > > > Em ter., 24 de set. de 2024 ?s 14:10, Thiago Milczarek Say?o < > thiago.sayao at gmail.com> escreveu: > >> I might be mistaken, but it seems deleteDrawableInfo is never called. >> >> I think it should be called when the platform View is replaced or when >> the window is closed. >> >> Github search for deleteDrawableInfo >> >> https://github.com/search?q=repo%3Aopenjdk%2Fjfx%20deleteDrawableInfo&type=code >> >> Em ter., 24 de set. de 2024 ?s 09:07, Thiago Milczarek Say?o < >> thiago.sayao at gmail.com> escreveu: >> >>> Hi, >>> >>> While doing some work on replacing GLX with EGL I discovered a possible >>> leak. >>> >>> Running this test: >>> gradle -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests >>> SetSceneScalingTest >>> >>> will result in X11GLDrawable -> nCreateDrawable to be called multiple >>> times on the same test, while GLDrawable -> deleteDrawableInfo is never >>> called, generating a leak (I think). >>> >>> I can probably fix this, but I still have little knowledge on the es2 >>> part, so any help would be appreciated. >>> >>> -- Thiago. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfox at openjdk.org Fri Sep 27 21:09:38 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 27 Sep 2024 21:09:38 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: > The standard across all platforms is: > > - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. > - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. > - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. > > The Windows glass code didn't implement the Space exception. This PR fixes that. > > On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. > > For some reason Windows 11 hides this setting well. To install a US International layout: > - Go to Settings > Time & Language > Language & Region. > - In the entry for English click on the three dots to the far right and select 'Language Options'. > - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. > - From the list select "United States - International". > To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). I haven't figured out how to write unit tests for dead keys or IME events. The Windows US English layout doesn't use dead keys. There's no way for me to force the use of a different keyboard layout or verify that the right one is installed before running the test. The best I can do is a manual test like the existing KeyboardTest app in the tests/manual/event folder. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1584#issuecomment-2380059984 From angorya at openjdk.org Fri Sep 27 21:45:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 27 Sep 2024 21:45:52 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: > The standard across all platforms is: > > - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. > - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. > - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. > > The Windows glass code didn't implement the Space exception. This PR fixes that. > > On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. > > For some reason Windows 11 hides this setting well. To install a US International layout: > - Go to Settings > Time & Language > Language & Region. > - In the entry for English click on the three dots to the far right and select 'Language Options'. > - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. > - From the list select "United States - International". > To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). tested on win11, the behavior matches Notepad.exe with dead keys `^` (shift-6), `~`, backtick (shift-tilda), quotes, ' (tick, same key as quotes), producing the following characters: ? ? ? ? ? but using the sequence of ' produces ? instead of ?. where can I get a complete list of dead keys for the US International keyboard, and will it be any different for other keyboards (is there any impact on this PR for different keyboards)? Could someone with a German keyboard take a look at this as well? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1584#issuecomment-2380104827 PR Comment: https://git.openjdk.org/jfx/pull/1584#issuecomment-2380109588 From mstrauss at openjdk.org Fri Sep 27 22:12:20 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 27 Sep 2024 22:12:20 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v41] In-Reply-To: References: Message-ID: <8AUBVjPwtnHPtSexL11c_ULGm7m05BMxImV-7cWBCYQ=.05c4d8d4-a979-490a-970b-5b9b052d9992@github.com> > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - documentation changes - documentation changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/3027caa5..e3792cc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=40 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=39-40 Stats: 36 lines in 5 files changed: 19 ins; 10 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From kcr at openjdk.org Fri Sep 27 22:15:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 27 Sep 2024 22:15:52 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v41] In-Reply-To: <8AUBVjPwtnHPtSexL11c_ULGm7m05BMxImV-7cWBCYQ=.05c4d8d4-a979-490a-970b-5b9b052d9992@github.com> References: <8AUBVjPwtnHPtSexL11c_ULGm7m05BMxImV-7cWBCYQ=.05c4d8d4-a979-490a-970b-5b9b052d9992@github.com> Message-ID: <1gSiUpCc6SxMoPEhUue1-oh1laOFbVjI4Ekjb4KPC_A=.1f36ac5d-8fe0-406f-9f0e-f6040093e82f@github.com> On Fri, 27 Sep 2024 22:12:20 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - documentation changes > - documentation changes Thanks for the updates. Looks good with a couple more comments on the deprecated-for-removal constructor. modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 106: > 104: * @throws NullPointerException if {@code eventType}, {@code property} or {@code elapsedTime} is {@code null} > 105: */ > 106: @Deprecated(forRemoval = true) Can you add `since = 24,` before the `forRemoval`? Also please add an `@deprecated` javadoc tag referring to the new constructor. ------------- PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2334740841 PR Review Comment: https://git.openjdk.org/jfx/pull/1522#discussion_r1779246075 From mstrauss at openjdk.org Fri Sep 27 22:19:43 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 27 Sep 2024 22:19:43 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v42] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: removed unnecessary imports ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/e3792cc5..7d086cf6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=41 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=40-41 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From mstrauss at openjdk.org Fri Sep 27 22:22:27 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 27 Sep 2024 22:22:27 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v43] In-Reply-To: References: Message-ID: <7RcpswtusTDPR3hOcZryT9ILUaAKC5cx-JCwZKX3QPI=.6d484a02-27a6-4060-82e9-cf2662588332@github.com> > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `Stop` > - `Paint` and all of its subclasses > - `Margins` (internal type) > - `BorderImageSlices` (internal type) > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the ... Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added @deprecated javadoc tag ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1522/files - new: https://git.openjdk.org/jfx/pull/1522/files/7d086cf6..332a5c1e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=42 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1522&range=41-42 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1522.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/jfx/pull/1522 From angorya at openjdk.org Fri Sep 27 22:57:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 27 Sep 2024 22:57:42 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: > The standard across all platforms is: > > - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. > - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. > - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. > > The Windows glass code didn't implement the Space exception. This PR fixes that. > > On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. > > For some reason Windows 11 hides this setting well. To install a US International layout: > - Go to Settings > Time & Language > Language & Region. > - In the entry for English click on the three dots to the far right and select 'Language Options'. > - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. > - From the list select "United States - International". > To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). Using DEAD_ACUTE key the sequence printed by the Keyboard Event Viewer in the Monkey Tester - master branch: KeyEvent{type=KEY_PRESSED, character=<\u00>, text=', code=DEAD_ACUTE} KeyEvent{type=KEY_PRESSED, character=<\u00>, text= , code=SPACE} KeyEvent{type=KEY_TYPED, character=', text=, code=UNDEFINED} KeyEvent{type=KEY_TYPED, character=<\u20>, text=, code=UNDEFINED} KeyEvent{type=KEY_RELEASED, character=<\u00>, text= , code=SPACE} with this PR: KeyEvent{type=KEY_PRESSED, character=<\u00>, text=', code=DEAD_ACUTE} KeyEvent{type=KEY_PRESSED, character=<\u00>, text= , code=SPACE} KeyEvent{type=KEY_TYPED, character=', text=, code=UNDEFINED} KeyEvent{type=KEY_RELEASED, character=<\u00>, text= , code=SPACE} Do we need to create a new ticket for DEAD_ACUTE + c ? Will it be related to JDK-8183521 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1584#issuecomment-2380250493 From angorya at openjdk.org Fri Sep 27 23:01:54 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 27 Sep 2024 23:01:54 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: > The standard across all platforms is: > > - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. > - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. > - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. > > The Windows glass code didn't implement the Space exception. This PR fixes that. > > On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. > > For some reason Windows 11 hides this setting well. To install a US International layout: > - Go to Settings > Time & Language > Language & Region. > - In the entry for English click on the three dots to the far right and select 'Language Options'. > - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. > - From the list select "United States - International". > To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1584#pullrequestreview-2334781207 From jhendrikx at openjdk.org Sat Sep 28 02:36:41 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 28 Sep 2024 02:36:41 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus In-Reply-To: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> References: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> Message-ID: On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote: > This change modifies `ScrollPaneBehavior` to only consume keys that are targetted at it. As `KeyEvent`s are in almost all cases only intended for the targetted node (as visually that's where the user expects the keyboard input to go, as per normal UI rules) consuming key events that bubble up is simply incorrect. When the `ScrollPane` is focused directly (it has the focused border) then it is fine for it to respond to all kinds of keys. > > In FX controls normally there is no need to check if a `Control` is focused (although they probably should **all** do this) as they do not have children that could have received the Key Events involved, and Key Events are always sent to the focused Node. When `ScrollPane` was developed this was not taken into account, leading to it consuming keys not intended for it. > > This fixes several unexpected problems for custom control builders. A custom control normally benefits from standard navigation out of the box (TAB/shift+TAB) and directional keys. However, this breaks down as soon as this custom control is positioned within a `ScrollPane`, which is very surprising behavior and not at all expected. This makes it harder than needed for custom control developers to get the standard navigation for the directional keys, as they would have to specifically capture those keys before they reach the `ScrollPane` and trigger the correct navigation action themselves (for which as of this writing there is no public API). > > The same goes for all the other keys captured by `ScrollPane` when it does not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys. I'm sorry, what is an SCCE? As for the problem, I think I explained this several times now, but I'll attempt it again: When the user uses the keyboard to control an application, there generally is a border or some other indication indicating the control that will be accepting those keyboard commands. In FX, KeyEvents therefore are always send to the control that has the current focus, as that's where the user expects them to go. For any controls that don't have children, you can assume that a KeyEvent that is received is intended for you -- your control is a leaf in the hierarchy, and so if you received the KeyEvent, you must have had the focus. ScrollPane is different. It is also a Control, but is rarely the target of the focus and even more rarely a leaf in a scene. As such, KeyEvents that were not consumed by the actual target Control can bubble up to it. If a Control wishes to use standard navigation provided by Scene, it must let KeyEvents bubble up. If there is no ScrollPane in between anywhere, this works perfectly. For example, take five Buttons, put them in a Scene in an HBox, remove the standard navigation behavior from them, and observe that even without these keys being part of the InputMap that the directional navigation works for these controls. Now, do this same experiment but put a ScrollPane in between (ie. Scene -> ScrollPane -> HBox -> 5 buttons). Observe that now directional navigation no longer works, despite one of the Buttons having the focus. This is because the ScrollPane, even though it is not focused (no :focused pseudo state, no focused border) is responding to bubbled up KeyEvents intended for one of the Buttons. Custom Control authors outside FX are facing this exact problem -- their Control works flawlessly with standard navigation out of the box when put in standard containers like HBox/VBox etc. However, as soon as a ScrollPane is part of the hierarchy, the directional navigation will no longer function. Again, this is because ScrollPane is consuming KeyEvents not targetted at it. There is no good work-around for this problem, as custom control authors don't have access to input maps nor the traversal engine. Their only option is to recreate the same navigation offered by FX by responding themselves to directional keys which is cumbersome. But why are we working around this problem at all? ScrollPane has no business consuming those keys when it is not focused itself. Controls in FX are basically installing navigation keys in their input maps **because** they otherwise stop functioning correctly when a ScrollPane is in the hierarchy. Navigation is not the business of individual controls, unless their very nature requires a different form of navigation (like ToggleButtons). So in short: create a custom control, put two of them in a HBox and observe that you get directional navigation for free. Now put a ScrollPane in that mix, observe that directional navigation no longer works. > Another question - do you think it might make sense to wait until we get the traversal policy API https://github.com/openjdk/jfx/pull/1555 and instead install a policy by default which is identical to the current behavior, but at the same time it can be disabled or changed to a different policy? I really don't think the current ScrollPane behavior has any place in FX, so I don't see a need to offer both the old and the new behavior. I really feel we're going overboard here to avoid potentially breaking something when it is clearly not correct behavior from a UI point of view. You can't make any changes at all anywhere to anything if the criteria is to not cause regressions in undocumented behavior. As for installing custom policies, I'm still not convinced that's the right way to go. I haven't seen any convincing use cases that aren't incredibly niche or are primarily there to work around other more fundamental problems (like this PR that attempts to address one of them). The use cases I did see could be solved by offering navigation methods on `Scene`, and wouldn't be solved by custom policies (ie. if I receive an ActionEvent, and in response to it I want to navigate to the logical next control, how would policies help here?) My take on all of this: if the navigation offered by default in Scene is insufficient for your control, then it is easy enough to look at the scene graph and pick your own next/previous control in response to a KeyEvent. Can FX help here? Sure, offer a few methods that given a Node find a logical/directional next/previous Node, or `null` if not found. There is no need to wrap this all up in a policy: In `Node`: Optional findFocusable(direction); Or if you want to get really fancy offer a few standard traversal policies that can be accessed statically: public interface TraversalPolicy { Optional findFocusable(Node from); } public enum DirectionalNavigation implements TraversalPolicy { UP, DOWN, LEFT, RIGHT; @Override public Optional findFocusable(Node from) { Node next = null; // Calculate next return Optional.of(next); } } public enum LogicalNavigation implements TraversalPolicy { NEXT, PREVIOUS; @Override public Optional findFocusable(Node from) { Node next = null; // Calculate next return Optional.of(next); } } public enum InsaneCustomNavigation implements TraversalPolicy { RANDOM, DIAGONAL_THREE_DOWN; @Override public Optional findFocusable(Node from) { Node next = null; // Calculate next return Optional.of(next); } } You can then super easily use these like this: Button button = new Button(); button.setOnAction(e -> LogicalNavigation.NEXT.findFocusable(button).ifPresent(Node::requestFocus)); You wouldn't even need the interface `TraversalPolicy` unless you want to make them configurable for the above code. With the interface you could do this: button.setOnAction(e -> configuredPolicy.findFocusable(button).ifPresent(Node::requestFocus)); ------------- PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2380363546 From jhendrikx at openjdk.org Sat Sep 28 02:52:40 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sat, 28 Sep 2024 02:52:40 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: > The standard across all platforms is: > > - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. > - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. > - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. > > The Windows glass code didn't implement the Space exception. This PR fixes that. > > On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. > > For some reason Windows 11 hides this setting well. To install a US International layout: > - Go to Settings > Time & Language > Language & Region. > - In the entry for English click on the three dots to the far right and select 'Language Options'. > - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. > - From the list select "United States - International". > To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). Thanks, this looks like a good fix. ------------- Marked as reviewed by jhendrikx (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1584#pullrequestreview-2334863854 From mfox at openjdk.org Sat Sep 28 13:02:38 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 28 Sep 2024 13:02:38 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 22:54:59 GMT, Andy Goryachev wrote: > Do we need to create a new ticket for DEAD_ACUTE + c ? Will it be related to [JDK-8183521](https://bugs.openjdk.org/browse/JDK-8183521) ? I could not find an official Microsoft page listing the dead key sequences for this keyboard. I did find a few university sites that contain write-ups (like [this one at Washington State](https://slcr.wsu.edu/help-pages/microsoft-keyboards-us-international/)). It shows the DEAD_ACUTE + c combination as generating a ?. I also get ? in other Windows apps so it doesn't appear to be a bug. [JDK-8183521](https://bugs.openjdk.org/browse/JDK-8183521) is in the same area of the code (good catch!) but whatever is going wrong occurs earlier. I decided to beat my head against that a bit more and will update the bug report with what I find. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1584#issuecomment-2380632358 From mfox at openjdk.org Sat Sep 28 13:02:39 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 28 Sep 2024 13:02:39 GMT Subject: Integrated: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: > The standard across all platforms is: > > - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. > - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. > - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. > > The Windows glass code didn't implement the Space exception. This PR fixes that. > > On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. > > For some reason Windows 11 hides this setting well. To install a US International layout: > - Go to Settings > Time & Language > Language & Region. > - In the entry for English click on the three dots to the far right and select 'Language Options'. > - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. > - From the list select "United States - International". > To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). This pull request has now been integrated. Changeset: 5428f267 Author: Martin Fox URL: https://git.openjdk.org/jfx/commit/5428f267887ea4098f6c2a87335de7ed9bf5c656 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod 8340982: [win] Dead key followed by Space generates two characters instead of one Reviewed-by: angorya, jhendrikx ------------- PR: https://git.openjdk.org/jfx/pull/1584 From kcr at openjdk.org Sat Sep 28 13:12:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 28 Sep 2024 13:12:47 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v43] In-Reply-To: <7RcpswtusTDPR3hOcZryT9ILUaAKC5cx-JCwZKX3QPI=.6d484a02-27a6-4060-82e9-cf2662588332@github.com> References: <7RcpswtusTDPR3hOcZryT9ILUaAKC5cx-JCwZKX3QPI=.6d484a02-27a6-4060-82e9-cf2662588332@github.com> Message-ID: On Fri, 27 Sep 2024 22:22:27 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added @deprecated javadoc tag Thanks, it looks good now. I have also Reviewed the CSR. You can Finalize it when ready. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2335001619 From mfox at openjdk.org Sat Sep 28 16:41:41 2024 From: mfox at openjdk.org (Martin Fox) Date: Sat, 28 Sep 2024 16:41:41 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: <4U8-KoUrnaRfoiF6MOFgoXuYl4yEj6xcsb0NLA5eI1Q=.80deaf89-9a91-4a7b-b694-fd32625ca6b0@github.com> On Fri, 27 Sep 2024 22:54:59 GMT, Andy Goryachev wrote: >> The standard across all platforms is: >> >> - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. >> - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. >> - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. >> >> The Windows glass code didn't implement the Space exception. This PR fixes that. >> >> On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. >> >> For some reason Windows 11 hides this setting well. To install a US International layout: >> - Go to Settings > Time & Language > Language & Region. >> - In the entry for English click on the three dots to the far right and select 'Language Options'. >> - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. >> - From the list select "United States - International". >> To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). > > Using DEAD_ACUTE key the sequence printed by the Keyboard Event Viewer in the Monkey Tester - > master branch: > > KeyEvent{type=KEY_PRESSED, character=<\u00>, text=', code=DEAD_ACUTE} > KeyEvent{type=KEY_PRESSED, character=<\u00>, text= , code=SPACE} > KeyEvent{type=KEY_TYPED, character=', text=, code=UNDEFINED} > KeyEvent{type=KEY_TYPED, character=<\u20>, text=, code=UNDEFINED} > KeyEvent{type=KEY_RELEASED, character=<\u00>, text= , code=SPACE} > > > > > with this PR: > > KeyEvent{type=KEY_PRESSED, character=<\u00>, text=', code=DEAD_ACUTE} > KeyEvent{type=KEY_PRESSED, character=<\u00>, text= , code=SPACE} > KeyEvent{type=KEY_TYPED, character=', text=, code=UNDEFINED} > KeyEvent{type=KEY_RELEASED, character=<\u00>, text= , code=SPACE} > > > Do we need to create a new ticket for DEAD_ACUTE + c ? > Will it be related to [JDK-8183521](https://bugs.openjdk.org/browse/JDK-8183521) ? @andy-goryachev-oracle Sorry, I misread your earlier message. You're right, in JavaFX DEAD_ACUTE + c is producing the wrong result with the U.S. International layout. We should see ?. I will enter a bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1584#issuecomment-2380778162 From kneester77 at gmail.com Mon Sep 30 00:12:20 2024 From: kneester77 at gmail.com (Knee Snap) Date: Sun, 29 Sep 2024 17:12:20 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: These are some great points! Nir mentioned a builder-style pattern for TriangleMesh, but I struggle to think of how this could work well, as one critical feature of the current API is to be able to dynamically update mesh data, which is very important for any kind of animated mesh. I'd love to see any designs that get prototyped though (regardless of if they are builder-like). Let's discuss the big question though, VertexFormat's design. To be honest, light maps and shadow maps seem unrealistic right now. They are way too intensive to generate in JavaFX (we'd need a LOT of work to do this efficiently, only for the user to not like the algorithm we selected). And even if the user gets this far, they'll be faced with a significant performance penalty. Light maps usually contain data for many 3D objects, but due to JavaFX rendering order being based on the scene graph order, which is going to cause a significant amount of large texture swaps. I'd be open to changing that and do hope to fix the performance issues as much as we can, but overall it strikes me as a very far-fetched feature. Regarding bones/skeletal rigs, that's a really good idea actually. I'm kind of shocked I didn't think of that sooner. I've got a few ideas for how we can tackle these problems, but none particularly jump out as the perfect option to me, so I'm hoping for feedback on what you guys think. *1) Why not let users define their own VertexFormats? If our concern is the explosion of definitions we'd be keeping statically, we could just define a handful of built-in formats but let users define formats as they see fit. Similar to the Cesium Project Nir linked.* *Pros:* - This would avoid the explosion of built-in formats, since we wouldn't need to explicitly define/support every single format, but instead let the user define the format themselves. *Cons:* - Doesn't address the concern of TriangleMesh properties not serving any purpose depending on what VertexFormat it has. *2) Have TriangleMesh automatically determine format based on which buffers contain/do not contain data.* This is extremely similar to #1, except it We could keep VertexFormat around, but make it read-only, so it only serves as a reflection of the data in TriangleMesh, instead of something the user can apply. We'd deprecate the constructor TriangleMesh(VertexFormat) and TriangleMesh.setFormat(VertexFormat) but keep them around (they would do nothing) thus keeping code compatibility (and maybe also binary compatibility?). *Pros:* - Avoid bloat. - Extensible without ever leaving any functionality both unusable and accessible. (IDEA: What if it's not fully removed, but instead is a read-only property obtainable inside TriangleMesh, and the constructor which accepts a VertexFormat deprecated instead? It still feels appropriate to get vertex format data from VertexFormat instead of the mesh itself) *Cons:* - Breaking API change. (If we deprecate/remove VertexFormat) - The user is still responsible for supplying the faces array in the correct format, and making the VertexFormat calculated implicitly behind the scenes (something the user must respond to or the mesh will either not render or display corrupted if we can't tell), would be hidden from the user. Currently the user has to explicitly say they're changing the format, but this automatic behavior is less clear to the user. Not a huge deal but worth considering. The overall outcome of this seems pretty similar to #1, but it loses the benefit of explicitness in exchange for not ever having buffers which are unusable but still accessible. I'm personally torn on if this trade-off is worth it. *3) Add Vertex Colors to VertexFormat, but future features use either #1 or #2.* Bump map tangents/light map uvs/skeleton seem significantly less ubiquitous than vertex colors even if they're still important. Picking this option would expand the already questionable normals design, but considering these future features may never be added, perhaps it makes sense to keep the existing design until we're sure we're even going to add the others. And at that point we'd be in exactly the same position as now with exactly the same options for implementing it. In other words, it buys us time while still letting us scrap VertexFormat if the time ever comes. *Pros:* - Keeps all existing features consistent with existing public API design. - Avoids bloat - Avoids breaking consistency with the existing public API up until the moment we start adding less common data fields. *Cons:* - If Option #1 is picked for future features, the same cons from #1 are present. - If Option #2 is picked for future features, the same cons from #2 are present. - If we're going to deprecate VertexFormat, it might be a valid point that that we don't actually want to delay that, and would rather do it earlier rather than later. I'm torn between all of the options I've listed here. What do you guys think? We should also discuss how other primitive topologies (POINT, LINE, TRIANGLE, TRIANGLE_STRIP) could work and how this might factor into our VertexFormat discussions. (Should LINE really even be represented by TriangleMesh and not a new LineMesh? Would it make sense to still use VertexFormat?) On Mon, Sep 23, 2024, 9:23?AM Nir Lisker wrote: > Having gone through some sources, I found the additional properties that > can be added as per-vertex data: > * Additional texture coordinates (mentioned by Michael). These can be used > for detailed textures. > * Bone indices and weights. These are for GPU skinning. Interestingly, the > D3D vertex shader constants file has some preparation for skinning and > bones [1]. > * Tangents. Used similarly to normals in some lighting-related > calculations. > > While it's not clear that we'll need these, the proliferation of vertex > formats will be unmanageable with even one of these added (in addition to > color). > > Looking at the use of VertexFormat in TriangleMesh with regards to normals: > > private boolean validateNormals() { > // Only validate normals if vertex format has normal component > if (getVertexFormat() != VertexFormat.POINT_NORMAL_TEXCOORD) return > true; > > if (normals.size() == 0) { // Valid but meaningless for picking or > rendering. > return false; > ... > } > > I'm confused by this. If the normals should be validated only when the > vertex format defines that normals are used, why does the method return > true when normals aren't used? > I would think, along with what Michael said, that either if the vertex > format doesn't declare normals, or the user doesn't declare normal (size > ==0), then the normals wouldn't be validated. That would also mean that the > vertex format is redundant since it's implied by the existence/length of > the array. > > Perhaps it's worth looking at the color implementation this way. > Additional vertex formats should not be added, and the use of vertex colors > should be dictated by looking at the array. > > [1] > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h > > On Sat, Sep 21, 2024 at 5:17?AM Michael Strau? > wrote: > >> > I'm not yet convinced that new vertex formats are the way to go. >> >> To be fair, I'm not sure why VertexFormat even exists. It serves no >> purpose when creating a TriangleMesh, as the vertex format could >> easily be inferred by the presence (or absence) of vertex data. Having >> users specify the VertexFormat explicitly is probably not a good API, >> as it now makes the other data components be dependent on the choice >> of the vertex format. >> >> Of course, not all combinations of vertex data are valid, but this >> could be specified in documentation and be validated by the >> implementation. I think it might be best to deprecate VertexFormat for >> removal. This would also prevent a potential explosion of vertex >> formats in the public API. >> >> I have no objection to the choice to add vertex colors as an >> additional data component to TriangleMesh. It adds to the API, but >> this is not a slippery slope as there's only a very finite set of >> features we might be tempted to add next: >> >> The most obvious thing that JavaFX 3D really can't do is shadows. >> These come in static form (light mapping) and dynamic form (shadow >> mapping). Light mapping requires a second set of texcoords, while >> shadow mapping does not. >> >> Adding light mapping would make JavaFX 3D competitive with late-90's >> graphics, and adding shadow mapping would make it competitive with >> early-2000's graphics. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Mon Sep 30 09:58:20 2024 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 30 Sep 2024 12:58:20 +0300 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: I would first try to figure out if the code in the snippet I gave is actually correct. If it is, then the vertex format has a functional use. If it's not, then we can think about what to do with it. I didn't look into it, but on the face of it, it doesn't look like the unused normals should be validated. The last sentence in my previous mail suggested a different solution: keep the vertex format as it is (for now) to dictate how points and normals are read, but add color without interaction with the vertex format. The color will be used if it's not empty/null. This keeps everything as it is, avoids multiplications of formats, and doesn't hinder possible future additions that will also not use the vertex format. On the slightly confusing side, it means that vertex format doesn't define the format for *all* the data of the vertex, just for its positional components that are mandatory (at the very least, points should be supplied). On Mon, Sep 30, 2024 at 3:12?AM Knee Snap wrote: > These are some great points! > > Nir mentioned a builder-style pattern for TriangleMesh, but I struggle to > think of how this could work well, as one critical feature of the current > API is to be able to dynamically update mesh data, which is very important > for any kind of animated mesh. I'd love to see any designs that get > prototyped though (regardless of if they are builder-like). > > Let's discuss the big question though, VertexFormat's design. > > To be honest, light maps and shadow maps seem unrealistic right now. They > are way too intensive to generate in JavaFX (we'd need a LOT of work to do > this efficiently, only for the user to not like the algorithm we selected). > And even if the user gets this far, they'll be faced with a significant > performance penalty. Light maps usually contain data for many 3D objects, > but due to JavaFX rendering order being based on the scene graph order, > which is going to cause a significant amount of large texture swaps. I'd be > open to changing that and do hope to fix the performance issues as much as > we can, but overall it strikes me as a very far-fetched feature. > > Regarding bones/skeletal rigs, that's a really good idea actually. I'm > kind of shocked I didn't think of that sooner. > > I've got a few ideas for how we can tackle these problems, but none > particularly jump out as the perfect option to me, so I'm hoping for > feedback on what you guys think. > > *1) Why not let users define their own VertexFormats? If our concern is > the explosion of definitions we'd be keeping statically, we could just > define a handful of built-in formats but let users define formats as they > see fit. Similar to the Cesium Project Nir linked.* > > *Pros:* > - This would avoid the explosion of built-in formats, since we wouldn't > need to explicitly define/support every single format, but instead let the > user define the format themselves. > > *Cons:* > - Doesn't address the concern of TriangleMesh properties not serving any > purpose depending on what VertexFormat it has. > > *2) Have TriangleMesh automatically determine format based on which > buffers contain/do not contain data.* > This is extremely similar to #1, except it > > We could keep VertexFormat around, but make it read-only, so it only > serves as a reflection of the data in TriangleMesh, instead of something > the user can apply. We'd deprecate the constructor > TriangleMesh(VertexFormat) and TriangleMesh.setFormat(VertexFormat) but > keep them around (they would do nothing) thus keeping code compatibility > (and maybe also binary compatibility?). > > *Pros:* > - Avoid bloat. > - Extensible without ever leaving any functionality both unusable and > accessible. (IDEA: What if it's not fully removed, but instead is a > read-only property obtainable inside TriangleMesh, and the constructor > which accepts a VertexFormat deprecated instead? It still feels appropriate > to get vertex format data from VertexFormat instead of the mesh itself) > > *Cons:* > - Breaking API change. (If we deprecate/remove VertexFormat) > - The user is still responsible for supplying the faces array in the > correct format, and making the VertexFormat calculated implicitly behind > the scenes (something the user must respond to or the mesh will either not > render or display corrupted if we can't tell), would be hidden from the > user. Currently the user has to explicitly say they're changing the format, > but this automatic behavior is less clear to the user. Not a huge deal but > worth considering. > > The overall outcome of this seems pretty similar to #1, but it loses the > benefit of explicitness in exchange for not ever having buffers which are > unusable but still accessible. I'm personally torn on if this trade-off is > worth it. > > *3) Add Vertex Colors to VertexFormat, but future features use either #1 > or #2.* > Bump map tangents/light map uvs/skeleton seem significantly less > ubiquitous than vertex colors even if they're still important. Picking this > option would expand the already questionable normals design, but > considering these future features may never be added, perhaps it makes > sense to keep the existing design until we're sure we're even going to add > the others. And at that point we'd be in exactly the same position as now > with exactly the same options for implementing it. In other words, it buys > us time while still letting us scrap VertexFormat if the time ever comes. > > *Pros:* > - Keeps all existing features consistent with existing public API design. > - Avoids bloat > - Avoids breaking consistency with the existing public API up until the > moment we start adding less common data fields. > > *Cons:* > - If Option #1 is picked for future features, the same cons from #1 are > present. > - If Option #2 is picked for future features, the same cons from #2 are > present. > - If we're going to deprecate VertexFormat, it might be a valid point > that that we don't actually want to delay that, and would rather do it > earlier rather than later. > > I'm torn between all of the options I've listed here. What do you guys > think? > > We should also discuss how other primitive topologies (POINT, LINE, > TRIANGLE, TRIANGLE_STRIP) could work and how this might factor into our > VertexFormat discussions. (Should LINE really even be represented by > TriangleMesh and not a new LineMesh? Would it make sense to still use > VertexFormat?) > > On Mon, Sep 23, 2024, 9:23?AM Nir Lisker wrote: > >> Having gone through some sources, I found the additional properties that >> can be added as per-vertex data: >> * Additional texture coordinates (mentioned by Michael). These can be >> used for detailed textures. >> * Bone indices and weights. These are for GPU skinning. Interestingly, >> the D3D vertex shader constants file has some preparation for skinning and >> bones [1]. >> * Tangents. Used similarly to normals in some lighting-related >> calculations. >> >> While it's not clear that we'll need these, the proliferation of vertex >> formats will be unmanageable with even one of these added (in addition to >> color). >> >> Looking at the use of VertexFormat in TriangleMesh with regards to >> normals: >> >> private boolean validateNormals() { >> // Only validate normals if vertex format has normal component >> if (getVertexFormat() != VertexFormat.POINT_NORMAL_TEXCOORD) return >> true; >> >> if (normals.size() == 0) { // Valid but meaningless for picking or >> rendering. >> return false; >> ... >> } >> >> I'm confused by this. If the normals should be validated only when the >> vertex format defines that normals are used, why does the method return >> true when normals aren't used? >> I would think, along with what Michael said, that either if the vertex >> format doesn't declare normals, or the user doesn't declare normal (size >> ==0), then the normals wouldn't be validated. That would also mean that the >> vertex format is redundant since it's implied by the existence/length of >> the array. >> >> Perhaps it's worth looking at the color implementation this way. >> Additional vertex formats should not be added, and the use of vertex colors >> should be dictated by looking at the array. >> >> [1] >> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h >> >> On Sat, Sep 21, 2024 at 5:17?AM Michael Strau? >> wrote: >> >>> > I'm not yet convinced that new vertex formats are the way to go. >>> >>> To be fair, I'm not sure why VertexFormat even exists. It serves no >>> purpose when creating a TriangleMesh, as the vertex format could >>> easily be inferred by the presence (or absence) of vertex data. Having >>> users specify the VertexFormat explicitly is probably not a good API, >>> as it now makes the other data components be dependent on the choice >>> of the vertex format. >>> >>> Of course, not all combinations of vertex data are valid, but this >>> could be specified in documentation and be validated by the >>> implementation. I think it might be best to deprecate VertexFormat for >>> removal. This would also prevent a potential explosion of vertex >>> formats in the public API. >>> >>> I have no objection to the choice to add vertex colors as an >>> additional data component to TriangleMesh. It adds to the API, but >>> this is not a slippery slope as there's only a very finite set of >>> features we might be tempted to add next: >>> >>> The most obvious thing that JavaFX 3D really can't do is shadows. >>> These come in static form (light mapping) and dynamic form (shadow >>> mapping). Light mapping requires a second set of texcoords, while >>> shadow mapping does not. >>> >>> Adding light mapping would make JavaFX 3D competitive with late-90's >>> graphics, and adding shadow mapping would make it competitive with >>> early-2000's graphics. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Mon Sep 30 10:13:51 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 30 Sep 2024 10:13:51 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v43] In-Reply-To: <7RcpswtusTDPR3hOcZryT9ILUaAKC5cx-JCwZKX3QPI=.6d484a02-27a6-4060-82e9-cf2662588332@github.com> References: <7RcpswtusTDPR3hOcZryT9ILUaAKC5cx-JCwZKX3QPI=.6d484a02-27a6-4060-82e9-cf2662588332@github.com> Message-ID: On Fri, 27 Sep 2024 22:22:27 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added @deprecated javadoc tag Re-approving the API. ------------- Marked as reviewed by nlisker (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2336994404 From angorya at openjdk.org Mon Sep 30 14:41:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 30 Sep 2024 14:41:49 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v43] In-Reply-To: <7RcpswtusTDPR3hOcZryT9ILUaAKC5cx-JCwZKX3QPI=.6d484a02-27a6-4060-82e9-cf2662588332@github.com> References: <7RcpswtusTDPR3hOcZryT9ILUaAKC5cx-JCwZKX3QPI=.6d484a02-27a6-4060-82e9-cf2662588332@github.com> Message-ID: On Fri, 27 Sep 2024 22:22:27 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `Stop` >> - `Paint` and all of its subclasses >> - `Margins` (internal type) >> - `BorderImageSlices` (internal type) >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the... > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added @deprecated javadoc tag re-approving ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1522#pullrequestreview-2337780921 From angorya at openjdk.org Mon Sep 30 14:51:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 30 Sep 2024 14:51:41 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: <5ltRq3CYy-YYvIx093TCJNmf948uTN3wYvj0Vr6wUeQ=.f988c23a-5825-46ae-8eee-bf7715fd7446@github.com> On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: > The standard across all platforms is: > > - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. > - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. > - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. > > The Windows glass code didn't implement the Space exception. This PR fixes that. > > On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. > > For some reason Windows 11 hides this setting well. To install a US International layout: > - Go to Settings > Time & Language > Language & Region. > - In the entry for English click on the three dots to the far right and select 'Language Options'. > - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. > - From the list select "United States - International". > To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). Thank you! Is the `DEAD_ACUTE + c` problem limited to the US International keyboard, or it also happens with other (e.g. German, French?) keyboards? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1584#issuecomment-2383428392 From jcorvel at gmail.com Mon Sep 30 14:55:31 2024 From: jcorvel at gmail.com (Johan Corveleyn) Date: Mon, 30 Sep 2024 16:55:31 +0200 Subject: Integrated: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: On Sat, Sep 28, 2024 at 3:02?PM Martin Fox wrote: > > On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: > > > The standard across all platforms is: > > > > - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. > > - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. > > - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. > > > > The Windows glass code didn't implement the Space exception. This PR fixes that. > > > > On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. > > > > For some reason Windows 11 hides this setting well. To install a US International layout: > > - Go to Settings > Time & Language > Language & Region. > > - In the entry for English click on the three dots to the far right and select 'Language Options'. > > - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. > > - From the list select "United States - International". > > To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). > > This pull request has now been integrated. > > Changeset: 5428f267 > Author: Martin Fox > URL: https://git.openjdk.org/jfx/commit/5428f267887ea4098f6c2a87335de7ed9bf5c656 > Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod > > 8340982: [win] Dead key followed by Space generates two characters instead of one > > Reviewed-by: angorya, jhendrikx > > ------------- > > PR: https://git.openjdk.org/jfx/pull/1584 Great! Thanks for the quick fix. Is there any chance this could be backported to JavaFX 8 and 11 (and perhaps 21)? We're currently still on Java 8, but are working to upgrade to 11 in the next half year or so, and possibly on to 21 after that. I realize this is not such an important issue (it's been there for ages). Still, if it's not too much effort, it would help us to get a hold on that fix (in an official release) in the near future. Thanks, -- Johan From kevin.rushforth at oracle.com Mon Sep 30 15:23:30 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Sep 2024 08:23:30 -0700 Subject: Integrated: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: References: Message-ID: <28aed265-8650-4a7c-bd61-b924eba5d79c@oracle.com> Gluon maintains JavaFX 17 and 21, so Johan can answer that. There is no maintainer for the JavaFX 8 or 11 code lines in OpenJDK. -- Kevin On 9/30/2024 7:55 AM, Johan Corveleyn wrote: > On Sat, Sep 28, 2024 at 3:02?PM Martin Fox wrote: >> On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote: >> >>> The standard across all platforms is: >>> >>> - A dead key followed by a composable character generates the composed character. For example, a circumflex dead key followed by an 'e' should generate '?'. >>> - A dead key followed by a character that can't compose with it generates a spacing character followed by the non-composable character. On Windows US International a circumflex dead key followed by a 'q' generates '^q'. The spacing character corresponding to the dead key varies based on the OS and layout. >>> - An exception is SPACE. On all platforms a dead key followed by SPACE should generate just the spacing version of the dead key but *not* a space character. Users rely on this shortcut to quickly access the character 'hidden' by the dead key. >>> >>> The Windows glass code didn't implement the Space exception. This PR fixes that. >>> >>> On Windows the US US International layout. Shift+6 is the dead key for a circumflex diacritic if you want to test out the combinations mentioned above. >>> >>> For some reason Windows 11 hides this setting well. To install a US International layout: >>> - Go to Settings > Time & Language > Language & Region. >>> - In the entry for English click on the three dots to the far right and select 'Language Options'. >>> - Scroll down until you see 'Installed keyboards' and select 'Add a keyboard'. >>> - From the list select "United States - International". >>> To actually use the layout look to the right of the Task Bar and you should see a button for choosing the layout (it will contain the word "ENG"). >> This pull request has now been integrated. >> >> Changeset: 5428f267 >> Author: Martin Fox >> URL: https://git.openjdk.org/jfx/commit/5428f267887ea4098f6c2a87335de7ed9bf5c656 >> Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod >> >> 8340982: [win] Dead key followed by Space generates two characters instead of one >> >> Reviewed-by: angorya, jhendrikx >> >> ------------- >> >> PR: https://git.openjdk.org/jfx/pull/1584 > Great! Thanks for the quick fix. > > Is there any chance this could be backported to JavaFX 8 and 11 (and > perhaps 21)? > We're currently still on Java 8, but are working to upgrade to 11 in > the next half year or so, and possibly on to 21 after that. > > I realize this is not such an important issue (it's been there for > ages). Still, if it's not too much effort, it would help us to get a > hold on that fix (in an official release) in the near future. > > Thanks, From angorya at openjdk.org Mon Sep 30 15:34:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 30 Sep 2024 15:34:39 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus In-Reply-To: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> References: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> Message-ID: On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote: > This change modifies `ScrollPaneBehavior` to only consume keys that are targetted at it. As `KeyEvent`s are in almost all cases only intended for the targetted node (as visually that's where the user expects the keyboard input to go, as per normal UI rules) consuming key events that bubble up is simply incorrect. When the `ScrollPane` is focused directly (it has the focused border) then it is fine for it to respond to all kinds of keys. > > In FX controls normally there is no need to check if a `Control` is focused (although they probably should **all** do this) as they do not have children that could have received the Key Events involved, and Key Events are always sent to the focused Node. When `ScrollPane` was developed this was not taken into account, leading to it consuming keys not intended for it. > > This fixes several unexpected problems for custom control builders. A custom control normally benefits from standard navigation out of the box (TAB/shift+TAB) and directional keys. However, this breaks down as soon as this custom control is positioned within a `ScrollPane`, which is very surprising behavior and not at all expected. This makes it harder than needed for custom control developers to get the standard navigation for the directional keys, as they would have to specifically capture those keys before they reach the `ScrollPane` and trigger the correct navigation action themselves (for which as of this writing there is no public API). > > The same goes for all the other keys captured by `ScrollPane` when it does not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys. SCCE = Self-contained code example, or "complete code sample" in https://wiki.openjdk.org/display/OpenJFX/Submitting+a+Bug+Report I am not entirely convinced that the proposed solution addresses compatibility concerns, unless this can be demonstrated. I would imagine the idea behind SP handling these keys might have been a desire to be able to scroll the content in the view without changing the currently focused node within possibly? Alternatively, should we use a different set of key bindings instead of simple arrow keys, like for instance alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings, similarly to #1393 ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2383534093 From angorya at openjdk.org Mon Sep 30 16:30:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 30 Sep 2024 16:30:40 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus In-Reply-To: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> References: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> Message-ID: On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote: > This change modifies `ScrollPaneBehavior` to only consume keys that are targetted at it. As `KeyEvent`s are in almost all cases only intended for the targetted node (as visually that's where the user expects the keyboard input to go, as per normal UI rules) consuming key events that bubble up is simply incorrect. When the `ScrollPane` is focused directly (it has the focused border) then it is fine for it to respond to all kinds of keys. > > In FX controls normally there is no need to check if a `Control` is focused (although they probably should **all** do this) as they do not have children that could have received the Key Events involved, and Key Events are always sent to the focused Node. When `ScrollPane` was developed this was not taken into account, leading to it consuming keys not intended for it. > > This fixes several unexpected problems for custom control builders. A custom control normally benefits from standard navigation out of the box (TAB/shift+TAB) and directional keys. However, this breaks down as soon as this custom control is positioned within a `ScrollPane`, which is very surprising behavior and not at all expected. This makes it harder than needed for custom control developers to get the standard navigation for the directional keys, as they would have to specifically capture those keys before they reach the `ScrollPane` and trigger the correct navigation action themselves (for which as of this writing there is no public API). > > The same goes for all the other keys captured by `ScrollPane` when it does not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys. I do not see much behavioral difference between controls inside a regular VBox and VBox inside a ScrollPane https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/FocusPolicyResearch.java Am I doing things wrong? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2383660184 From mfox at openjdk.org Mon Sep 30 16:36:14 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 30 Sep 2024 16:36:14 GMT Subject: RFR: 8183521: Unable to type characters with tilde with swiss german keyboard layout Message-ID: The glass code on Windows does its own dead key processing so at certain points it must clear the dead key state that the OS is maintaining. It does this by simulating a SPACE key press but this only works reliably if the SPACE key is pressed without any modifiers. Currently the code is picking up the current modifier state of the keyboard. If the dead key is invoked using AltGr the code is trying to clear the dead key state using AltGr+Space. This does nothing. The fix is to ignore the current keyboard state and pretend the only key being held down is Space. I haven't figured out a way of providing automated tests for dead keys. There's no way to detect whether the correct keyboard layout is active or to force the correct layout to be active. To test this you'll need to install the correct layout. On Windows 11 go to Settings > Time & language > Language & region. Click on the three dots to the far right of the English entry (or whatever language you're using) and select ?Language options?. Scroll down until you find ?Add a keyboard?. From that button scroll through all the many, many layouts until you find ?Swiss German?. Once you?ve added the keyboard you should see a button on the far right of the task bar to select the layout. The dead key for this bug is where the =/+ key is on the standard US keyboard, top row to the left of Backspace. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into swissgermantilde - Using Space without modifiers to clear dead key state Changes: https://git.openjdk.org/jfx/pull/1585/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1585&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8183521 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1585.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1585/head:pull/1585 PR: https://git.openjdk.org/jfx/pull/1585 From mfox at openjdk.org Mon Sep 30 17:08:44 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 30 Sep 2024 17:08:44 GMT Subject: RFR: 8340982: [win] Dead key followed by Space generates two characters instead of one In-Reply-To: <5ltRq3CYy-YYvIx093TCJNmf948uTN3wYvj0Vr6wUeQ=.f988c23a-5825-46ae-8eee-bf7715fd7446@github.com> References: <5ltRq3CYy-YYvIx093TCJNmf948uTN3wYvj0Vr6wUeQ=.f988c23a-5825-46ae-8eee-bf7715fd7446@github.com> Message-ID: On Mon, 30 Sep 2024 14:49:08 GMT, Andy Goryachev wrote: > Thank you! Is the `DEAD_ACUTE + c` problem limited to the US International keyboard, or it also happens with other (e.g. German, French?) keyboards? I have entered [JDK-8341256](https://bugs.openjdk.org/browse/JDK-8341256) with some background information. I'm not aware of other layouts that would have this particular problem. Layouts associated with languages that use ? (like French) have a dedicated key for it. On other keyboards you just can't type ?. The way US International works is sort of unusual since most layouts handle their dead key combinations in a uniform way. Still, given the way Glass works there's no doubt other layouts which will throw it off. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1584#issuecomment-2383732711 From iris at openjdk.org Mon Sep 30 18:34:39 2024 From: iris at openjdk.org (Iris Clark) Date: Mon, 30 Sep 2024 18:34:39 GMT Subject: RFR: 8340829: Generated API docs should clearly identify EA builds [v2] In-Reply-To: References: Message-ID: <75gkvwTQOAU983c7Vr87W5oMy4ysfTKTqvRlOCdMCEs=.a34a6058-0b3d-4b5c-973e-4193ade2f87a@github.com> On Fri, 27 Sep 2024 13:07:15 GMT, Kevin Rushforth wrote: >> This PR modifies the header and footer of the javadoc-generated API docs to add "DRAFT $VER-ea+$BLD" to clearly identify an ea build of the docs, and also to make it clear which build number the docs refer to. This matches was the JDK does. For GA builds, there will be no change to what we generate today. Since I had to add logic to filter the javadoc properties defined in `build.javadoc` to add the DRAFT message if not a GA build, I also changed the properties to not hard-code the major version of JavaFX, thus reducing the duplication. >> >> I ran three builds to test this, an ordinary developer build, an EA build, and a GA build as follows: >> >> #### Developer build >> >> Command line: >> >> gradle javadoc >> >> >> Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-internal/ >> >> #### EA build >> >> Command line: >> >> gradle -PPROMOTED_BUILD_NUMBER=98 -PHUDSON_BUILD_NUMBER=1234 -PHUDSON_JOB_NAME=jfx-dev javadoc >> >> >> Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-ea/ >> >> #### GA build >> >> Command line: >> >> gradle -PMILESTONE_FCS=true -PPROMOTED_BUILD_NUMBER=99 -PHUDSON_BUILD_NUMBER=4321 -PHUDSON_JOB_NAME=jfx-dev javadoc >> >> >> Generated docs: https://cr.openjdk.org/~kcr/8340829/javadoc-fcs/ > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback Thanks for aligning the javadoc footer/banner with the generated jdk javadoc. I'm particularly happy to see the html comment in the footer. Agree that vertical centering can be investigated later. ------------- Marked as reviewed by iris (no project role). PR Review: https://git.openjdk.org/jfx/pull/1583#pullrequestreview-2338316274 From angorya at openjdk.org Mon Sep 30 19:08:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 30 Sep 2024 19:08:22 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v15] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: file operations ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/198206f8..b22f476c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=14 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=13-14 Stats: 323 lines in 5 files changed: 77 ins; 208 del; 38 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From kcr at openjdk.org Mon Sep 30 21:36:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 30 Sep 2024 21:36:43 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: <5tEA2xhX-RYYZmDpIU7tcPDLSF5nCjHwo_lLhf8wErA=.82156460-1310-47e7-9e17-28e85dea4e49@github.com> Message-ID: On Fri, 13 Sep 2024 21:21:56 GMT, Andy Goryachev wrote: > > `fromInlineStyle` docs that it is equivalent to `fromStyles(style)`. > > good point, thanks! > > edit: actually, these are hidden behind RichParagraph.Builder methods, so they can be made package-protected. Also, StyleAttributeMap.fromTextNode() can be hidden since it's an impl. detail. You mean `StyleAttributeMap.Builder`, right? Question then: how do I now create a StyleAttributeMap from a CSS style? I ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2384182457 From kcr at openjdk.org Mon Sep 30 21:44:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 30 Sep 2024 21:44:42 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v15] In-Reply-To: References: Message-ID: On Mon, 30 Sep 2024 19:08:22 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > file operations A few additional comments. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1038: > 1036: * @return the text position at the end of the appended text, or null if editing is disabled > 1037: * @throws NullPointerException if the model is {@code null} > 1038: * @throws UnsupportedOperationException if the model is not {@link StyledTextModel#isWritable() writable} This matches what we had previous discussed. To capture some additional thinking I have around this, there are two possible exceptions we could throw here: `UnsupportedOperationException` or `IllegalStateException`. Given the reason we are throwing the exception, they are similar in meaning to each other. Typically UOE means "this is illegal for this instance of this object" while ISE mean "this is illegal at this time given the current state of the object (or some other state)". For similar methods in the _model_, UOE is clearly the right thing to throw, since that model is not writable (and won't be). For the RichTextArea control, it isn't a clear cut. While unlikely, the model is a property of the control that you can change at runtime if you want to (NB: has this been tested?), which would suggest ISE might be more clear. However, since this exception is basically rethrowing an exception from the model, having it be a different exception class might be unexpected. Let's leave it as you have it for now. I don't expect we will revisit it unless someone comes up with a compelling reason. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1138: > 1136: * by the model. > 1137: *

    > 1138: * This method does nothing when the caret position is {@code null}. What does it do if the model is null? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1166: > 1164: * This method does nothing if the model or the caret position is {@code null}. > 1165: * The default implementation may throw an {@code UnsupportedOperationException} > 1166: * if the control is not editable. When this happens, the copying to clipboard will succeed. Same question here (and elsewhere so I won't repeat after this) : should this throw an exception here since it is the target of an input function tag? If so, then it should throw on a null model rather than doing nothing; as it stands, it is inconsistent. ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2338497775 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1781693413 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1781733535 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1781736060 From kcr at openjdk.org Mon Sep 30 21:44:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 30 Sep 2024 21:44:43 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v10] In-Reply-To: References: Message-ID: On Tue, 17 Sep 2024 21:21:49 GMT, Andy Goryachev wrote: >> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 314: >> >>> 312: /** >>> 313: * Creates the instance with the in-memory model {@link RichTextModel}. >>> 314: */ >> >> I recommend adding `@defaultValue` > > Can you clarify please? `@defaultValue` seem to apply to a property, this is a constructor. Oh, right. Never mind. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1781743864 From kcr at openjdk.org Mon Sep 30 21:44:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 30 Sep 2024 21:44:44 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v7] In-Reply-To: References: Message-ID: On Mon, 9 Sep 2024 15:10:00 GMT, Andy Goryachev wrote: >> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1076: >> >>> 1074: * When selection exists, deletes selected text. Otherwise, deletes the character preceding the caret, >>> 1075: * possibly breaking up the grapheme clusters. >>> 1076: * This method does nothing if either control or the model is not editable, or the caret position is {@code null}. >> >> Suggestion for here and similar methods: >> >> "does nothing if the control is not editable or the model is not writable..." > > changed this and similar methods to throw an exception This is still pending, since the docs haven't been updated. Is an exception really what you want in this case? This method is the target of a function tag: We definitely don't want to produce an exception when the user presses the DELETE key; should calling the method directly throw an exception? If so, you will need logic to detect when it is called from an input event vs directly. Whatever we decide should apply to a null model as well. Either a null model and a read-only model should both throw an exception or neither should. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1781726542 From kcr at openjdk.org Mon Sep 30 21:55:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 30 Sep 2024 21:55:42 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v15] In-Reply-To: References: Message-ID: <-2bdNRUvNBkB9UXfc6peLcM_WR6_zsWqIF4YVRZyDTU=.82737791-070b-478b-b999-7815ee4fd38d@github.com> On Mon, 30 Sep 2024 19:08:22 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > file operations I think the following behavior is probably what we want for RichTextArea (control) methods: The methods that can be used to programmatically modify the text -- `appendText`, `insertText`, `replaceText`, `applyStyle`, `setStyle`, and `clear` -- throw an exception if the model is null or is not writable. They do not care about the `editable` state. The methods that are mapped to input function tags (`delete`, `copy`, `cut`, `paste`, etc) do nothing if `editable` is `false` or if the model is null; they don't modify the text if the model is not writable (so, for example, cut will do a copy). They do not throw an exception. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2384225811 From kneester77 at gmail.com Mon Sep 30 23:01:02 2024 From: kneester77 at gmail.com (Knee Snap) Date: Mon, 30 Sep 2024 16:01:02 -0700 Subject: [Feature Proposal]: TriangleMesh - Vertex Color Support In-Reply-To: References: Message-ID: The code snippet returns true because if the VertexFormat specifies no normal data, then the contents of the normals array are valid no matter what they are, because they are unused. validateNormals() is called regardless of if normals are used by the VertexFormat which is why it explicitly includes that check. validateNormals() is only returning whether the mesh data is valid, and if the VertexFormat does not include normal data, then the normal array is always treated as valid (as normals are not used and thus the mesh is valid regardless of the contents of the array). Regarding the last sentence of the previous email, yes, that is the same as option #2 in my last email. This would break the existing design choices (as you've noticed with normals), but it is one of the paths I can see working. On Mon, Sep 30, 2024, 2:58?AM Nir Lisker wrote: > I would first try to figure out if the code in the snippet I gave is > actually correct. If it is, then the vertex format has a functional use. If > it's not, then we can think about what to do with it. I didn't look into > it, but on the face of it, it doesn't look like the unused normals should > be validated. > > The last sentence in my previous mail suggested a different solution: keep > the vertex format as it is (for now) to dictate how points and normals are > read, but add color without interaction with the vertex format. The color > will be used if it's not empty/null. > This keeps everything as it is, avoids multiplications of formats, and > doesn't hinder possible future additions that will also not use the vertex > format. On the slightly confusing side, it means that vertex format doesn't > define the format for *all* the data of the vertex, just for its positional > components that are mandatory (at the very least, points should be > supplied). > > On Mon, Sep 30, 2024 at 3:12?AM Knee Snap wrote: > >> These are some great points! >> >> Nir mentioned a builder-style pattern for TriangleMesh, but I struggle to >> think of how this could work well, as one critical feature of the current >> API is to be able to dynamically update mesh data, which is very important >> for any kind of animated mesh. I'd love to see any designs that get >> prototyped though (regardless of if they are builder-like). >> >> Let's discuss the big question though, VertexFormat's design. >> >> To be honest, light maps and shadow maps seem unrealistic right now. They >> are way too intensive to generate in JavaFX (we'd need a LOT of work to do >> this efficiently, only for the user to not like the algorithm we selected). >> And even if the user gets this far, they'll be faced with a significant >> performance penalty. Light maps usually contain data for many 3D objects, >> but due to JavaFX rendering order being based on the scene graph order, >> which is going to cause a significant amount of large texture swaps. I'd be >> open to changing that and do hope to fix the performance issues as much as >> we can, but overall it strikes me as a very far-fetched feature. >> >> Regarding bones/skeletal rigs, that's a really good idea actually. I'm >> kind of shocked I didn't think of that sooner. >> >> I've got a few ideas for how we can tackle these problems, but none >> particularly jump out as the perfect option to me, so I'm hoping for >> feedback on what you guys think. >> >> *1) Why not let users define their own VertexFormats? If our concern is >> the explosion of definitions we'd be keeping statically, we could just >> define a handful of built-in formats but let users define formats as they >> see fit. Similar to the Cesium Project Nir linked.* >> >> *Pros:* >> - This would avoid the explosion of built-in formats, since we wouldn't >> need to explicitly define/support every single format, but instead let the >> user define the format themselves. >> >> *Cons:* >> - Doesn't address the concern of TriangleMesh properties not serving any >> purpose depending on what VertexFormat it has. >> >> *2) Have TriangleMesh automatically determine format based on which >> buffers contain/do not contain data.* >> This is extremely similar to #1, except it >> >> We could keep VertexFormat around, but make it read-only, so it only >> serves as a reflection of the data in TriangleMesh, instead of something >> the user can apply. We'd deprecate the constructor >> TriangleMesh(VertexFormat) and TriangleMesh.setFormat(VertexFormat) but >> keep them around (they would do nothing) thus keeping code compatibility >> (and maybe also binary compatibility?). >> >> *Pros:* >> - Avoid bloat. >> - Extensible without ever leaving any functionality both unusable and >> accessible. (IDEA: What if it's not fully removed, but instead is a >> read-only property obtainable inside TriangleMesh, and the constructor >> which accepts a VertexFormat deprecated instead? It still feels appropriate >> to get vertex format data from VertexFormat instead of the mesh itself) >> >> *Cons:* >> - Breaking API change. (If we deprecate/remove VertexFormat) >> - The user is still responsible for supplying the faces array in the >> correct format, and making the VertexFormat calculated implicitly behind >> the scenes (something the user must respond to or the mesh will either not >> render or display corrupted if we can't tell), would be hidden from the >> user. Currently the user has to explicitly say they're changing the format, >> but this automatic behavior is less clear to the user. Not a huge deal but >> worth considering. >> >> The overall outcome of this seems pretty similar to #1, but it loses the >> benefit of explicitness in exchange for not ever having buffers which are >> unusable but still accessible. I'm personally torn on if this trade-off is >> worth it. >> >> *3) Add Vertex Colors to VertexFormat, but future features use either #1 >> or #2.* >> Bump map tangents/light map uvs/skeleton seem significantly less >> ubiquitous than vertex colors even if they're still important. Picking this >> option would expand the already questionable normals design, but >> considering these future features may never be added, perhaps it makes >> sense to keep the existing design until we're sure we're even going to add >> the others. And at that point we'd be in exactly the same position as now >> with exactly the same options for implementing it. In other words, it buys >> us time while still letting us scrap VertexFormat if the time ever comes. >> >> *Pros:* >> - Keeps all existing features consistent with existing public API design. >> - Avoids bloat >> - Avoids breaking consistency with the existing public API up until the >> moment we start adding less common data fields. >> >> *Cons:* >> - If Option #1 is picked for future features, the same cons from #1 are >> present. >> - If Option #2 is picked for future features, the same cons from #2 are >> present. >> - If we're going to deprecate VertexFormat, it might be a valid point >> that that we don't actually want to delay that, and would rather do it >> earlier rather than later. >> >> I'm torn between all of the options I've listed here. What do you guys >> think? >> >> We should also discuss how other primitive topologies (POINT, LINE, >> TRIANGLE, TRIANGLE_STRIP) could work and how this might factor into our >> VertexFormat discussions. (Should LINE really even be represented by >> TriangleMesh and not a new LineMesh? Would it make sense to still use >> VertexFormat?) >> >> On Mon, Sep 23, 2024, 9:23?AM Nir Lisker wrote: >> >>> Having gone through some sources, I found the additional properties that >>> can be added as per-vertex data: >>> * Additional texture coordinates (mentioned by Michael). These can be >>> used for detailed textures. >>> * Bone indices and weights. These are for GPU skinning. Interestingly, >>> the D3D vertex shader constants file has some preparation for skinning and >>> bones [1]. >>> * Tangents. Used similarly to normals in some lighting-related >>> calculations. >>> >>> While it's not clear that we'll need these, the proliferation of vertex >>> formats will be unmanageable with even one of these added (in addition to >>> color). >>> >>> Looking at the use of VertexFormat in TriangleMesh with regards to >>> normals: >>> >>> private boolean validateNormals() { >>> // Only validate normals if vertex format has normal component >>> if (getVertexFormat() != VertexFormat.POINT_NORMAL_TEXCOORD) return >>> true; >>> >>> if (normals.size() == 0) { // Valid but meaningless for picking or >>> rendering. >>> return false; >>> ... >>> } >>> >>> I'm confused by this. If the normals should be validated only when the >>> vertex format defines that normals are used, why does the method return >>> true when normals aren't used? >>> I would think, along with what Michael said, that either if the vertex >>> format doesn't declare normals, or the user doesn't declare normal (size >>> ==0), then the normals wouldn't be validated. That would also mean that the >>> vertex format is redundant since it's implied by the existence/length of >>> the array. >>> >>> Perhaps it's worth looking at the color implementation this way. >>> Additional vertex formats should not be added, and the use of vertex colors >>> should be dictated by looking at the array. >>> >>> [1] >>> https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/native-prism-d3d/hlsl/vsConstants.h >>> >>> On Sat, Sep 21, 2024 at 5:17?AM Michael Strau? >>> wrote: >>> >>>> > I'm not yet convinced that new vertex formats are the way to go. >>>> >>>> To be fair, I'm not sure why VertexFormat even exists. It serves no >>>> purpose when creating a TriangleMesh, as the vertex format could >>>> easily be inferred by the presence (or absence) of vertex data. Having >>>> users specify the VertexFormat explicitly is probably not a good API, >>>> as it now makes the other data components be dependent on the choice >>>> of the vertex format. >>>> >>>> Of course, not all combinations of vertex data are valid, but this >>>> could be specified in documentation and be validated by the >>>> implementation. I think it might be best to deprecate VertexFormat for >>>> removal. This would also prevent a potential explosion of vertex >>>> formats in the public API. >>>> >>>> I have no objection to the choice to add vertex colors as an >>>> additional data component to TriangleMesh. It adds to the API, but >>>> this is not a slippery slope as there's only a very finite set of >>>> features we might be tempted to add next: >>>> >>>> The most obvious thing that JavaFX 3D really can't do is shadows. >>>> These come in static form (light mapping) and dynamic form (shadow >>>> mapping). Light mapping requires a second set of texcoords, while >>>> shadow mapping does not. >>>> >>>> Adding light mapping would make JavaFX 3D competitive with late-90's >>>> graphics, and adding shadow mapping would make it competitive with >>>> early-2000's graphics. >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: