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-