From torbjorn at torsvik.net Wed Sep 1 10:50:30 2021 From: torbjorn at torsvik.net (=?UTF-8?Q?Torbj=C3=B8rn_Torsvik?=) Date: Wed, 1 Sep 2021 12:50:30 +0200 Subject: JDK-8092100 : Text needs to support letter spacing Message-ID: Hi. I'm new to this mailing list. I have read through the rules and guidelines. My apologies if I have missed or misinterpreted anything. Text (and Label) has no support for letter spacing. This was first noted back in 2011 (JDK-8092100, unresolved, https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8092100), and also commented on when a "-fx-letter-spacing" css property was requested in 2014 (JDK-8090880, unresolved, https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8090880). >From what I can tell, the issue has not received much attention. The feature might seem minor, but is sorely missed at least by me. I'm trying to implement a user interface following google's material design, but am unable to follow the typography guidelines ( https://material.io/design/typography/the-type-system.html#type-scale) since letter spacing is not supported. Although admittedly not the most noticeable of features, there's a reason for why it's often specified in design guidelines. Failure to take it into account will often lead to an interface looking "not quite right" ( https://www.webdesignerdepot.com/2020/07/the-designers-guide-to-letter-spacing/ ). I have looked through the source, and have a few ideas for how to implement this feature. I gather that before proposing any code change, I should make a CSR which must be approved by the lead of this project. I find no guidelines detailing what a CSR must include. Will this message suffice? From johan.vos at gluonhq.com Wed Sep 1 11:15:54 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 1 Sep 2021 13:15:54 +0200 Subject: Gtk4 and Wayland In-Reply-To: References: Message-ID: Hi Thiago, I was thinking (and experimenting) in the same direction, and so far that is working good. I don't see disadvantages, but it would be good to find out about it before we move forward. Maybe the main issue to me is that GTK comes with lots of dependencies. We already have that situation today, so it is not going to be worse. But if we would use the Wayland protocol on a lower level (with a Wayland-specific glass platform, instead of GTK), we could probably reduce the dependencies. However, this comes at the price of creating *and maintaining* more low-level code. I've been running GTK3 on Wayland and that works fine too. However, it might be better to focus Wayland support for GTK4. I think there won't be many installs that have no X11, but only Wayland, and that have GTK3 and no GTK4. - Johan - Johan On Tue, Aug 31, 2021 at 11:03 PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Hi, > > I did some investigation on gtk4 and wayland. > > After some research I ended up with the conclusion that the best way is to > do a separate gtk4 backend, that would support X11 and Wayland. > > This would be a good start: > https://github.com/openjdk/jfx/pull/77/files > > Why? > > Gtk4 moves the decoration to the client side, which is GREAT since knowing > the window size with decoration was a real pain. > > We probably won't want to do all the decoration work, Gtk does that, but on > GtkWindow level, not GdkSurface (which replaces GdkWindow). > > Thus the move to use "more Gtk" (hence "less Gdk") which is exactly what > the PR does. It also removes Applet code > > This is also a good starting point: > https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html > > --Thiago. > From neugens at redhat.com Wed Sep 1 11:26:34 2021 From: neugens at redhat.com (Mario Torre) Date: Wed, 1 Sep 2021 13:26:34 +0200 Subject: Gtk4 and Wayland In-Reply-To: References: Message-ID: On Wed, Sep 1, 2021 at 1:18 PM Johan Vos wrote: > > Hi Thiago, > > I was thinking (and experimenting) in the same direction, and so far that > is working good. I don't see disadvantages, but it would be good to find > out about it before we move forward. > Maybe the main issue to me is that GTK comes with lots of dependencies. We > already have that situation today, so it is not going to be worse. But if > we would use the Wayland protocol on a lower level (with a Wayland-specific > glass platform, instead of GTK), we could probably reduce the dependencies. > However, this comes at the price of creating *and maintaining* more > low-level code. > > I've been running GTK3 on Wayland and that works fine too. However, it > might be better to focus Wayland support for GTK4. I think there won't be > many installs that have no X11, but only Wayland, and that have GTK3 and no > GTK4. I tend to agree with you, I think we should consider this for Wakefield too. Cheers, Mario > - Johan > - Johan > > On Tue, Aug 31, 2021 at 11:03 PM Thiago Milczarek Say?o < > thiago.sayao at gmail.com> wrote: > > > Hi, > > > > I did some investigation on gtk4 and wayland. > > > > After some research I ended up with the conclusion that the best way is to > > do a separate gtk4 backend, that would support X11 and Wayland. > > > > This would be a good start: > > https://github.com/openjdk/jfx/pull/77/files > > > > Why? > > > > Gtk4 moves the decoration to the client side, which is GREAT since knowing > > the window size with decoration was a real pain. > > > > We probably won't want to do all the decoration work, Gtk does that, but on > > GtkWindow level, not GdkSurface (which replaces GdkWindow). > > > > Thus the move to use "more Gtk" (hence "less Gdk") which is exactly what > > the PR does. It also removes Applet code > > > > This is also a good starting point: > > https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html > > > > --Thiago. > > > -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From kevin.rushforth at oracle.com Wed Sep 1 11:41:08 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 1 Sep 2021 04:41:08 -0700 Subject: Gtk4 and Wayland In-Reply-To: References: Message-ID: <4b837870-9178-bb16-becc-044dea5a14ec@oracle.com> This seems reasonable to me as well, at least for JavaFX since we already rely on Gtk for most of the windowing toolkit on Linux. -- Kevin On 9/1/2021 4:26 AM, Mario Torre wrote: > On Wed, Sep 1, 2021 at 1:18 PM Johan Vos wrote: >> Hi Thiago, >> >> I was thinking (and experimenting) in the same direction, and so far that >> is working good. I don't see disadvantages, but it would be good to find >> out about it before we move forward. >> Maybe the main issue to me is that GTK comes with lots of dependencies. We >> already have that situation today, so it is not going to be worse. But if >> we would use the Wayland protocol on a lower level (with a Wayland-specific >> glass platform, instead of GTK), we could probably reduce the dependencies. >> However, this comes at the price of creating *and maintaining* more >> low-level code. >> >> I've been running GTK3 on Wayland and that works fine too. However, it >> might be better to focus Wayland support for GTK4. I think there won't be >> many installs that have no X11, but only Wayland, and that have GTK3 and no >> GTK4. > I tend to agree with you, I think we should consider this for Wakefield too. > > Cheers, > Mario > >> - Johan >> - Johan >> >> On Tue, Aug 31, 2021 at 11:03 PM Thiago Milczarek Say?o < >> thiago.sayao at gmail.com> wrote: >> >>> Hi, >>> >>> I did some investigation on gtk4 and wayland. >>> >>> After some research I ended up with the conclusion that the best way is to >>> do a separate gtk4 backend, that would support X11 and Wayland. >>> >>> This would be a good start: >>> https://github.com/openjdk/jfx/pull/77/files >>> >>> Why? >>> >>> Gtk4 moves the decoration to the client side, which is GREAT since knowing >>> the window size with decoration was a real pain. >>> >>> We probably won't want to do all the decoration work, Gtk does that, but on >>> GtkWindow level, not GdkSurface (which replaces GdkWindow). >>> >>> Thus the move to use "more Gtk" (hence "less Gdk") which is exactly what >>> the PR does. It also removes Applet code >>> >>> This is also a good starting point: >>> https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html >>> >>> --Thiago. >>> > From arapte at openjdk.java.net Thu Sep 2 09:20:40 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Sep 2021 09:20:40 GMT Subject: RFR: 8269081: Tree/ListViewSkin: must remove flow on dispose In-Reply-To: <7RgCoBT0MIeJkxgYffwL6o1oNldqfqds75JgQoHInXk=.2de3fbf9-97be-4645-9795-cd0ae9257d89@github.com> References: <7RgCoBT0MIeJkxgYffwL6o1oNldqfqds75JgQoHInXk=.2de3fbf9-97be-4645-9795-cd0ae9257d89@github.com> Message-ID: On Fri, 27 Aug 2021 11:15:58 GMT, Jeanette Winzenburg wrote: > left-over issue from cleanup of Tree/ListViewSkin: direct children that have been added by the skin must be removed in dispose > > fixed by removing the flow (which allowed to revert the previous cleanup of event handlers/cellfactory) > > added tests to verify > - constant child count after replacing skin > - no memory leak when switching skin while showing Looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/612 From nlisker at gmail.com Thu Sep 2 09:57:49 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 2 Sep 2021 12:57:49 +0300 Subject: Eager Evaluation of Invalidation Listeners In-Reply-To: <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl> References: <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl> Message-ID: > > So in order > to make sure that a new interested invalidation listener does not miss > the fact that a property was *already* invalid, the easiest solution > might have been to revalidate it upon registration of a new listener > But why does an invalidation listener need to know the past state of the property? It is only interested in the valid -> invalid transition. If the property was invalid then the listener (in theory) shouldn't receive any events anyway on subsequent invalidations. (I understand that you don't justify this, I'm posing it as a general question.) I suggest that we split the problem into 2: one is the case where the property was valid when the listener was attached, and the other is when it was invalid. * A valid starting state. In this case attaching a listener shouldn't need to do anything. A subsequent invalidation event will be sent regardless. Currently, it is calling get() redundantly. * An invalid starting state. In this case the documentation says that nothing needs to happen, but get() is called anyway. Here, the difference is that a subsequent invalidation event is sent in one case and not in the other. The only way to advance here is to make a design decision on what should happen, at least that's how I see it. As to the implementation of a possible solution, suppose we add the isValid method. Upon attaching an invalidation listener, if the property is valid, we can skip the get() call. That solves the valid starting state issue. The question is what to do if the property is not valid. I also noticed an odd design choice in the implementation of properties: the value field does not update if the property is bound, instead, the result of the binding is returned and the value field holds an outdated value (until the property is unbound). I would have thought that the value would always be stored, and the binding will only be recomputed if the value is invalid. If this was the case, there would not have been an eager evaluation for the case when the property was valid upon attachment. In a way, the implementation question here is if we expose the valid state to let classes like ExpressionHelper check the valid state and decide what to do, or if they call get() anyway and it's the property's job to not recompute a valid value. I think we can defer this discussion to a later stage. An interesting solution could be to send out an Invalidation event > eagerly only to a newly registered listener if said property was invalid > at the time of registration; > I understand the reasoning, but I think that sending an invalidation event after the invalidation happened will be confusing and it's not what the specs say, and might cause backward compatibility issues. On Wed, Sep 1, 2021 at 12:28 AM John Hendrikx wrote: > > > On 31/08/2021 17:52, Nir Lisker wrote: > > Hi, > > > > This is a continuation of the discussion that stemmed from changing > > bidirectional bindings to use invalidation listeners instead of change > > listeners [1]. > > > > The relevant issue in JBS is [2]. > > > > I have looked at removing the eager evaluation when attaching an > > invalidation listener. I found that tests, for example, the > > method > BooleanPropertyBaseTest#testAddingListenerWillAlwaysReceiveInvalidationEvent > > (only lines 428-432 are relevant) set the following requirement: > > > > 1. Start with a property in an invalid state. > > 2. Attach an invalidation listener. > > 3. Set a value which is different than the current one. > > Result: an invalidation event must be sent. > > > > This means that attaching an invalidation listener must validate the > > property, which is (at least currently) only possible by evaluating the > > value. > > > > This is in contrast to the comment in the JBS that invalidation listeners > > should not generally force eager evaluation. It is also in contrast to > this > > line in the class doc of ObservableValue: > > "Implementations in this library mark themselves as invalid when the > first > > invalidation event occurs. They do not generate any more invalidation > > events until their value is recomputed and valid again." > > > > So, either the requirement set by the tests is wrong, or invalidation > > listeners really do need to behave according to the test and the docs > > missed a practical requirement, or my analysis is wrong. > > What I'm thinking is that perhaps the revalidation on registering a new > InvalidationListener was done intentionally as there is no mechanism to > query the current valid state of an observable (#isValid). So in order > to make sure that a new interested invalidation listener does not miss > the fact that a property was *already* invalid, the easiest solution > might have been to revalidate it upon registration of a new listener -- > then again, this does not communicate this fact, it only does so when > the property changes again. > > An interesting solution could be to send out an Invalidation event > eagerly only to a newly registered listener if said property was invalid > at the time of registration; this would inform the new listener that the > property was already invalid but would not notify any existing listeners > (as they already know the property to be invalid). > > > There are more tests that fail, but the ones I looked at rely on the same > > concept. For > > example, > Node_LocalToParentTransform_Test#shouldBeNotifiedWhenNodeTransforms() > > tests the Node#LazyTransformProperty property. Interestingly, this one is > > initialized with an invalid state, while Simple___Property are > initialized > > as valid. > > > > Thoughts? > > Perhaps we could consider the registration of an invalidation listener > to be infrequent enough to be of little consequence, although I agree > that the documentation and tests are not in agreement. > > --John > From fastegal at openjdk.java.net Thu Sep 2 11:34:30 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Sep 2021 11:34:30 GMT Subject: Integrated: 8269081: Tree/ListViewSkin: must remove flow on dispose In-Reply-To: <7RgCoBT0MIeJkxgYffwL6o1oNldqfqds75JgQoHInXk=.2de3fbf9-97be-4645-9795-cd0ae9257d89@github.com> References: <7RgCoBT0MIeJkxgYffwL6o1oNldqfqds75JgQoHInXk=.2de3fbf9-97be-4645-9795-cd0ae9257d89@github.com> Message-ID: On Fri, 27 Aug 2021 11:15:58 GMT, Jeanette Winzenburg wrote: > left-over issue from cleanup of Tree/ListViewSkin: direct children that have been added by the skin must be removed in dispose > > fixed by removing the flow (which allowed to revert the previous cleanup of event handlers/cellfactory) > > added tests to verify > - constant child count after replacing skin > - no memory leak when switching skin while showing This pull request has now been integrated. Changeset: e9315014 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/e9315014f4accd97d757689d5ff212dd536a6e61 Stats: 90 lines in 3 files changed: 68 ins; 18 del; 4 mod 8269081: Tree/ListViewSkin: must remove flow on dispose Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/612 From fastegal at openjdk.java.net Thu Sep 2 12:49:49 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 2 Sep 2021 12:49:49 GMT Subject: RFR: 8273071: SeparatorSkin: must remove child on dispose Message-ID: minor skin cleanup issue: SeparatorSkin didn't remove the line it added to the control's children fix is to override dispose and include the removal for testing: removed the exclusion of SeparatorSkin from memoryLeakTest - doing so lets it fail/pass before/after this fix ------------- Commit messages: - 8273071: SeparatorSkin: must remove child on dispose Changes: https://git.openjdk.java.net/jfx/pull/616/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=616&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273071 Stats: 14 lines in 2 files changed: 7 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/616.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/616/head:pull/616 PR: https://git.openjdk.java.net/jfx/pull/616 From arapte at openjdk.java.net Thu Sep 2 13:13:39 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Sep 2021 13:13:39 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 17:40:48 GMT, Nir Lisker wrote: >> Added convenience factory factory methods for Background and Border. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Corrected comment tags Provided few suggestions for doc. modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 357: > 355: > 356: /** > 357: * A convenience factory method for creating a background with a single {@code Paint}. The background will use the Suggestion to rephrase as: `A convenience factory method for creating a Background by specifying only the {@code Paint} for BackgroundFill` modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 361: > 359: * > 360: * @implSpec This call is equivalent to {@code new Background(new BackgroundFill(fill, null, null));}. > 361: * @param fill the fill of the background `@param fill Any Paint. If null, the value Color.TRANSPARENT is used.` Picked from BackgroundFill constructor's doc modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 393: > 391: > 392: /** > 393: * A convenience factory method for creating a solid border with a single {@code Paint}. The border will use the Suggestion to rephrase as: `A convenience factory method for creating a solid Border by specifying only the {@code Paint} for BorderStroke.` modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 398: > 396: * @implSpec > 397: * This call is equivalent to {@code new Border(new BorderStroke(stroke, BorderStrokeStyle.SOLID, null, null));}. > 398: * @param stroke the stroke of the border `@param stroke The stroke to use for all sides. If {@code null}, defaults to {@code Color.BLACK}.` Picked from BorderStroke doc ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/610 From arapte at openjdk.java.net Thu Sep 2 13:13:41 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 2 Sep 2021 13:13:41 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 14:13:01 GMT, Kevin Rushforth wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected comment tags > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 364: > >> 362: * {@code new Background(new BackgroundFill(fill, null, null));} >> 363: * @param fill the fill of the background >> 364: * @return a new background of the given fill > > Need to add `@since 18` `@return a new background of the given fill` -> `@return a new Background with specified fill` > modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line 400: > >> 398: * {@code new Border(new BorderStroke(stroke, BorderStrokeStyle.SOLID, null, null));} >> 399: * @param stroke the stroke of the border >> 400: * @return a new border of the given stroke > > Same comments about the javadoc as above. `@return a new border of the given stroke` -> `@return a new Border with the specified stroke` ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From andrea.vacondio at gmail.com Thu Sep 2 14:12:20 2021 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Thu, 2 Sep 2021 16:12:20 +0200 Subject: JDK-8092100 : Text needs to support letter spacing In-Reply-To: References: Message-ID: I'm also interested in this feature and I can also help if help is needed Il mer 1 set 2021, 12:51 Torbj?rn Torsvik ha scritto: > Hi. I'm new to this mailing list. I have read through the rules and > guidelines. My apologies if I have missed or misinterpreted anything. > > Text (and Label) has no support for letter spacing. This was first noted > back in 2011 (JDK-8092100, unresolved, > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8092100), and also > commented on when a "-fx-letter-spacing" css property was requested in 2014 > (JDK-8090880, unresolved, > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8090880). > > From what I can tell, the issue has not received much attention. The > feature might seem minor, but is sorely missed at least by me. I'm > trying to implement a user interface following google's material design, > but am unable to follow the typography guidelines ( > https://material.io/design/typography/the-type-system.html#type-scale) > since letter spacing is not supported. Although admittedly not the most > noticeable of features, there's a reason for why it's often specified in > design guidelines. Failure to take it into account will often lead to an > interface looking "not quite right" ( > > https://www.webdesignerdepot.com/2020/07/the-designers-guide-to-letter-spacing/ > ). > > I have looked through the source, and have a few ideas for how to implement > this feature. I gather that before proposing any code change, I should make > a CSR which must be approved by the lead of this project. I find no > guidelines detailing what a CSR must include. Will this message suffice? > From trkas at eg.dk Thu Sep 2 18:07:36 2021 From: trkas at eg.dk (Troels Skytte Kaspersen) Date: Thu, 2 Sep 2021 18:07:36 +0000 Subject: Critical error when showing and hiding stage or popup Message-ID: Hi, We have received many complaints from our customers that the popups are not shown anymore after a period of time. I have then created a simple piece of code that result in the error our customers get: package test; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.StackPane; import javafx.stage.Popup; import javafx.stage.Stage; public class TestFX extends Application { @Override public void start(Stage primaryStage) { System.out.println("javafx.runtime.version: " + System.getProperties().get("javafx.runtime.version")); Stage stage = new Stage(); Scene scene = new Scene(new StackPane()); stage.setScene(scene); stage.show(); Popup popOver = new Popup(); for (int i = 0; i < 99999; i++) { popOver.show(scene.getRoot(), 1, 1); popOver.hide(); System.out.println(i); } } public static void main(String[] args) { launch(args); } } I use javafx 16+8 If I run the code, it will result in error after various iterations: Exception in Application start method Exception in thread "JavaFX Application Thread" java.lang.NullPointerException at javafx.base/com.sun.javafx.binding.ExpressionHelper.removeListener(ExpressionHelper.java:73) at javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.removeListener(ReadOnlyBooleanPropertyBase.java:67) at javafx.graphics/javafx.stage.PopupWindow.unbindOwnerFocusedProperty(PopupWindow.java:895) at javafx.graphics/javafx.stage.PopupWindow.doVisibleChanged(PopupWindow.java:542) at javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanged(PopupWindow.java:111) at javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangedImpl(PopupWindowHelper.java:63) at javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanged(WindowHelper.java:77) at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1160) at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) at javafx.graphics/javafx.stage.Window.hide(Window.java:1212) at javafx.graphics/javafx.stage.PopupWindow.hide(PopupWindow.java:486) at javafx.graphics/javafx.stage.PopupWindow.lambda$new$0(PopupWindow.java:147) at javafx.base/javafx.beans.value.WeakChangeListener.changed(WeakChangeListener.java:86) at javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) at javafx.graphics/javafx.scene.Node$TreeShowingPropertyReadOnly.invalidate(Node.java:8479) at javafx.graphics/javafx.scene.Node.setTreeShowing(Node.java:8436) at javafx.graphics/javafx.scene.Node.updateTreeShowing(Node.java:8427) at javafx.graphics/javafx.scene.Node.lambda$new$2(Node.java:1010) at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) at javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.fireValueChangedEvent(ReadOnlyBooleanPropertyBase.java:78) at javafx.base/javafx.beans.property.ReadOnlyBooleanWrapper.fireValueChangedEvent(ReadOnlyBooleanWrapper.java:103) at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:111) at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) at javafx.graphics/javafx.stage.Window.hide(Window.java:1212) at javafx.graphics/com.sun.javafx.stage.WindowPeerListener.closed(WindowPeerListener.java:105) at javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:144) at javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:40) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.lambda$handleWindowEvent$4(GlassWindowEventHandler.java:176) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:412) at javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.handleWindowEvent(GlassWindowEventHandler.java:174) at javafx.graphics/com.sun.glass.ui.Window.handleWindowEvent(Window.java:1336) at javafx.graphics/com.sun.glass.ui.Window.notifyDestroy(Window.java:1250) at javafx.graphics/com.sun.glass.ui.win.WinWindow._close(Native Method) at javafx.graphics/com.sun.glass.ui.Window.close(Window.java:352) at javafx.graphics/com.sun.glass.ui.win.WinWindow.close(WinWindow.java:316) at javafx.graphics/com.sun.glass.ui.Application.terminate(Application.java:394) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$exit$13(QuantumToolkit.java:831) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:827) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:614) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) at java.base/java.lang.Thread.run(Thread.java:831) java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:464) at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1071) Caused by: java.lang.RuntimeException: Exception in Application start method at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:900) at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) at java.base/java.lang.Thread.run(Thread.java:831) Caused by: java.lang.RuntimeException: could not create platform window at javafx.graphics/com.sun.glass.ui.Window.(Window.java:294) at javafx.graphics/com.sun.glass.ui.win.WinWindow.(WinWindow.java:54) at javafx.graphics/com.sun.glass.ui.win.WinApplication.createWindow(WinApplication.java:219) at javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.initPlatformWindow(WindowStage.java:201) at javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.init(WindowStage.java:143) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.createTKPopupStage(QuantumToolkit.java:678) at javafx.graphics/javafx.stage.PopupWindow.doVisibleChanging(PopupWindow.java:514) at javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanging(PopupWindow.java:107) at javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangingImpl(PopupWindowHelper.java:57) at javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanging(WindowHelper.java:73) at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1065) at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) at javafx.graphics/javafx.stage.Window.show(Window.java:1202) at javafx.graphics/javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) at javafx.graphics/javafx.stage.PopupWindow.show(PopupWindow.java:417) at test.TestFX.start(TestFX.java:35) at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) ... 1 more Exception running application test.TestFX B_ I have tried javafx version down to javafx 11 and the error always occurs at some point. I would consider this a very critical error. The workaround seems to just set the opacity to 0 instead of hide(), but still I expect this code to run until the end.. Venlig hilsen / best regards Troels Skytte Kaspersen Software Developer ASPECT4 Development EG A/S ? Finsensvej 3 ? 7430 Ikast T: +45 7013 2211 ? D: +45 7260 2235 F: +45 7013 2299 ? M: +45 2085 9209 E-mail: trkas at eg.dk ? web: www.eg.dk Read our Privacy Policy From kcr at openjdk.java.net Thu Sep 2 23:47:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Sep 2021 23:47:33 GMT Subject: RFR: 8270107: Open source FXMediaPlayer test app In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds during development. > - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. Looks good. Tested on all three platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/613 From hjohn at xs4all.nl Fri Sep 3 02:35:37 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 3 Sep 2021 04:35:37 +0200 Subject: Eager Evaluation of Invalidation Listeners In-Reply-To: References: <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl> Message-ID: On 02/09/2021 11:57, Nir Lisker wrote: > So in order > to make sure that a new interested invalidation listener does not miss > the fact that a property was *already* invalid, the easiest solution > might have been to revalidate it upon registration of a new listener > > > But why does an invalidation listener need to know the past state of the > property? It is only interested in the valid -> invalid transition. If > the property was invalid then the listener (in theory) shouldn't receive > any events anyway on subsequent invalidations. (I understand that you > don't justify this, I'm posing it as a general question.) Strictly speaking, no, if users are using InvalidationListener correctly then this is definitely correct behavior. I'm not really advocating a change, and I'd even prefer that it be brought in line with the documentation. I think however that many users are not using it correctly and expect an invalidation event always the next time the value changes (and their listener will read that value, validating it again), making it act like a light-weight ChangeListener. I know that I probably have written code that made that assumption, and would in the past not even think twice about replacing a change with an invalidation listener or vice versa if that happened to be a better fit. Which is sort of what happened as well in the bidirectional binding PR, and the issue slipped past the author and two reviewers. > I suggest that we split the problem into 2: one is the case where the > property was valid when the listener was attached, and the other is when > it was invalid. > * A valid starting state. In this case attaching a listener shouldn't > need to do anything. A subsequent invalidation event will be sent > regardless. Currently, it is calling get() redundantly. True, the call to get is redundant in this case. Ugly too, calling get and discarding its result, while the intention is to force the property to become valid. > * An invalid starting state. In this case the documentation says that > nothing needs to happen, but get() is called anyway. Here, the > difference is that a subsequent invalidation event is sent in one case > and not in the other. The only way to advance here is to make a design > decision on what should happen, at least that's how I see it. The docs are even more specific I think, they say no more events will be generated until it becomes valid -- it doesn't leave any option open that it could generate events if it wanted to. > As to the implementation of a possible solution, suppose we add the > isValid method. Upon attaching an invalidation listener, if the property > is valid, we can skip the get() call. That solves the valid starting > state issue. The question is what to do if the property is not valid. > > I also noticed an odd design choice in the implementation of properties: > the value field does not update if the property is bound, instead, the > result of the binding is returned and the value field holds an outdated > value (until the property is unbound). Yeah, that might not be a wise decision as that can lead to memory being referenced that users might expect to be freed. I didn't see anywhere defined what will happen to the value of the property when it is unbound again. The current implementation will keep its last value (during the unbind it will take the last value and assign it to its own value field), so the value field should perhaps be nulled out when bound. --John From nlisker at gmail.com Fri Sep 3 04:49:14 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 3 Sep 2021 07:49:14 +0300 Subject: Eager Evaluation of Invalidation Listeners In-Reply-To: References: <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl> Message-ID: > > so the value field should perhaps be nulled out when bound. There was a PR for something like that in the old repo: https://github.com/javafxports/openjdk-jfx/pull/110 On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx wrote: > > > On 02/09/2021 11:57, Nir Lisker wrote: > > So in order > > to make sure that a new interested invalidation listener does not > miss > > the fact that a property was *already* invalid, the easiest solution > > might have been to revalidate it upon registration of a new listener > > > > > > But why does an invalidation listener need to know the past state of the > > property? It is only interested in the valid -> invalid transition. If > > the property was invalid then the listener (in theory) shouldn't receive > > any events anyway on subsequent invalidations. (I understand that you > > don't justify this, I'm posing it as a general question.) > > Strictly speaking, no, if users are using InvalidationListener correctly > then this is definitely correct behavior. I'm not really advocating a > change, and I'd even prefer that it be brought in line with the > documentation. > > I think however that many users are not using it correctly and expect an > invalidation event always the next time the value changes (and their > listener will read that value, validating it again), making it act like > a light-weight ChangeListener. I know that I probably have written code > that made that assumption, and would in the past not even think twice > about replacing a change with an invalidation listener or vice versa if > that happened to be a better fit. Which is sort of what happened as well > in the bidirectional binding PR, and the issue slipped past the author > and two reviewers. > > > I suggest that we split the problem into 2: one is the case where the > > property was valid when the listener was attached, and the other is when > > it was invalid. > > * A valid starting state. In this case attaching a listener shouldn't > > need to do anything. A subsequent invalidation event will be sent > > regardless. Currently, it is calling get() redundantly. > > True, the call to get is redundant in this case. Ugly too, calling get > and discarding its result, while the intention is to force the property > to become valid. > > > * An invalid starting state. In this case the documentation says that > > nothing needs to happen, but get() is called anyway. Here, the > > difference is that a subsequent invalidation event is sent in one case > > and not in the other. The only way to advance here is to make a design > > decision on what should happen, at least that's how I see it. > > The docs are even more specific I think, they say no more events will be > generated until it becomes valid -- it doesn't leave any option open > that it could generate events if it wanted to. > > > As to the implementation of a possible solution, suppose we add the > > isValid method. Upon attaching an invalidation listener, if the property > > is valid, we can skip the get() call. That solves the valid starting > > state issue. The question is what to do if the property is not valid. > > > > I also noticed an odd design choice in the implementation of properties: > > the value field does not update if the property is bound, instead, the > > result of the binding is returned and the value field holds an outdated > > value (until the property is unbound). > > Yeah, that might not be a wise decision as that can lead to memory being > referenced that users might expect to be freed. I didn't see anywhere > defined what will happen to the value of the property when it is unbound > again. The current implementation will keep its last value (during the > unbind it will take the last value and assign it to its own value > field), so the value field should perhaps be nulled out when bound. > > --John > From dev.infeo at mailbox.org Fri Sep 3 09:27:14 2021 From: dev.infeo at mailbox.org (dev.infeo at mailbox.org) Date: Fri, 3 Sep 2021 11:27:14 +0200 (CEST) Subject: Usage of Stream::peek in Project Message-ID: <974310702.80319.1630661234811@office.mailbox.org> Hey all, recently I stumbled over the problem of non-executing stream operations, especially `Stream.peek(Consumer action)`, for more Info see [1]. With JDK 17 this behaviour is even extended (e.g. skip() preserves the SIZED attribute of a stream, making optimizations possible). Out of curiosity I searched the sources at HEAD of peek(...) usages and found two problematic classes: * javafx.scene.control.MultipleSelectionModelBase: Line 745 * javafx.scene.control.ControlsUtil: Line 165 & 171 Especially the statement around line 171 in ControlsUtil is a candidate which might be "optimized" to not execute the peek(...) at all, while the inline comment states the call to peek is crucial. I don't know what the roadmap says about updating to JDK17, but it might already be a problem and I wantend to raise attention to this. Best Regards, Armin [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/package-summary.html#SideEffects From arapte at openjdk.java.net Fri Sep 3 09:59:38 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 3 Sep 2021 09:59:38 GMT Subject: RFR: 8273071: SeparatorSkin: must remove child on dispose In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 12:45:02 GMT, Jeanette Winzenburg wrote: > minor skin cleanup issue: SeparatorSkin didn't remove the line it added to the control's children > > fix is to override dispose and include the removal > for testing: removed the exclusion of SeparatorSkin from memoryLeakTest - doing so lets it fail/pass before/after this fix looks good to me. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/616 From fastegal at openjdk.java.net Fri Sep 3 10:10:35 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 3 Sep 2021 10:10:35 GMT Subject: Integrated: 8273071: SeparatorSkin: must remove child on dispose In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 12:45:02 GMT, Jeanette Winzenburg wrote: > minor skin cleanup issue: SeparatorSkin didn't remove the line it added to the control's children > > fix is to override dispose and include the removal > for testing: removed the exclusion of SeparatorSkin from memoryLeakTest - doing so lets it fail/pass before/after this fix This pull request has now been integrated. Changeset: 2267b115 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/2267b115f907e7c9c447691569e48cf0b2b95029 Stats: 14 lines in 2 files changed: 7 ins; 7 del; 0 mod 8273071: SeparatorSkin: must remove child on dispose Reviewed-by: arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/616 From mhanl at openjdk.java.net Fri Sep 3 10:31:33 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 3 Sep 2021 10:31:33 GMT Subject: RFR: 8269871: CellEditEvent: must not throw NPE in accessors In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 14:09:58 GMT, Jeanette Winzenburg wrote: > The issue is unguarded access to tablePosition though it might be null (since [JDK-8120610](https://bugs.openjdk.java.net/browse/JDK-8120610) > > The fix is to check against null in each accessor. Also required to fix the default onEditCommit handlers in Tree/TableColumn to really cope with null TablePostion on the event. > > Added tests that failed/pass before/after the fix. > > Note that there was an old test (in Tree/TableColumnTest each), that failed after the fix because it expected the NPE. Fixed by removing the expected parameter. Looks good to me. Good to see this fixed, I remember I had some NPEs in the past because of a null table position. ?? ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/611 From mhanl at openjdk.java.net Fri Sep 3 13:26:34 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 3 Sep 2021 13:26:34 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: Message-ID: <4jwwsPx1DVeTlLIsTSke_SZlMdkzdHEZgWyYz4iaQHg=.e809373a-94dd-4274-888f-0d7b7cf84e3a@github.com> On Fri, 27 Aug 2021 17:40:48 GMT, Nir Lisker wrote: >> Added convenience factory factory methods for Background and Border. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Corrected comment tags modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 366: > 364: */ > 365: public static Background fill(Paint fill) { > 366: return new Background(new BackgroundFill(fill, null, null)); null **CornerRaddii** and null **Insets** will use **CornerRadii.EMPTY** and **Insets.EMPTY**. Maybe we should use those here instead so it's more clear for anyone having a look in the source code? I also always use those instead of null. Same for **BorderStroke** ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From hjohn at xs4all.nl Fri Sep 3 13:39:12 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 3 Sep 2021 15:39:12 +0200 Subject: Critical error when showing and hiding stage or popup In-Reply-To: References: Message-ID: <282cf09e-4899-4b1d-1e19-d4827400bdf1@xs4all.nl> This ran for me until 15058 iterations, then the whole system froze for a few seconds and the program threw an exception (without a stacktrace). Windows 10, javafx.runtime.version: 16+8 This looks like some native resource getting exhausted (especially since the whole system froze for a moment when the application failed). I did a heapdump afterwards, but didn't see any Popup instances left. Looking at the code, it basically errors on a native call to create a window. Checking a bit further, it does call the native _close to close these windows. Couldn't debug much further from there. --John On 02/09/2021 20:07, Troels Skytte Kaspersen wrote: > Hi, > > We have received many complaints from our customers that the popups are not shown anymore after a period of time. > > I have then created a simple piece of code that result in the error our customers get: > > package test; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.layout.StackPane; > import javafx.stage.Popup; > import javafx.stage.Stage; > > public class TestFX extends Application { > > @Override > public void start(Stage primaryStage) { > System.out.println("javafx.runtime.version: " + System.getProperties().get("javafx.runtime.version")); > Stage stage = new Stage(); > Scene scene = new Scene(new StackPane()); > stage.setScene(scene); > stage.show(); > Popup popOver = new Popup(); > for (int i = 0; i < 99999; i++) { > popOver.show(scene.getRoot(), 1, 1); > popOver.hide(); > System.out.println(i); > } > } > > public static void main(String[] args) { > launch(args); > } > } > > I use javafx 16+8 > > If I run the code, it will result in error after various iterations: > > Exception in Application start method > Exception in thread "JavaFX Application Thread" java.lang.NullPointerException > at javafx.base/com.sun.javafx.binding.ExpressionHelper.removeListener(ExpressionHelper.java:73) > at javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.removeListener(ReadOnlyBooleanPropertyBase.java:67) > at javafx.graphics/javafx.stage.PopupWindow.unbindOwnerFocusedProperty(PopupWindow.java:895) > at javafx.graphics/javafx.stage.PopupWindow.doVisibleChanged(PopupWindow.java:542) > at javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanged(PopupWindow.java:111) > at javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangedImpl(PopupWindowHelper.java:63) > at javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanged(WindowHelper.java:77) > at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1160) > at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) > at javafx.graphics/javafx.stage.Window.hide(Window.java:1212) > at javafx.graphics/javafx.stage.PopupWindow.hide(PopupWindow.java:486) > at javafx.graphics/javafx.stage.PopupWindow.lambda$new$0(PopupWindow.java:147) > at javafx.base/javafx.beans.value.WeakChangeListener.changed(WeakChangeListener.java:86) > at javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181) > at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) > at javafx.graphics/javafx.scene.Node$TreeShowingPropertyReadOnly.invalidate(Node.java:8479) > at javafx.graphics/javafx.scene.Node.setTreeShowing(Node.java:8436) > at javafx.graphics/javafx.scene.Node.updateTreeShowing(Node.java:8427) > at javafx.graphics/javafx.scene.Node.lambda$new$2(Node.java:1010) > at javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) > at javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) > at javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.fireValueChangedEvent(ReadOnlyBooleanPropertyBase.java:78) > at javafx.base/javafx.beans.property.ReadOnlyBooleanWrapper.fireValueChangedEvent(ReadOnlyBooleanWrapper.java:103) > at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:111) > at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) > at javafx.graphics/javafx.stage.Window.hide(Window.java:1212) > at javafx.graphics/com.sun.javafx.stage.WindowPeerListener.closed(WindowPeerListener.java:105) > at javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:144) > at javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:40) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) > at javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.lambda$handleWindowEvent$4(GlassWindowEventHandler.java:176) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:412) > at javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.handleWindowEvent(GlassWindowEventHandler.java:174) > at javafx.graphics/com.sun.glass.ui.Window.handleWindowEvent(Window.java:1336) > at javafx.graphics/com.sun.glass.ui.Window.notifyDestroy(Window.java:1250) > at javafx.graphics/com.sun.glass.ui.win.WinWindow._close(Native Method) > at javafx.graphics/com.sun.glass.ui.Window.close(Window.java:352) > at javafx.graphics/com.sun.glass.ui.win.WinWindow.close(WinWindow.java:316) > at javafx.graphics/com.sun.glass.ui.Application.terminate(Application.java:394) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$exit$13(QuantumToolkit.java:831) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:827) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:614) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) > at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > at java.base/java.lang.Thread.run(Thread.java:831) > java.lang.reflect.InvocationTargetException > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:464) > at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1071) > Caused by: java.lang.RuntimeException: Exception in Application start method > at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:900) > at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) > at java.base/java.lang.Thread.run(Thread.java:831) > Caused by: java.lang.RuntimeException: could not create platform window > at javafx.graphics/com.sun.glass.ui.Window.(Window.java:294) > at javafx.graphics/com.sun.glass.ui.win.WinWindow.(WinWindow.java:54) > at javafx.graphics/com.sun.glass.ui.win.WinApplication.createWindow(WinApplication.java:219) > at javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.initPlatformWindow(WindowStage.java:201) > at javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.init(WindowStage.java:143) > at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.createTKPopupStage(QuantumToolkit.java:678) > at javafx.graphics/javafx.stage.PopupWindow.doVisibleChanging(PopupWindow.java:514) > at javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanging(PopupWindow.java:107) > at javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangingImpl(PopupWindowHelper.java:57) > at javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanging(WindowHelper.java:73) > at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1065) > at javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > at javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) > at javafx.graphics/javafx.stage.Window.show(Window.java:1202) > at javafx.graphics/javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > at javafx.graphics/javafx.stage.PopupWindow.show(PopupWindow.java:417) > at test.TestFX.start(TestFX.java:35) > at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:391) > at javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) > at javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > ... 1 more > Exception running application test.TestFX > B_ > > I have tried javafx version down to javafx 11 and the error always occurs at some point. > > I would consider this a very critical error. The workaround seems to just set the opacity to 0 instead of hide(), but still I expect this code to run until the end.. > > Venlig hilsen / best regards > > Troels Skytte Kaspersen > Software Developer > ASPECT4 Development > > EG A/S ? Finsensvej 3 ? 7430 Ikast > T: +45 7013 2211 ? D: +45 7260 2235 > F: +45 7013 2299 ? M: +45 2085 9209 > E-mail: trkas at eg.dk ? web: www.eg.dk > Read our Privacy Policy > From nlisker at gmail.com Fri Sep 3 13:50:31 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 3 Sep 2021 16:50:31 +0300 Subject: Critical error when showing and hiding stage or popup In-Reply-To: References: Message-ID: I would submit it to bugreport.java.com. On Thu, Sep 2, 2021 at 9:08 PM Troels Skytte Kaspersen wrote: > Hi, > > We have received many complaints from our customers that the popups are > not shown anymore after a period of time. > > I have then created a simple piece of code that result in the error our > customers get: > > package test; > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.layout.StackPane; > import javafx.stage.Popup; > import javafx.stage.Stage; > > public class TestFX extends Application { > > @Override > public void start(Stage primaryStage) { > System.out.println("javafx.runtime.version: " + > System.getProperties().get("javafx.runtime.version")); > Stage stage = new Stage(); > Scene scene = new Scene(new StackPane()); > stage.setScene(scene); > stage.show(); > Popup popOver = new Popup(); > for (int i = 0; i < 99999; i++) { > popOver.show(scene.getRoot(), 1, 1); > popOver.hide(); > System.out.println(i); > } > } > > public static void main(String[] args) { > launch(args); > } > } > > I use javafx 16+8 > > If I run the code, it will result in error after various iterations: > > Exception in Application start method > Exception in thread "JavaFX Application Thread" > java.lang.NullPointerException > at > javafx.base/com.sun.javafx.binding.ExpressionHelper.removeListener(ExpressionHelper.java:73) > at > javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.removeListener(ReadOnlyBooleanPropertyBase.java:67) > at > javafx.graphics/javafx.stage.PopupWindow.unbindOwnerFocusedProperty(PopupWindow.java:895) > at > javafx.graphics/javafx.stage.PopupWindow.doVisibleChanged(PopupWindow.java:542) > at > javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanged(PopupWindow.java:111) > at > javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangedImpl(PopupWindowHelper.java:63) > at > javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanged(WindowHelper.java:77) > at > javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1160) > at > javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > at > javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > at > javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) > at javafx.graphics/javafx.stage.Window.hide(Window.java:1212) > at > javafx.graphics/javafx.stage.PopupWindow.hide(PopupWindow.java:486) > at > javafx.graphics/javafx.stage.PopupWindow.lambda$new$0(PopupWindow.java:147) > at > javafx.base/javafx.beans.value.WeakChangeListener.changed(WeakChangeListener.java:86) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) > at > javafx.graphics/javafx.scene.Node$TreeShowingPropertyReadOnly.invalidate(Node.java:8479) > at > javafx.graphics/javafx.scene.Node.setTreeShowing(Node.java:8436) > at > javafx.graphics/javafx.scene.Node.updateTreeShowing(Node.java:8427) > at > javafx.graphics/javafx.scene.Node.lambda$new$2(Node.java:1010) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) > at > javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) > at > javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.fireValueChangedEvent(ReadOnlyBooleanPropertyBase.java:78) > at > javafx.base/javafx.beans.property.ReadOnlyBooleanWrapper.fireValueChangedEvent(ReadOnlyBooleanWrapper.java:103) > at > javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:111) > at > javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > at > javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) > at javafx.graphics/javafx.stage.Window.hide(Window.java:1212) > at > javafx.graphics/com.sun.javafx.stage.WindowPeerListener.closed(WindowPeerListener.java:105) > at > javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:144) > at > javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:40) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:391) > at > javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.lambda$handleWindowEvent$4(GlassWindowEventHandler.java:176) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:412) > at > javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.handleWindowEvent(GlassWindowEventHandler.java:174) > at > javafx.graphics/com.sun.glass.ui.Window.handleWindowEvent(Window.java:1336) > at > javafx.graphics/com.sun.glass.ui.Window.notifyDestroy(Window.java:1250) > at > javafx.graphics/com.sun.glass.ui.win.WinWindow._close(Native Method) > at > javafx.graphics/com.sun.glass.ui.Window.close(Window.java:352) > at > javafx.graphics/com.sun.glass.ui.win.WinWindow.close(WinWindow.java:316) > at > javafx.graphics/com.sun.glass.ui.Application.terminate(Application.java:394) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$exit$13(QuantumToolkit.java:831) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:827) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:614) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:391) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) > at > javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > at > javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > at java.base/java.lang.Thread.run(Thread.java:831) > java.lang.reflect.InvocationTargetException > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:464) > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at > java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1071) > Caused by: java.lang.RuntimeException: Exception in Application start > method > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:900) > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) > at java.base/java.lang.Thread.run(Thread.java:831) > Caused by: java.lang.RuntimeException: could not create platform window > at > javafx.graphics/com.sun.glass.ui.Window.(Window.java:294) > at > javafx.graphics/com.sun.glass.ui.win.WinWindow.(WinWindow.java:54) > at > javafx.graphics/com.sun.glass.ui.win.WinApplication.createWindow(WinApplication.java:219) > at > javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.initPlatformWindow(WindowStage.java:201) > at > javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.init(WindowStage.java:143) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.createTKPopupStage(QuantumToolkit.java:678) > at > javafx.graphics/javafx.stage.PopupWindow.doVisibleChanging(PopupWindow.java:514) > at > javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanging(PopupWindow.java:107) > at > javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangingImpl(PopupWindowHelper.java:57) > at > javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanging(WindowHelper.java:73) > at > javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1065) > at > javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > at > javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > at > javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) > at javafx.graphics/javafx.stage.Window.show(Window.java:1202) > at > javafx.graphics/javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > at > javafx.graphics/javafx.stage.PopupWindow.show(PopupWindow.java:417) > at test.TestFX.start(TestFX.java:35) > at > javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:391) > at > javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) > at > javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > at > javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > ... 1 more > Exception running application test.TestFX > B_ > > I have tried javafx version down to javafx 11 and the error always occurs > at some point. > > I would consider this a very critical error. The workaround seems to just > set the opacity to 0 instead of hide(), but still I expect this code to run > until the end.. > > Venlig hilsen / best regards > > Troels Skytte Kaspersen > Software Developer > ASPECT4 Development > > EG A/S ? Finsensvej 3 ? 7430 Ikast > T: +45 7013 2211 ? D: +45 7260 2235 > F: +45 7013 2299 ? M: +45 2085 9209 > E-mail: trkas at eg.dk ? web: www.eg.dk > Read our Privacy Policy > From perini.davide at dpsoftware.org Fri Sep 3 14:06:48 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 3 Sep 2021 16:06:48 +0200 Subject: Get how many monitors are connected. Message-ID: <9618ecf6-afcf-bad2-83f3-cb001340947c@dpsoftware.org> Hi, I'm using this to get how many monitors is connected to the PC: for (Screen screen : Screen.getScreens()) { } Is there a way to know what is the first, second and third monitor? Using Windows and I would like to see what is the first monitor set in windows, what's the second and so on. Is this possible using JavaFX? Thanks Davide From kevin.rushforth at oracle.com Fri Sep 3 14:34:01 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Sep 2021 07:34:01 -0700 Subject: Critical error when showing and hiding stage or popup In-Reply-To: References: Message-ID: <87f8f8c8-dc57-ce7a-f47e-198e63faf181@oracle.com> I missed seeing the message yesterday. He did file a bug at bugreport.java.com, which ended up here: https://bugs.openjdk.java.net/browse/JDK-8273319 I just evaluated it, and closed it as "not an issue". As I wrote in the bug report: --------------------------------------------- "The test application is starving the event queue by running the show / hide in a tight loop on the JavaFX Application Thread. This means that no other operations, such as event processing, repainting the screen, or processing any queued messages, can occur. When a window is closed, we queue up an message to unregister the Window class to ensure that the class is no longer referenced before unregistering it (else it will fail). Since it is given no opportunity to run, we will leak and eventually run out of Windows class objects. A modified test program that uses Platform.runLater to avoid starving the event queue does not encounter this problem. I ran it for about 200,000 iterations of the loop with no problems, and verified that the Regisgter / Unregister Class methods are correctly balanced. There *might* be something we could do to workaround this, but this is the result of a poorly behaved application test program. Instead, the application should be rewritten to not run code like this in a tight loop on the JavaFX Application Thread. I can't imagine the case where a real application would need to do what this stress test is doing." --------------------------------------------- Do you have a non-pathological test case (meaning one where you don't show/hide in a loop) that shows this leak? If so, I can reopen the bug and we'll take a look. -- Kevin On 9/3/2021 6:50 AM, Nir Lisker wrote: > I would submit it to bugreport.java.com. > > On Thu, Sep 2, 2021 at 9:08 PM Troels Skytte Kaspersen wrote: > >> Hi, >> >> We have received many complaints from our customers that the popups are >> not shown anymore after a period of time. >> >> I have then created a simple piece of code that result in the error our >> customers get: >> >> package test; >> >> import javafx.application.Application; >> import javafx.scene.Scene; >> import javafx.scene.layout.StackPane; >> import javafx.stage.Popup; >> import javafx.stage.Stage; >> >> public class TestFX extends Application { >> >> @Override >> public void start(Stage primaryStage) { >> System.out.println("javafx.runtime.version: " + >> System.getProperties().get("javafx.runtime.version")); >> Stage stage = new Stage(); >> Scene scene = new Scene(new StackPane()); >> stage.setScene(scene); >> stage.show(); >> Popup popOver = new Popup(); >> for (int i = 0; i < 99999; i++) { >> popOver.show(scene.getRoot(), 1, 1); >> popOver.hide(); >> System.out.println(i); >> } >> } >> >> public static void main(String[] args) { >> launch(args); >> } >> } >> >> I use javafx 16+8 >> >> If I run the code, it will result in error after various iterations: >> >> Exception in Application start method >> Exception in thread "JavaFX Application Thread" >> java.lang.NullPointerException >> at >> javafx.base/com.sun.javafx.binding.ExpressionHelper.removeListener(ExpressionHelper.java:73) >> at >> javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.removeListener(ReadOnlyBooleanPropertyBase.java:67) >> at >> javafx.graphics/javafx.stage.PopupWindow.unbindOwnerFocusedProperty(PopupWindow.java:895) >> at >> javafx.graphics/javafx.stage.PopupWindow.doVisibleChanged(PopupWindow.java:542) >> at >> javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanged(PopupWindow.java:111) >> at >> javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangedImpl(PopupWindowHelper.java:63) >> at >> javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanged(WindowHelper.java:77) >> at >> javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1160) >> at >> javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) >> at >> javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >> at >> javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) >> at javafx.graphics/javafx.stage.Window.hide(Window.java:1212) >> at >> javafx.graphics/javafx.stage.PopupWindow.hide(PopupWindow.java:486) >> at >> javafx.graphics/javafx.stage.PopupWindow.lambda$new$0(PopupWindow.java:147) >> at >> javafx.base/javafx.beans.value.WeakChangeListener.changed(WeakChangeListener.java:86) >> at >> javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181) >> at >> javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) >> at >> javafx.graphics/javafx.scene.Node$TreeShowingPropertyReadOnly.invalidate(Node.java:8479) >> at >> javafx.graphics/javafx.scene.Node.setTreeShowing(Node.java:8436) >> at >> javafx.graphics/javafx.scene.Node.updateTreeShowing(Node.java:8427) >> at >> javafx.graphics/javafx.scene.Node.lambda$new$2(Node.java:1010) >> at >> javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) >> at >> javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) >> at >> javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.fireValueChangedEvent(ReadOnlyBooleanPropertyBase.java:78) >> at >> javafx.base/javafx.beans.property.ReadOnlyBooleanWrapper.fireValueChangedEvent(ReadOnlyBooleanWrapper.java:103) >> at >> javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:111) >> at >> javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >> at >> javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) >> at javafx.graphics/javafx.stage.Window.hide(Window.java:1212) >> at >> javafx.graphics/com.sun.javafx.stage.WindowPeerListener.closed(WindowPeerListener.java:105) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:144) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:40) >> at >> java.base/java.security.AccessController.doPrivileged(AccessController.java:391) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.lambda$handleWindowEvent$4(GlassWindowEventHandler.java:176) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:412) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.handleWindowEvent(GlassWindowEventHandler.java:174) >> at >> javafx.graphics/com.sun.glass.ui.Window.handleWindowEvent(Window.java:1336) >> at >> javafx.graphics/com.sun.glass.ui.Window.notifyDestroy(Window.java:1250) >> at >> javafx.graphics/com.sun.glass.ui.win.WinWindow._close(Native Method) >> at >> javafx.graphics/com.sun.glass.ui.Window.close(Window.java:352) >> at >> javafx.graphics/com.sun.glass.ui.win.WinWindow.close(WinWindow.java:316) >> at >> javafx.graphics/com.sun.glass.ui.Application.terminate(Application.java:394) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$exit$13(QuantumToolkit.java:831) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:827) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:614) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) >> at >> java.base/java.security.AccessController.doPrivileged(AccessController.java:391) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) >> at >> javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> at >> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) >> at >> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) >> at java.base/java.lang.Thread.run(Thread.java:831) >> java.lang.reflect.InvocationTargetException >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:464) >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> at >> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1071) >> Caused by: java.lang.RuntimeException: Exception in Application start >> method >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:900) >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) >> at java.base/java.lang.Thread.run(Thread.java:831) >> Caused by: java.lang.RuntimeException: could not create platform window >> at >> javafx.graphics/com.sun.glass.ui.Window.(Window.java:294) >> at >> javafx.graphics/com.sun.glass.ui.win.WinWindow.(WinWindow.java:54) >> at >> javafx.graphics/com.sun.glass.ui.win.WinApplication.createWindow(WinApplication.java:219) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.initPlatformWindow(WindowStage.java:201) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.init(WindowStage.java:143) >> at >> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.createTKPopupStage(QuantumToolkit.java:678) >> at >> javafx.graphics/javafx.stage.PopupWindow.doVisibleChanging(PopupWindow.java:514) >> at >> javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanging(PopupWindow.java:107) >> at >> javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangingImpl(PopupWindowHelper.java:57) >> at >> javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanging(WindowHelper.java:73) >> at >> javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1065) >> at >> javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) >> at >> javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >> at >> javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) >> at javafx.graphics/javafx.stage.Window.show(Window.java:1202) >> at >> javafx.graphics/javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) >> at >> javafx.graphics/javafx.stage.PopupWindow.show(PopupWindow.java:417) >> at test.TestFX.start(TestFX.java:35) >> at >> javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) >> at >> java.base/java.security.AccessController.doPrivileged(AccessController.java:391) >> at >> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) >> at >> javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> at >> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method) >> at >> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) >> ... 1 more >> Exception running application test.TestFX >> B_ >> >> I have tried javafx version down to javafx 11 and the error always occurs >> at some point. >> >> I would consider this a very critical error. The workaround seems to just >> set the opacity to 0 instead of hide(), but still I expect this code to run >> until the end.. >> >> Venlig hilsen / best regards >> >> Troels Skytte Kaspersen >> Software Developer >> ASPECT4 Development >> >> EG A/S ? Finsensvej 3 ? 7430 Ikast >> T: +45 7013 2211 ? D: +45 7260 2235 >> F: +45 7013 2299 ? M: +45 2085 9209 >> E-mail: trkas at eg.dk ? web: www.eg.dk >> Read our Privacy Policy >> From kevin.rushforth at oracle.com Fri Sep 3 14:39:06 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Sep 2021 07:39:06 -0700 Subject: Get how many monitors are connected. In-Reply-To: <9618ecf6-afcf-bad2-83f3-cb001340947c@dpsoftware.org> References: <9618ecf6-afcf-bad2-83f3-cb001340947c@dpsoftware.org> Message-ID: <741ea953-64c1-6af8-bc41-8c06fe8891ad@oracle.com> I don't think so. You can find out the primary monitor with Screen.getPrimary(), and you can determine the positioning of all screens relative to each other using the visual bounds of each screen. There isn't any guarantee, though, that the list of screens is ordered, so if there are more than 2 screens, I don't know of a reliable way to distinguish the second, third, and so on. -- Kevin On 9/3/2021 7:06 AM, Davide Perini wrote: > Hi, > I'm using this to get how many monitors is connected to the PC: > > for (Screen screen : Screen.getScreens()) { > > > } > > > Is there a way to know what is the first, second and third monitor? > Using Windows and I would like to see what is the first monitor set in > windows, what's the second and so on. > > Is this possible using JavaFX? > > Thanks > Davide > From perini.davide at dpsoftware.org Fri Sep 3 14:58:44 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 3 Sep 2021 16:58:44 +0200 Subject: Get how many monitors are connected. In-Reply-To: <741ea953-64c1-6af8-bc41-8c06fe8891ad@oracle.com> References: <9618ecf6-afcf-bad2-83f3-cb001340947c@dpsoftware.org> <741ea953-64c1-6af8-bc41-8c06fe8891ad@oracle.com> Message-ID: mmm... I confirm that it isn't really reliable. I have noticed the Screen.getScreens() have primary screen as the first element, but other screens are just in a non correct order. Hope that JavaFX will find a way to overcome this problem. Thank you Davide Il 03/09/2021 16:39, Kevin Rushforth ha scritto: > I don't think so. You can find out the primary monitor with > Screen.getPrimary(), and you can determine the positioning of all > screens relative to each other using the visual bounds of each screen. > There isn't any guarantee, though, that the list of screens is > ordered, so if there are more than 2 screens, I don't know of a > reliable way to distinguish the second, third, and so on. > > -- Kevin > > > On 9/3/2021 7:06 AM, Davide Perini wrote: >> Hi, >> I'm using this to get how many monitors is connected to the PC: >> >> for (Screen screen : Screen.getScreens()) { >> >> >> } >> >> >> Is there a way to know what is the first, second and third monitor? >> Using Windows and I would like to see what is the first monitor set >> in windows, what's the second and so on. >> >> Is this possible using JavaFX? >> >> Thanks >> Davide >> > From kevin.rushforth at oracle.com Fri Sep 3 15:09:01 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Sep 2021 08:09:01 -0700 Subject: Critical error when showing and hiding stage or popup In-Reply-To: <87f8f8c8-dc57-ce7a-f47e-198e63faf181@oracle.com> References: <87f8f8c8-dc57-ce7a-f47e-198e63faf181@oracle.com> Message-ID: <5b2fc07a-747d-f235-cd63-ac08c6c0bfa3@oracle.com> FWIW, here is the modified code that will run indefinitely (note that there is an extra "9" in the loop count...I got tired of watching it after about 200,000 times): ??????? Thread t = new Thread(() -> { ?? ?????? for (int i = 0; i < 999999; i++) { ? ?? ???????? final int _i = i; ??? ?? ?????? Platform.runLater(() -> { ? ?? ?? ?? ???? popOver.show(scene.getRoot(), 1, 1); ??? ?? ?? ?? ?? popOver.hide(); ????? ?? ?? ? ? System.out.println(_i); ????????????? }); ?? ?????? } ??????? }); ??????? t.start(); And while that code is very artificial, too, it shows that we are not leaking Windows class objects in general. -- Kevin On 9/3/2021 7:34 AM, Kevin Rushforth wrote: > I missed seeing the message yesterday. He did file a bug at > bugreport.java.com, which ended up here: > > https://bugs.openjdk.java.net/browse/JDK-8273319 > > I just evaluated it, and closed it as "not an issue". As I wrote in > the bug report: > > --------------------------------------------- > "The test application is starving the event queue by running the show > / hide in a tight loop on the JavaFX Application Thread. This means > that no other operations, such as event processing, repainting the > screen, or processing any queued messages, can occur. When a window is > closed, we queue up an message to unregister the Window class to > ensure that the class is no longer referenced before unregistering it > (else it will fail). Since it is given no opportunity to run, we will > leak and eventually run out of Windows class objects. > > A modified test program that uses Platform.runLater to avoid starving > the event queue does not encounter this problem. I ran it for about > 200,000 iterations of the loop with no problems, and verified that the > Regisgter / Unregister Class methods are correctly balanced. > > There *might* be something we could do to workaround this, but this is > the result of a poorly behaved application test program. Instead, the > application should be rewritten to not run code like this in a tight > loop on the JavaFX Application Thread. I can't imagine the case where > a real application would need to do what this stress test is doing." > --------------------------------------------- > > Do you have a non-pathological test case (meaning one where you don't > show/hide in a loop) that shows this leak? If so, I can reopen the bug > and we'll take a look. > > -- Kevin > > > On 9/3/2021 6:50 AM, Nir Lisker wrote: >> I would submit it to bugreport.java.com. >> >> On Thu, Sep 2, 2021 at 9:08 PM Troels Skytte Kaspersen >> wrote: >> >>> Hi, >>> >>> We have received many complaints from our customers that the popups are >>> not shown anymore after a period of time. >>> >>> I have then created a simple piece of code that result in the error our >>> customers get: >>> >>> package test; >>> >>> import javafx.application.Application; >>> import javafx.scene.Scene; >>> import javafx.scene.layout.StackPane; >>> import javafx.stage.Popup; >>> import javafx.stage.Stage; >>> >>> public class TestFX extends Application { >>> >>> ???????????? @Override >>> ???????????? public void start(Stage primaryStage) { >>> System.out.println("javafx.runtime.version: " + >>> System.getProperties().get("javafx.runtime.version")); >>> ????????????????????????? Stage stage = new Stage(); >>> ????????????????????????? Scene scene = new Scene(new StackPane()); >>> ????????????????????????? stage.setScene(scene); >>> ????????????????????????? stage.show(); >>> ????????????????????????? Popup popOver = new Popup(); >>> ????????????????????????? for (int i = 0; i < 99999; i++) { >>> popOver.show(scene.getRoot(), 1, 1); >>> ????????????????????????????????????? popOver.hide(); >>> ????????????????????????????????????? System.out.println(i); >>> ????????????????????????? } >>> ???????????? } >>> >>> ???????????? public static void main(String[] args) { >>> ????????????????????????? launch(args); >>> ???????????? } >>> } >>> >>> I use javafx 16+8 >>> >>> If I run the code, it will result in error after various iterations: >>> >>> Exception in Application start method >>> Exception in thread "JavaFX Application Thread" >>> java.lang.NullPointerException >>> ???????????? at >>> javafx.base/com.sun.javafx.binding.ExpressionHelper.removeListener(ExpressionHelper.java:73) >>> >>> ???????????? at >>> javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.removeListener(ReadOnlyBooleanPropertyBase.java:67) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.PopupWindow.unbindOwnerFocusedProperty(PopupWindow.java:895) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.PopupWindow.doVisibleChanged(PopupWindow.java:542) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanged(PopupWindow.java:111) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangedImpl(PopupWindowHelper.java:63) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanged(WindowHelper.java:77) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1160) >>> ???????????? at >>> javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) >>> >>> ???????????? at >>> javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) >>> ???????????? at >>> javafx.graphics/javafx.stage.Window.hide(Window.java:1212) >>> ???????????? at >>> javafx.graphics/javafx.stage.PopupWindow.hide(PopupWindow.java:486) >>> ???????????? at >>> javafx.graphics/javafx.stage.PopupWindow.lambda$new$0(PopupWindow.java:147) >>> >>> ???????????? at >>> javafx.base/javafx.beans.value.WeakChangeListener.changed(WeakChangeListener.java:86) >>> >>> ???????????? at >>> javafx.base/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181) >>> >>> ???????????? at >>> javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) >>> >>> ???????????? at >>> javafx.graphics/javafx.scene.Node$TreeShowingPropertyReadOnly.invalidate(Node.java:8479) >>> >>> ???????????? at >>> javafx.graphics/javafx.scene.Node.setTreeShowing(Node.java:8436) >>> ???????????? at >>> javafx.graphics/javafx.scene.Node.updateTreeShowing(Node.java:8427) >>> ???????????? at >>> javafx.graphics/javafx.scene.Node.lambda$new$2(Node.java:1010) >>> ???????????? at >>> javafx.base/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(ExpressionHelper.java:360) >>> >>> ???????????? at >>> javafx.base/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:80) >>> >>> ???????????? at >>> javafx.base/javafx.beans.property.ReadOnlyBooleanPropertyBase.fireValueChangedEvent(ReadOnlyBooleanPropertyBase.java:78) >>> >>> ???????????? at >>> javafx.base/javafx.beans.property.ReadOnlyBooleanWrapper.fireValueChangedEvent(ReadOnlyBooleanWrapper.java:103) >>> >>> ???????????? at >>> javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:111) >>> >>> ???????????? at >>> javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) >>> ???????????? at >>> javafx.graphics/javafx.stage.Window.hide(Window.java:1212) >>> ???????????? at >>> javafx.graphics/com.sun.javafx.stage.WindowPeerListener.closed(WindowPeerListener.java:105) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:144) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.run(GlassWindowEventHandler.java:40) >>> >>> ???????????? at >>> java.base/java.security.AccessController.doPrivileged(AccessController.java:391) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.lambda$handleWindowEvent$4(GlassWindowEventHandler.java:176) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:412) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.GlassWindowEventHandler.handleWindowEvent(GlassWindowEventHandler.java:174) >>> >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.Window.handleWindowEvent(Window.java:1336) >>> >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.Window.notifyDestroy(Window.java:1250) >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.win.WinWindow._close(Native Method) >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.Window.close(Window.java:352) >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.win.WinWindow.close(WinWindow.java:316) >>> >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.Application.terminate(Application.java:394) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$exit$13(QuantumToolkit.java:831) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:827) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:614) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) >>> >>> ???????????? at >>> java.base/java.security.AccessController.doPrivileged(AccessController.java:391) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) >>> >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >>> >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native >>> Method) >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) >>> >>> ???????????? at java.base/java.lang.Thread.run(Thread.java:831) >>> java.lang.reflect.InvocationTargetException >>> ???????????? at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> ???????????? at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >>> >>> ???????????? at >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> ???????????? at >>> java.base/java.lang.reflect.Method.invoke(Method.java:567) >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplicationWithArgs(LauncherImpl.java:464) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication(LauncherImpl.java:363) >>> >>> ???????????? at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> ???????????? at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >>> >>> ???????????? at >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> ???????????? at >>> java.base/java.lang.reflect.Method.invoke(Method.java:567) >>> ???????????? at >>> java.base/sun.launcher.LauncherHelper$FXHelper.main(LauncherHelper.java:1071) >>> >>> Caused by: java.lang.RuntimeException: Exception in Application start >>> method >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:900) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195) >>> >>> ???????????? at java.base/java.lang.Thread.run(Thread.java:831) >>> Caused by: java.lang.RuntimeException: could not create platform window >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.Window.(Window.java:294) >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.win.WinWindow.(WinWindow.java:54) >>> >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.win.WinApplication.createWindow(WinApplication.java:219) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.initPlatformWindow(WindowStage.java:201) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.WindowStage.init(WindowStage.java:143) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.createTKPopupStage(QuantumToolkit.java:678) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.PopupWindow.doVisibleChanging(PopupWindow.java:514) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.PopupWindow$1.doVisibleChanging(PopupWindow.java:107) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.stage.PopupWindowHelper.visibleChangingImpl(PopupWindowHelper.java:57) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.stage.WindowHelper.visibleChanging(WindowHelper.java:73) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1065) >>> ???????????? at >>> javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) >>> >>> ???????????? at >>> javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) >>> >>> ???????????? at >>> javafx.graphics/javafx.stage.Window.setShowing(Window.java:1187) >>> ???????????? at >>> javafx.graphics/javafx.stage.Window.show(Window.java:1202) >>> ???????????? at >>> javafx.graphics/javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) >>> ???????????? at >>> javafx.graphics/javafx.stage.PopupWindow.show(PopupWindow.java:417) >>> ???????????? at test.TestFX.start(TestFX.java:35) >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:846) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:474) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:447) >>> >>> ???????????? at >>> java.base/java.security.AccessController.doPrivileged(AccessController.java:391) >>> >>> ???????????? at >>> javafx.graphics/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:446) >>> >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >>> >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native >>> Method) >>> ???????????? at >>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) >>> >>> ???????????? ... 1 more >>> Exception running application test.TestFX >>> B_ >>> >>> I have tried javafx version down to javafx 11 and the error always >>> occurs >>> at some point. >>> >>> I would consider this a very critical error. The workaround seems to >>> just >>> set the opacity to 0 instead of hide(), but still I expect this code >>> to run >>> until the end.. >>> >>> Venlig hilsen / best regards >>> >>> Troels Skytte Kaspersen >>> Software Developer >>> ASPECT4 Development >>> >>> EG A/S ? Finsensvej 3 ? 7430 Ikast >>> T: +45 7013 2211 ? D: +45 7260 2235 >>> F: +45 7013 2299 ? M: +45 2085 9209 >>> E-mail: trkas at eg.dk ? web: >>> www.eg.dk >>> Read our Privacy >>> Policy >>> > From aghaisas at openjdk.java.net Fri Sep 3 15:26:36 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 3 Sep 2021 15:26:36 GMT Subject: RFR: 8269871: CellEditEvent: must not throw NPE in accessors In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 14:09:58 GMT, Jeanette Winzenburg wrote: > The issue is unguarded access to tablePosition though it might be null (since [JDK-8120610](https://bugs.openjdk.java.net/browse/JDK-8120610) > > The fix is to check against null in each accessor. Also required to fix the default onEditCommit handlers in Tree/TableColumn to really cope with null TablePostion on the event. > > Added tests that failed/pass before/after the fix. > > Note that there was an old test (in Tree/TableColumnTest each), that failed after the fix because it expected the NPE. Fixed by removing the expected parameter. The fix looks good. Minor : Two comments from tests need to be removed. modules/javafx.controls/src/test/java/test/javafx/scene/control/CellEditEventOfTableColumnTest.java line 179: > 177: > 178: ObservableList model = FXCollections.observableArrayList("Four", "Five", "Fear"); > 179: // "Flop", "Food", "Fizz" Did you forget to remove this comment? modules/javafx.controls/src/test/java/test/javafx/scene/control/CellEditEventOfTreeTableColumnTest.java line 186: > 184: root.setExpanded(true); > 185: ObservableList model = FXCollections.observableArrayList("Four", "Five", "Fear"); > 186: // "Flop", "Food", "Fizz" Did you forget to remove this comment? ------------- PR: https://git.openjdk.java.net/jfx/pull/611 From mstrauss at openjdk.java.net Fri Sep 3 18:36:00 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Sep 2021 18:36:00 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell Message-ID: This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. --------- ### Progress - [x] Change must not contain extraneous whitespace - [x] Commit message must refer to an issue - [ ] Change must be properly reviewed ### Error  ?? The pull request body must not be empty. ### Reviewing
Using git Checkout this PR locally: \ `$ git fetch https://git.openjdk.java.net/jfx pull/617/head:pull/617` \ `$ git checkout pull/617` Update a local copy of the PR: \ `$ git checkout pull/617` \ `$ git pull https://git.openjdk.java.net/jfx pull/617/head`
Using Skara CLI tools Checkout this PR locally: \ `$ git pr checkout 617` View PR using the GUI difftool: \ `$ git pr show -t 617`
Using diff file Download this PR as a diff file: \ https://git.openjdk.java.net/jfx/pull/617.diff
------------- Commit messages: - fixed IllegalArgumentException Changes: https://git.openjdk.java.net/jfx/pull/617/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273324 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/617.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/617/head:pull/617 PR: https://git.openjdk.java.net/jfx/pull/617 From mstrauss at openjdk.java.net Fri Sep 3 18:36:04 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Sep 2021 18:36:04 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 18:19:45 GMT, Michael Strau? wrote: > This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > ### Error >  ?? The pull request body must not be empty. > > > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.java.net/jfx pull/617/head:pull/617` \ > `$ git checkout pull/617` > > Update a local copy of the PR: \ > `$ git checkout pull/617` \ > `$ git pull https://git.openjdk.java.net/jfx pull/617/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 617` > > View PR using the GUI difftool: \ > `$ git pr show -t 617` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.java.net/jfx/pull/617.diff > >
It's quite hard to come up with a meaningful test for this fix. While I can reproduce the failure mode, "passing" the test would simply mean not failing with an exception. There are no meaningful assertions until the [underlying problem](https://bugs.openjdk.java.net/browse/JDK-8273336) is fixed. ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From kcr at openjdk.java.net Fri Sep 3 19:13:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Sep 2021 19:13:25 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 18:19:45 GMT, Michael Strau? wrote: > This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > ### Error >  ?? The pull request body must not be empty. > > > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.java.net/jfx pull/617/head:pull/617` \ > `$ git checkout pull/617` > > Update a local copy of the PR: \ > `$ git checkout pull/617` \ > `$ git pull https://git.openjdk.java.net/jfx pull/617/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 617` > > View PR using the GUI difftool: \ > `$ git pr show -t 617` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.java.net/jfx/pull/617.diff > >
The fix looks correct to me. Can we get a unit test for this case? ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From jpereda at openjdk.java.net Fri Sep 3 20:33:11 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 3 Sep 2021 20:33:11 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 18:19:45 GMT, Michael Strau? wrote: > This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. Marked as reviewed by jpereda (Committer). Looks good to me too. It solves the exception, and also solves the incorrect null element that was logged: `Change: { [null] removed at 1 }, selected items: []` now reports correctly as `Change: { [Person{a b}] removed at 0 }, selected items: []` ). (However, the deselected cell is still showing as selected, but that is for [JDK-8273336](https://bugs.openjdk.java.net/browse/JDK-8273336).) ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From kcr at openjdk.java.net Fri Sep 3 20:56:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Sep 2021 20:56:07 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | The explanation makes sense, and both the fix and the test look good. I can confirm that the new test fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/614 From kcr at openjdk.java.net Fri Sep 3 21:11:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Sep 2021 21:11:09 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: <4jwwsPx1DVeTlLIsTSke_SZlMdkzdHEZgWyYz4iaQHg=.e809373a-94dd-4274-888f-0d7b7cf84e3a@github.com> References: <4jwwsPx1DVeTlLIsTSke_SZlMdkzdHEZgWyYz4iaQHg=.e809373a-94dd-4274-888f-0d7b7cf84e3a@github.com> Message-ID: On Fri, 3 Sep 2021 13:23:39 GMT, Marius Hanl wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected comment tags > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 366: > >> 364: */ >> 365: public static Background fill(Paint fill) { >> 366: return new Background(new BackgroundFill(fill, null, null)); > > null **CornerRaddii** and null **Insets** will use **CornerRadii.EMPTY** and **Insets.EMPTY**. Maybe we should use those here instead so it's more clear for anyone having a look in the source code? I also always use those instead of null. > Same for **BorderStroke** Are you talking about the implementation or the code? I guess both, since the `@implSepc` indicates what this call is equivalent to. I don't have a strong opinion on this one. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From kcr at openjdk.java.net Fri Sep 3 21:11:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Sep 2021 21:11:08 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: Message-ID: On Thu, 2 Sep 2021 12:14:58 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected comment tags > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 357: > >> 355: >> 356: /** >> 357: * A convenience factory method for creating a background with a single {@code Paint}. The background will use the > > Suggestion to rephrase as: > `A convenience factory method for creating a Background by specifying only the {@code Paint} for BackgroundFill` Since the `Background` constructors take a list of `Paint` objects, I think saying a "single" `{@code Paint}` is helpful. I can see how adding "for `BackgroundFill`" (or maybe "as a `BackgroundFill`"?) might make it clearer. > modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 361: > >> 359: * >> 360: * @implSpec This call is equivalent to {@code new Background(new BackgroundFill(fill, null, null));}. >> 361: * @param fill the fill of the background > > `@param fill Any Paint. If null, the value Color.TRANSPARENT is used.` > > Picked from BackgroundFill constructor's doc Good idea to indicate what happens on `null`, although that might be better in the description? ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From mstrauss at openjdk.java.net Fri Sep 3 21:20:07 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 3 Sep 2021 21:20:07 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 19:10:40 GMT, Kevin Rushforth wrote: > Can we get a unit test for this case? This is a test that fails without the fix, and passes with the fix. However, there are no assertions, which is... strange. Once [JDK-8273336](https://bugs.openjdk.java.net/browse/JDK-8273336) is fixed, the test could validate the selection state. @Test public void test_jdk_8273324() { class Person { final String firstName, lastName; Person(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } public String getFirstName() { return firstName; } public String getLastName() { return lastName; } } var tableView = new TableView(); tableView.getSelectionModel().setCellSelectionEnabled(true); tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); var col1 = new TableColumn(); col1.setCellValueFactory(new PropertyValueFactory<>("firstName")); var col2 = new TableColumn(); col2.setCellValueFactory(new PropertyValueFactory<>("lastName")); tableView.getColumns().addAll(List.of(col1, col2)); var ab = new Person("a", "b"); tableView.getItems().add(ab); var cd = new Person("c", "d"); tableView.getItems().add(cd); tableView.getSelectionModel().select(0); tableView.getSelectionModel().clearAndSelect(0, col1); } ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From kcr at openjdk.java.net Fri Sep 3 21:32:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Sep 2021 21:32:27 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v6] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 17:01:00 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Use color to int32 converter instead of hash I just have a couple remaining comments. modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 97: > 95: > 96: private int fontSmoothingType; > 97: private Color backgroundColor = Color.WHITE; This might be a problem, since there are code paths that bypass `setBackgroundColor(Color)`. I might recommend storing the converted 32-bit color, and then checking that for transparency. Either that or you will need to derive a `Color` from a 32-bit int in the cases that set a 32-bit int color directly. The former is probably easier. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Fri Sep 3 21:32:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Sep 2021 21:32:40 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: <93SV4Qk57pLyW711Z7cxfOP6qbN6rBOfdJR_WXHiVR8=.611ad06d-f2d2-4a64-96cd-16a729b3632c@github.com> References: <7zOdT4itDTUHytx49g6scMXHOW4b3pWEhERb96fr_UY=.fcacf5e2-d2f6-4b67-9361-521a1166d179@github.com> <0MA1oKn0b6q1IyqzRGB8pONGvxZ6ATDrdl3zLw1TcMM=.072d4745-4944-475b-8482-e5aae62d0e81@github.com> <93SV4Qk57pLyW711Z7cxfOP6qbN6rBOfdJR_WXHiVR8=.611ad06d-f2d2-4a64-96cd-16a729b3632c@github.com> Message-ID: <8unV9ja2V9qK5x0KehPFcAPmtVOhBLB-70fbebNTOZU=.2892729d-aa87-4603-9acf-5a2c10619058@github.com> On Fri, 27 Aug 2021 17:34:25 GMT, Jose Pereda wrote: >> I'm more worried about correctness than performance. Setting a clip does not necessarily imply that the clipped region should be cleared. So this feels a bit like a workaround for a missing `clearRect` elsewhere. I wonder if there is code somewhere that assumes that if the fill color is fully transparent it can skip the call to `clearRect`? > > I guess the assumption might be the other way around? Since the fill color was not transparent, there was no need to clear the area, when rendering the same solid rect at the new position? > > If you check this [comment](https://bugs.openjdk.java.net/browse/JDK-8090547?focusedCommentId=13808421&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13808421), there is already a mention that `WCPageBackBufferImpl::copyArea` doesn't care about the alpha channel. > > The proposed patch: > > texture.createGraphics().clearQuad(x+dx, y+dy, x+dx+w, y+dy+h); > > could work if we could apply it conditionally only for alpha == 0 (or maybe also for alpha < 1). > > My current approach with `clearRect` ultimately calls `clearQuad`, so both might be doing the same after all. I don't doubt that the area should be cleared. What I was questioning is whether this was the best place to do it? I'd be OK with it if you document it. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From hjohn at xs4all.nl Fri Sep 3 21:51:01 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 3 Sep 2021 23:51:01 +0200 Subject: Get how many monitors are connected. In-Reply-To: References: <9618ecf6-afcf-bad2-83f3-cb001340947c@dpsoftware.org> <741ea953-64c1-6af8-bc41-8c06fe8891ad@oracle.com> Message-ID: In what order would you want them? Windows itself isn't all that reliable either -- it will randomly reorder my screens sometimes when resuming from sleep depending on how quickly all the monitors respond. Currently my primary monitor is screen 2 according to Windows. Using the bounds you can determine however what is the left/right most screen and which screens go in between. --John On 03/09/2021 16:58, Davide Perini wrote: > mmm... > I confirm that it isn't really reliable. > > I have noticed the Screen.getScreens() have primary screen as the first > element, but other screens are just in a non correct order. > > Hope that JavaFX will find a way to overcome this problem. > > Thank you > Davide > > > Il 03/09/2021 16:39, Kevin Rushforth ha scritto: >> I don't think so. You can find out the primary monitor with >> Screen.getPrimary(), and you can determine the positioning of all >> screens relative to each other using the visual bounds of each screen. >> There isn't any guarantee, though, that the list of screens is >> ordered, so if there are more than 2 screens, I don't know of a >> reliable way to distinguish the second, third, and so on. >> >> -- Kevin >> >> >> On 9/3/2021 7:06 AM, Davide Perini wrote: >>> Hi, >>> I'm using this to get how many monitors is connected to the PC: >>> >>> for (Screen screen : Screen.getScreens()) { >>> >>> >>> } >>> >>> >>> Is there a way to know what is the first, second and third monitor? >>> Using Windows and I would like to see what is the first monitor set >>> in windows, what's the second and so on. >>> >>> Is this possible using JavaFX? >>> >>> Thanks >>> Davide >>> >> > From kcr at openjdk.java.net Fri Sep 3 21:52:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Sep 2021 21:52:51 GMT Subject: RFR: 8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 17:09:46 GMT, Abhinay Agarwal wrote: > 8172095: Let Node.managed become CSS-styleable The new API looks fine. I left one comment on the cssref docs, and that's otherwise ready to go (so you can get the CSR ready). I noticed that there are no existing tests in `NodeTest` for the default value or for setting / getting the property, which there are for other properties. Can you add these missing tests, to verify that there are no problems? modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html line 1755: > 1753: > 1754: -fx-managed > 1755: This isn't rendered correctly. You need to use `<boolean>`. ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From kevin.rushforth at oracle.com Fri Sep 3 22:44:11 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 3 Sep 2021 15:44:11 -0700 Subject: Usage of Stream::peek in Project In-Reply-To: <974310702.80319.1630661234811@office.mailbox.org> References: <974310702.80319.1630661234811@office.mailbox.org> Message-ID: <4e60e108-a99e-1f0b-4cb8-a429fb4f0882@oracle.com> Thanks for pointing this out. We don't use parallel streams for the cases in question, so we don't have the concurrency concerns that the stream docs point out. However, we should take a look and make sure that the call to peek can't be optimized out, since I expect some applications will start running with JDK 17 as soon as it is released (in less than 2 weeks). I filed a bug to investigate this: https://bugs.openjdk.java.net/browse/JDK-8273349 -- Kevin On 9/3/2021 2:27 AM, dev.infeo at mailbox.org wrote: > Hey all, > > recently I stumbled over the problem of non-executing stream operations, especially `Stream.peek(Consumer action)`, for more Info see [1]. With JDK 17 this behaviour is even extended (e.g. skip() preserves the SIZED attribute of a stream, making optimizations possible). > > Out of curiosity I searched the sources at HEAD of peek(...) usages and found two problematic classes: > * javafx.scene.control.MultipleSelectionModelBase: Line 745 > * javafx.scene.control.ControlsUtil: Line 165 & 171 > > Especially the statement around line 171 in ControlsUtil is a candidate which might be "optimized" to not execute the peek(...) at all, while the inline comment states the call to peek is crucial. > > I don't know what the roadmap says about updating to JDK17, but it might already be a problem and I wantend to raise attention to this. > > Best Regards, > Armin > > > [1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/package-summary.html#SideEffects From fastegal at openjdk.java.net Sat Sep 4 08:46:49 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 4 Sep 2021 08:46:49 GMT Subject: RFR: 8269871: CellEditEvent: must not throw NPE in accessors In-Reply-To: References: Message-ID: <4oCDA_U48CzNSCBUlhLpfRnENTiI6YZdnoNaoomEjNM=.54fc7e13-8048-467d-89dd-9ba36dfb0dc0@github.com> On Fri, 3 Sep 2021 15:00:32 GMT, Ajit Ghaisas wrote: >> The issue is unguarded access to tablePosition though it might be null (since [JDK-8120610](https://bugs.openjdk.java.net/browse/JDK-8120610) >> >> The fix is to check against null in each accessor. Also required to fix the default onEditCommit handlers in Tree/TableColumn to really cope with null TablePostion on the event. >> >> Added tests that failed/pass before/after the fix. >> >> Note that there was an old test (in Tree/TableColumnTest each), that failed after the fix because it expected the NPE. Fixed by removing the expected parameter. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/CellEditEventOfTreeTableColumnTest.java line 186: > >> 184: root.setExpanded(true); >> 185: ObservableList model = FXCollections.observableArrayList("Four", "Five", "Fear"); >> 186: // "Flop", "Food", "Fizz" > > Did you forget to remove this comment? yeah, pitfalls of c&p test boiler-plate code ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/611 From fastegal at openjdk.java.net Sat Sep 4 08:57:28 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sat, 4 Sep 2021 08:57:28 GMT Subject: RFR: 8269871: CellEditEvent: must not throw NPE in accessors [v2] In-Reply-To: References: Message-ID: > The issue is unguarded access to tablePosition though it might be null (since [JDK-8120610](https://bugs.openjdk.java.net/browse/JDK-8120610) > > The fix is to check against null in each accessor. Also required to fix the default onEditCommit handlers in Tree/TableColumn to really cope with null TablePostion on the event. > > Added tests that failed/pass before/after the fix. > > Note that there was an old test (in Tree/TableColumnTest each), that failed after the fix because it expected the NPE. Fixed by removing the expected parameter. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: removed forgotten code comments in tests as per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/611/files - new: https://git.openjdk.java.net/jfx/pull/611/files/b6540a2d..7082541d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=611&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=611&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/611.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/611/head:pull/611 PR: https://git.openjdk.java.net/jfx/pull/611 From mhanl at openjdk.java.net Sat Sep 4 11:23:54 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sat, 4 Sep 2021 11:23:54 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 21:17:11 GMT, Michael Strau? wrote: > > Can we get a unit test for this case? > > This is a test that fails without the fix, and passes with the fix. However, there are no assertions, which is... strange. Once [JDK-8273336](https://bugs.openjdk.java.net/browse/JDK-8273336) is fixed, the test could validate the selection state. > That is still fine. I also don't like to write tests without at least one assertion, but there is not other way in JUnit4. I ended up writing a comment above the problematic call, e.g.: `// Should not throw an NPE.` ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From kcr at openjdk.java.net Sat Sep 4 15:43:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 4 Sep 2021 15:43:56 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 11:20:30 GMT, Marius Hanl wrote: >>> Can we get a unit test for this case? >> >> This is a test that fails without the fix, and passes with the fix. However, there are no assertions, which is... strange. Once [JDK-8273336](https://bugs.openjdk.java.net/browse/JDK-8273336) is fixed, the test could validate the selection state. >> >> >> @Test >> public void test_jdk_8273324() { >> class Person { >> final String firstName, lastName; >> Person(String firstName, String lastName) { >> this.firstName = firstName; >> this.lastName = lastName; >> } >> public String getFirstName() { return firstName; } >> public String getLastName() { return lastName; } >> } >> >> var tableView = new TableView(); >> tableView.getSelectionModel().setCellSelectionEnabled(true); >> tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); >> >> var col1 = new TableColumn(); >> col1.setCellValueFactory(new PropertyValueFactory<>("firstName")); >> var col2 = new TableColumn(); >> col2.setCellValueFactory(new PropertyValueFactory<>("lastName")); >> tableView.getColumns().addAll(List.of(col1, col2)); >> >> var ab = new Person("a", "b"); >> tableView.getItems().add(ab); >> var cd = new Person("c", "d"); >> tableView.getItems().add(cd); >> >> tableView.getSelectionModel().select(0); >> tableView.getSelectionModel().clearAndSelect(0, col1); >> } > >> > Can we get a unit test for this case? >> >> This is a test that fails without the fix, and passes with the fix. However, there are no assertions, which is... strange. Once [JDK-8273336](https://bugs.openjdk.java.net/browse/JDK-8273336) is fixed, the test could validate the selection state. >> > > That is still fine. I also don't like to write tests without at least one assertion, but there is not other way in JUnit4. I ended up writing a comment above the problematic call, e.g.: `// Should not throw an NPE.` Your proposed unit test looks fine to me, and catches the bug. I agree with @Maran23 that as long as you add a comment that it should run without throwing NPE, it's OK to not have any asserts. One final point is that we have moved away from the practice of including the bug ID in the name of the method (or class, which we also used to do), and instead just use a meaningful name. You can add the bug ID in a comment. ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From github.com+3197675+abhinayagarwal at openjdk.java.net Sat Sep 4 15:44:17 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Sat, 4 Sep 2021 15:44:17 GMT Subject: RFR: 8172095: Let Node.managed become CSS-styleable [v2] In-Reply-To: References: Message-ID: > 8172095: Let Node.managed become CSS-styleable Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: - Add default value tests for setting / getting the managed property - Replace with HTML equivalent code ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/602/files - new: https://git.openjdk.java.net/jfx/pull/602/files/56b8f24b..394a47e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=602&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=602&range=00-01 Stats: 29 lines in 2 files changed: 28 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/602.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/602/head:pull/602 PR: https://git.openjdk.java.net/jfx/pull/602 From perini.davide at dpsoftware.org Sun Sep 5 13:48:28 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sun, 5 Sep 2021 15:48:28 +0200 Subject: Get how many monitors are connected. In-Reply-To: References: <9618ecf6-afcf-bad2-83f3-cb001340947c@dpsoftware.org> <741ea953-64c1-6af8-bc41-8c06fe8891ad@oracle.com> Message-ID: <839277f2-7ee0-2ded-aae4-5dee1811018d@dpsoftware.org> I would like to get the same order Windows uses. Thanks Davide Il 03/09/2021 23:51, John Hendrikx ha scritto: > In what order would you want them? > > Windows itself isn't all that reliable either -- it will randomly > reorder my screens sometimes when resuming from sleep depending on how > quickly all the monitors respond. Currently my primary monitor is > screen 2 according to Windows. > > Using the bounds you can determine however what is the left/right most > screen and which screens go in between. > > --John > > On 03/09/2021 16:58, Davide Perini wrote: >> mmm... >> I confirm that it isn't really reliable. >> >> I have noticed the Screen.getScreens() have primary screen as the first >> element, but other screens are just in a non correct order. >> >> Hope that JavaFX will find a way to overcome this problem. >> >> Thank you >> Davide >> >> >> Il 03/09/2021 16:39, Kevin Rushforth ha scritto: >>> I don't think so. You can find out the primary monitor with >>> Screen.getPrimary(), and you can determine the positioning of all >>> screens relative to each other using the visual bounds of each screen. >>> There isn't any guarantee, though, that the list of screens is >>> ordered, so if there are more than 2 screens, I don't know of a >>> reliable way to distinguish the second, third, and so on. >>> >>> -- Kevin >>> >>> >>> On 9/3/2021 7:06 AM, Davide Perini wrote: >>>> Hi, >>>> I'm using this to get how many monitors is connected to the PC: >>>> >>>> for (Screen screen : Screen.getScreens()) { >>>> >>>> >>>> } >>>> >>>> >>>> Is there a way to know what is the first, second and third monitor? >>>> Using Windows and I would like to see what is the first monitor set >>>> in windows, what's the second and so on. >>>> >>>> Is this possible using JavaFX? >>>> >>>> Thanks >>>> Davide >>>> >>> >> From perini.davide at dpsoftware.org Sun Sep 5 13:49:17 2021 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sun, 5 Sep 2021 15:49:17 +0200 Subject: Get location from HTML 5 webview Message-ID: Hi all, is it possible to get the location from an HTML5 webview? Thanks Davide From fastegal at openjdk.java.net Mon Sep 6 08:53:51 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 6 Sep 2021 08:53:51 GMT Subject: Integrated: 8269871: CellEditEvent: must not throw NPE in accessors In-Reply-To: References: Message-ID: On Thu, 26 Aug 2021 14:09:58 GMT, Jeanette Winzenburg wrote: > The issue is unguarded access to tablePosition though it might be null (since [JDK-8120610](https://bugs.openjdk.java.net/browse/JDK-8120610) > > The fix is to check against null in each accessor. Also required to fix the default onEditCommit handlers in Tree/TableColumn to really cope with null TablePostion on the event. > > Added tests that failed/pass before/after the fix. > > Note that there was an old test (in Tree/TableColumnTest each), that failed after the fix because it expected the NPE. Fixed by removing the expected parameter. This pull request has now been integrated. Changeset: 78ae4a81 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/78ae4a815b728f5a0dca8fa6de8ca68a27a1d189 Stats: 411 lines in 6 files changed: 391 ins; 5 del; 15 mod 8269871: CellEditEvent: must not throw NPE in accessors Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/611 From jpereda at openjdk.java.net Mon Sep 6 09:31:45 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 6 Sep 2021 09:31:45 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v6] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 21:19:09 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Use color to int32 converter instead of hash > > modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 97: > >> 95: >> 96: private int fontSmoothingType; >> 97: private Color backgroundColor = Color.WHITE; > > This might be a problem, since there are code paths that bypass `setBackgroundColor(Color)`. I might recommend storing the converted 32-bit color, and then checking that for transparency. Either that or you will need to derive a `Color` from a 32-bit int in the cases that set a 32-bit int color directly. The former is probably easier. In my first commit there was already a method to get the color out of the 32-bit int (which was still referred as hash value at that time): private static Color getColorFromHash(int hash) { String hexString = Integer.toHexString(hash); int length = hexString.length(); return Color.valueOf("#" + "0".repeat(8 - length) + hexString); } If we keep it in `WebPage` (renaming it accordingly to `getColorFromInt32` for instance), we could do: public void setBackgroundColor(Color backgroundColor) { setBackgroundColor(getColorInt32Value(backgroundColor)); } public void setBackgroundColor(int backgroundColor) { this.backgroundColor = getColorFromInt32(backgroundColor); lockPage(); ... } ``` which looks a little bit ugly. The other option, as you mention, is finding out if the 32-bit int has alpha 0 or 1, which can be done storing only the int value, not the color, so this looks cleaner, we don't really need to hold a reference to the Color after all: private int backgroundColor = -1; // Color.WHITE public void setBackgroundColor(Color backgroundColor) { setBackgroundColor(getColorInt32Value(backgroundColor)); } public void setBackgroundColor(int backgroundColor) { this.backgroundColor = backgroundColor; lockPage(); ... } private boolean isBackgroundTransparent() { return (backgroundColor & 0x000000FF) == 0; } private boolean isBackgroundOpaque() { return (backgroundColor & 0x000000FF) == 255; } ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From fthevenet at openjdk.java.net Mon Sep 6 10:03:42 2021 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 6 Sep 2021 10:03:42 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: <-U976EcUxPWIhKhVe8hG1Zq0znGXux-JlXlAGAwlS1c=.e54bd473-8c19-44c8-aae9-6602a5729b8b@github.com> On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | Am I correct in assuming that, as is, this PR is only going to be merged into openJFX 18 ? If so, because it addresses a regression introduced in jfx 17, we'll probably want to have this one in 17 as well on day one, if its not too late. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From mpaus at openjdk.java.net Mon Sep 6 10:07:48 2021 From: mpaus at openjdk.java.net (Michael Paus) Date: Mon, 6 Sep 2021 10:07:48 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v6] In-Reply-To: References: Message-ID: <6KQxHBAPxIW3IAuloIAHFUvI9PmR8h-v3i40CmdYJcA=.2ca8bccc-e65d-49dd-8922-c92715fa8b79@github.com> On Fri, 27 Aug 2021 17:01:00 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Use color to int32 converter instead of hash Always referring to Int32 is very vague and does not provide any information because this information is kind of obvious from the argument. It would be clearer to say RGBA (or whatever your assumption is) because that might help avoid confusion about which color component ordering you actually expect in your Int32. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From fkirmaier at openjdk.java.net Mon Sep 6 10:40:00 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 6 Sep 2021 10:40:00 GMT Subject: RFR: 8271395: Fixing crash at printing Message-ID: This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread. I'm open for better solutions on how to fix this Issue. Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread. ------------- Commit messages: - JDK-8271395 Fixing crash at printing Changes: https://git.openjdk.java.net/jfx/pull/618/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=618&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271395 Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/618.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/618/head:pull/618 PR: https://git.openjdk.java.net/jfx/pull/618 From mstrauss at openjdk.java.net Mon Sep 6 10:43:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 6 Sep 2021 10:43:43 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: <9Vk_liRZKZzGN0df5j4-aAV76l7nKtWzkEdLOiTS8Wc=.771e243d-5f52-47dc-8b9a-356a5f01d62f@github.com> On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | [It seems to be too late.](https://bugs.openjdk.java.net/browse/JDK-8273138?focusedCommentId=14445309&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14445309) ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From jpereda at openjdk.java.net Mon Sep 6 11:08:43 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 6 Sep 2021 11:08:43 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: <8unV9ja2V9qK5x0KehPFcAPmtVOhBLB-70fbebNTOZU=.2892729d-aa87-4603-9acf-5a2c10619058@github.com> References: <7zOdT4itDTUHytx49g6scMXHOW4b3pWEhERb96fr_UY=.fcacf5e2-d2f6-4b67-9361-521a1166d179@github.com> <0MA1oKn0b6q1IyqzRGB8pONGvxZ6ATDrdl3zLw1TcMM=.072d4745-4944-475b-8482-e5aae62d0e81@github.com> <93SV4Qk57pLyW711Z7cxfOP6qbN6rBOfdJR_WXHiVR8=.611ad06d-f2d2-4a64-96cd-16a729b3632c@github.com> <8unV9ja2V9qK5x0KehPFcAPmtVOhBLB-70fbebNTOZU=.2892729d-aa87-4603-9acf-5a2c10619058@github.com> Message-ID: On Fri, 3 Sep 2021 21:11:48 GMT, Kevin Rushforth wrote: >> I guess the assumption might be the other way around? Since the fill color was not transparent, there was no need to clear the area, when rendering the same solid rect at the new position? >> >> If you check this [comment](https://bugs.openjdk.java.net/browse/JDK-8090547?focusedCommentId=13808421&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13808421), there is already a mention that `WCPageBackBufferImpl::copyArea` doesn't care about the alpha channel. >> >> The proposed patch: >> >> texture.createGraphics().clearQuad(x+dx, y+dy, x+dx+w, y+dy+h); >> >> could work if we could apply it conditionally only for alpha == 0 (or maybe also for alpha < 1). >> >> My current approach with `clearRect` ultimately calls `clearQuad`, so both might be doing the same after all. > > I don't doubt that the area should be cleared. What I was questioning is whether this was the best place to do it? I'd be OK with it if you document it. The two options I see so far to clear the area are the one I've committed (change in `WCGraphicsPrismContext::setClip`) and the one I've mentioned above (`WCPageBackBufferImpl::copyArea`). After some more testing, I see that the latter doesn't work when there is full transparency, so I will discard it. Back to my original commit, it could be moved up to `WebPage::paint2GC`, before the call to `gc.setClip(rq.getClip());`, and that would also remove the need of passing down the opacity level to `WCGraphicsContext`. I also see now that the `clearRect()` call is required for full transparency only. This would be the change: WCRectangle clip = rq.getClip(); if (clip != null) { if (isBackgroundTransparent()) { // As backbuffer is enabled, new clips are drawn over the old rendered frames // regardless the alpha channel. While that works fine for alpha > 0, // for alpha == 0 we need to clear the old frame or it will still be visible. gc.clearRect((int) clip.getX(), (int) clip.getY(), (int) clip.getWidth(), (int) clip.getHeight()); } gc.setClip(clip); } ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From fthevenet at openjdk.java.net Mon Sep 6 12:35:39 2021 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 6 Sep 2021 12:35:39 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | I see. This is unfortunate though, as this will definitely break some applications in ways potentially difficult to diagnose. Maybe this won't be too bad if the window until 17.0.1 is small, but still, I'm afraid third party developers not following these discussions might be in for some head scratching. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From kcr at openjdk.java.net Mon Sep 6 13:23:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Sep 2021 13:23:43 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | Yes, it is far too late for 17 (code freeze was more than two weeks ago; GA is tomorrow). 17.0.1 should be out in about 6 weeks, and this is a candidate for backporting. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From kcr at openjdk.java.net Mon Sep 6 13:33:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Sep 2021 13:33:42 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v6] In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 17:01:00 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Use color to int32 converter instead of hash > The other option, as you mention, is finding out if the 32-bit int has alpha 0 or 1, which can be done storing only the int value, not the color, so this looks cleaner, we don't really need to hold a reference to the Color after all Yes, I like this better, too. I also agree with the point about including `rgba` in the name. It is also meaningful to keep `int` in the name. We would typically call this format `IntRgba`. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Mon Sep 6 13:40:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Sep 2021 13:40:42 GMT Subject: RFR: 8271395: Fixing crash at printing In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 10:33:28 GMT, Florian Kirmaier wrote: > This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread. > I'm open for better solutions on how to fix this Issue. > Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread. I haven't reviewed the approach yet. Presuming the approach is the right one, the implementation will need some refactoring to move the toolkit-specific logic into the toolkit. I'll provide more feedback when I go to review this. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumRenderer.java line 57: > 55: * Quantum Renderer > 56: */ > 57: final public class QuantumRenderer extends ThreadPoolExecutor { I am not in favor of making this class public. I would rather add a method to Toolkit, and have the overridden method in QuantumToolkit call the Quantum renderer as needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/618 From fthevenet at openjdk.java.net Mon Sep 6 13:46:37 2021 From: fthevenet at openjdk.java.net (Frederic Thevenet) Date: Mon, 6 Sep 2021 13:46:37 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: <8Mmtmr2gOxPVpOVAim3eXAHjB2hhNejhNn6GxlkmMs4=.d4271c69-ad63-41fc-9e69-f97eae16e5bf@github.com> On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | OK I see. I didn't realize GA is due for tomorrow already. I had September 14 in mind as a release date, but realize now that this is the date for OpenJDK. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From jpereda at openjdk.java.net Mon Sep 6 15:08:42 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 6 Sep 2021 15:08:42 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v6] In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 13:30:46 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Use color to int32 converter instead of hash > >> The other option, as you mention, is finding out if the 32-bit int has alpha 0 or 1, which can be done storing only the int value, not the color, so this looks cleaner, we don't really need to hold a reference to the Color after all > > Yes, I like this better, too. > > I also agree with the point about including `rgba` in the name. It is also meaningful to keep `int` in the name. We would typically call this format `IntRgba`. @kevinrushforth In case you didn't see it, I replied to your comment https://github.com/openjdk/jfx/pull/563#discussion_r702164954 here: https://github.com/openjdk/jfx/pull/563/files#r702814752 (but there was not email notification). ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From mstrauss at openjdk.java.net Mon Sep 6 19:23:58 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 6 Sep 2021 19:23:58 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell [v2] In-Reply-To: References: Message-ID: <-jZydcD_bAAaU0C9S70gjtFOvEeAp5gKnpc6SMFf3B8=.18f09e30-96f3-4916-9c79-035c969fea49@github.com> > This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: added test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/617/files - new: https://git.openjdk.java.net/jfx/pull/617/files/31bad0b6..483130c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=617&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=617&range=00-01 Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/617.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/617/head:pull/617 PR: https://git.openjdk.java.net/jfx/pull/617 From arapte at openjdk.java.net Tue Sep 7 06:34:38 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 7 Sep 2021 06:34:38 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 21:04:13 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 357: >> >>> 355: >>> 356: /** >>> 357: * A convenience factory method for creating a background with a single {@code Paint}. The background will use the >> >> Suggestion to rephrase as: >> `A convenience factory method for creating a Background by specifying only the {@code Paint} for BackgroundFill` > > Since the `Background` constructors take a list of `Paint` objects, I think saying a "single" `{@code Paint}` is helpful. I can see how adding "for `BackgroundFill`" (or maybe "as a `BackgroundFill`"?) might make it clearer. Sound good to me, It would read like `A convenience factory method for creating a Background by specifying a single {@code Paint} as a BackgroundFill` ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From arapte at openjdk.java.net Tue Sep 7 08:40:35 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 7 Sep 2021 08:40:35 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: Message-ID: <4PvSKci0A_kEwwxTTnrj-TzDJUiVqJN5LGdtIkREbsw=.ae01777b-e825-4702-ba00-f8240d3f09e5@github.com> On Fri, 3 Sep 2021 21:06:38 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 361: >> >>> 359: * >>> 360: * @implSpec This call is equivalent to {@code new Background(new BackgroundFill(fill, null, null));}. >>> 361: * @param fill the fill of the background >> >> `@param fill Any Paint. If null, the value Color.TRANSPARENT is used.` >> >> Picked from BackgroundFill constructor's doc > > Good idea to indicate what happens on `null`, although that might be better in the description? I think that should be fine too. How should we describe the @param in that case. `@param fill Any Paint as BackgroundFill` -> Does this sound good ? ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From github.com+3197675+abhinayagarwal at openjdk.java.net Tue Sep 7 09:15:50 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Tue, 7 Sep 2021 09:15:50 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 Message-ID: Add release notes for JavaFX 17 to the repository ------------- Commit messages: - 8273343: Create release notes for JavaFX 17 Changes: https://git.openjdk.java.net/jfx/pull/619/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=619&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273343 Stats: 134 lines in 1 file changed: 134 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/619.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/619/head:pull/619 PR: https://git.openjdk.java.net/jfx/pull/619 From arapte at openjdk.java.net Tue Sep 7 09:45:46 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 7 Sep 2021 09:45:46 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell [v2] In-Reply-To: <-jZydcD_bAAaU0C9S70gjtFOvEeAp5gKnpc6SMFf3B8=.18f09e30-96f3-4916-9c79-035c969fea49@github.com> References: <-jZydcD_bAAaU0C9S70gjtFOvEeAp5gKnpc6SMFf3B8=.18f09e30-96f3-4916-9c79-035c969fea49@github.com> Message-ID: <6CcdKnk4ycIpAWAXhAmEeKxO3ASSC2NCD3sszREOCds=.cf092b47-4d46-4da6-a244-b65c11f2be3f@github.com> On Mon, 6 Sep 2021 19:23:58 GMT, Michael Strau? wrote: >> This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > added test The exception can be observed in one other similar scenario. 1. Run the program attached to [JDK-8273324](https://bugs.openjdk.java.net/browse/JDK-8273324). 2. Click on a 3. Shift + Click on d 4. Click on d -> The same exception can be observed. ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From jpereda at openjdk.java.net Tue Sep 7 10:02:39 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 7 Sep 2021 10:02:39 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell [v2] In-Reply-To: <6CcdKnk4ycIpAWAXhAmEeKxO3ASSC2NCD3sszREOCds=.cf092b47-4d46-4da6-a244-b65c11f2be3f@github.com> References: <-jZydcD_bAAaU0C9S70gjtFOvEeAp5gKnpc6SMFf3B8=.18f09e30-96f3-4916-9c79-035c969fea49@github.com> <6CcdKnk4ycIpAWAXhAmEeKxO3ASSC2NCD3sszREOCds=.cf092b47-4d46-4da6-a244-b65c11f2be3f@github.com> Message-ID: On Tue, 7 Sep 2021 09:42:43 GMT, Ambarish Rapte wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> added test > > The exception can be observed in one other similar scenario. > 1. Run the program attached to [JDK-8273324](https://bugs.openjdk.java.net/browse/JDK-8273324). > 2. Click on a > 3. Shift + Click on d > 4. Click on d > -> The same exception can be observed. @arapte yes, you are right, I can reproduce it too after the proposed fix is applied. For this case, `insertionPoint = 2`, so probably we need: -if (insertionPoint == 0) { +if (insertionPoint >= 0) { ``` ? ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From mstrauss at openjdk.java.net Tue Sep 7 10:40:01 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 Sep 2021 10:40:01 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell [v3] In-Reply-To: References: Message-ID: > This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fixed case of multi-selection across several rows ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/617/files - new: https://git.openjdk.java.net/jfx/pull/617/files/483130c0..c853c3e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=617&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=617&range=01-02 Stats: 14 lines in 2 files changed: 9 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/617.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/617/head:pull/617 PR: https://git.openjdk.java.net/jfx/pull/617 From mstrauss at openjdk.java.net Tue Sep 7 10:40:02 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 Sep 2021 10:40:02 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell [v2] In-Reply-To: <6CcdKnk4ycIpAWAXhAmEeKxO3ASSC2NCD3sszREOCds=.cf092b47-4d46-4da6-a244-b65c11f2be3f@github.com> References: <-jZydcD_bAAaU0C9S70gjtFOvEeAp5gKnpc6SMFf3B8=.18f09e30-96f3-4916-9c79-035c969fea49@github.com> <6CcdKnk4ycIpAWAXhAmEeKxO3ASSC2NCD3sszREOCds=.cf092b47-4d46-4da6-a244-b65c11f2be3f@github.com> Message-ID: On Tue, 7 Sep 2021 09:42:43 GMT, Ambarish Rapte wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> added test > > The exception can be observed in one other similar scenario. > 1. Run the program attached to [JDK-8273324](https://bugs.openjdk.java.net/browse/JDK-8273324). > 2. Click on a > 3. Shift + Click on d > 4. Click on d > -> The same exception can be observed. > @arapte yes, you are right, I can reproduce it too after the proposed fix is applied. > > For this case, `insertionPoint = 2`, so probably we need: > > ``` > -if (insertionPoint == 0) { > +if (insertionPoint >= 0) { > ``` > > ? Yes, basically all cases in which the cleared rows contain the retained row. ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From nlisker at openjdk.java.net Tue Sep 7 10:56:35 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 7 Sep 2021 10:56:35 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: <2NVoi3JHqfqf3Pt4tJnQ5Kf4N4nIcL534H6M3N5ChT4=.b81461dc-f34d-41fd-a258-45ecaee81909@github.com> On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | There's an ongoing discussion about the eager evaluation of invalidation listeners in the [mailing list](http://mail.openjdk.java.net/pipermail/openjfx-dev/2021-September/031801.html). Its conclusion might affect this patch, I didn't look at this one closely. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From nlisker at openjdk.java.net Tue Sep 7 11:31:38 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 7 Sep 2021 11:31:38 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: <4PvSKci0A_kEwwxTTnrj-TzDJUiVqJN5LGdtIkREbsw=.ae01777b-e825-4702-ba00-f8240d3f09e5@github.com> References: <4PvSKci0A_kEwwxTTnrj-TzDJUiVqJN5LGdtIkREbsw=.ae01777b-e825-4702-ba00-f8240d3f09e5@github.com> Message-ID: On Tue, 7 Sep 2021 08:37:31 GMT, Ambarish Rapte wrote: >> Good idea to indicate what happens on `null`, although that might be better in the description? > > I think that should be fine too. > How should we describe the @param in that case. > `@param fill Any Paint as BackgroundFill` -> Does this sound good ? I disliked the docs of `BackgroundFill` in that regard. If the type of a parameter `t` is `T`, saying in the docs `@param t any T` is useless. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From jvos at openjdk.java.net Tue Sep 7 12:11:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Sep 2021 12:11:42 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 In-Reply-To: References: Message-ID: <1xEwJJDmpfQ43NqLFfwznNMhzmsUFPoXEUxW-NWmP9Y=.e9d42322-6d99-4b69-9805-6bd9a2c2ed0d@github.com> On Tue, 7 Sep 2021 09:11:41 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 17 to the repository doc-files/release-notes-17.md line 32: > 30: [JDK-8259680](https://bugs.openjdk.java.net/browse/JDK-8259680)|Need API to query states of CAPS LOCK and NUM LOCK keys|scenegraph > 31: > 32: ## List of Sub-task Technically, the following issue is of type Sub-task indeed -- but it is a very old issue. We might move it to enhancement, as today we would probably categorize it as such? ------------- PR: https://git.openjdk.java.net/jfx/pull/619 From kcr at openjdk.java.net Tue Sep 7 12:17:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 12:17:40 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 In-Reply-To: References: Message-ID: <98F5du5eTNWFD_-HMWzismF5RakfuH8qXDFDRSmpMoY=.de14c6d8-27df-4c34-b234-97c03f257660@github.com> On Tue, 7 Sep 2021 09:11:41 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 17 to the repository I noted a few bugs that probably shouldn't be on this list. The rest looks good. doc-files/release-notes-17.md line 27: > 25: [JDK-8267551](https://bugs.openjdk.java.net/browse/JDK-8267551)|Support loading images from inline data-URIs|graphics > 26: [JDK-8268120](https://bugs.openjdk.java.net/browse/JDK-8268120)|Allow hardware cursor to be used on Monocle-EGL platforms|graphics > 27: [JDK-8257895](https://bugs.openjdk.java.net/browse/JDK-8257895)|Allow building of JavaFX media libs for Apple Silicon|media Maybe remove? doc-files/release-notes-17.md line 36: > 34: Issue key|Summary|Subcomponent > 35: ---------|-------|------------ > 36: [JDK-8092439](https://bugs.openjdk.java.net/browse/JDK-8092439)|[Monocle] Refactor monocle SPI to allow support for multiple screens|graphics Since this is just refactoring, I probably wouldn't mention it in the release notes. I added the `noreg-cleanup` label in JBS. doc-files/release-notes-17.md line 62: > 60: [JDK-8244075](https://bugs.openjdk.java.net/browse/JDK-8244075)|Accelerator of ContextMenu's MenuItem is not removed when ContextMenu is removed from Scene|controls > 61: [JDK-8252238](https://bugs.openjdk.java.net/browse/JDK-8252238)|TableView: Editable (pseudo-editable) cells should respect the row editability|controls > 62: [JDK-8252820](https://bugs.openjdk.java.net/browse/JDK-8252820)|Skins: cleanup use of deprecated snapSize/snapPosition|controls Maybe remove? doc-files/release-notes-17.md line 92: > 90: [JDK-8262802](https://bugs.openjdk.java.net/browse/JDK-8262802)|Wrong context origin coordinates when using EGL and HiDPI|graphics > 91: [JDK-8263402](https://bugs.openjdk.java.net/browse/JDK-8263402)|MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene|graphics > 92: [JDK-8263778](https://bugs.openjdk.java.net/browse/JDK-8263778)|Fix monocle JNI signatures for instance methods|graphics Maybe remove? doc-files/release-notes-17.md line 95: > 93: [JDK-8267160](https://bugs.openjdk.java.net/browse/JDK-8267160)|Monocle mouse never get ENTERED state|graphics > 94: [JDK-8267314](https://bugs.openjdk.java.net/browse/JDK-8267314)|Loading some animated GIFs fails with ArrayIndexOutOfBoundsException: Index 4096 out of bounds for length 4096|graphics > 95: [JDK-8267621](https://bugs.openjdk.java.net/browse/JDK-8267621)|Mark HonorDeveloperSettingsTest as unstable on Linux|graphics This is a test bug (I just added the missing label), so need not be listed. doc-files/release-notes-17.md line 116: > 114: [JDK-8260245](https://bugs.openjdk.java.net/browse/JDK-8260245)|Update ICU4C to version 68.2|web > 115: [JDK-8260257](https://bugs.openjdk.java.net/browse/JDK-8260257)|[Linux] WebView no longer reacts to some mouse events|web > 116: [JDK-8261927](https://bugs.openjdk.java.net/browse/JDK-8261927)|WebKit build fails with Visual Studio 2017|web Maybe remove? ------------- PR: https://git.openjdk.java.net/jfx/pull/619 From kcr at openjdk.java.net Tue Sep 7 12:17:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 12:17:41 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 In-Reply-To: <1xEwJJDmpfQ43NqLFfwznNMhzmsUFPoXEUxW-NWmP9Y=.e9d42322-6d99-4b69-9805-6bd9a2c2ed0d@github.com> References: <1xEwJJDmpfQ43NqLFfwznNMhzmsUFPoXEUxW-NWmP9Y=.e9d42322-6d99-4b69-9805-6bd9a2c2ed0d@github.com> Message-ID: On Tue, 7 Sep 2021 12:08:32 GMT, Johan Vos wrote: >> Add release notes for JavaFX 17 to the repository > > doc-files/release-notes-17.md line 32: > >> 30: [JDK-8259680](https://bugs.openjdk.java.net/browse/JDK-8259680)|Need API to query states of CAPS LOCK and NUM LOCK keys|scenegraph >> 31: >> 32: ## List of Sub-task > > Technically, the following issue is of type Sub-task indeed -- but it is a very old issue. We might move it to enhancement, as today we would probably categorize it as such? Yes, since it is a sub-task of an Enhancement, it could be listed as an enhancement. In this case, since it is just cleanup refactoring, and shouldn't have any impact on developers, I would probably just exclude it. ------------- PR: https://git.openjdk.java.net/jfx/pull/619 From mstrauss at openjdk.java.net Tue Sep 7 12:40:44 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 Sep 2021 12:40:44 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: <2NVoi3JHqfqf3Pt4tJnQ5Kf4N4nIcL534H6M3N5ChT4=.b81461dc-f34d-41fd-a258-45ecaee81909@github.com> References: <2NVoi3JHqfqf3Pt4tJnQ5Kf4N4nIcL534H6M3N5ChT4=.b81461dc-f34d-41fd-a258-45ecaee81909@github.com> Message-ID: On Tue, 7 Sep 2021 10:53:48 GMT, Nir Lisker wrote: > There's an ongoing discussion about the eager evaluation of invalidation listeners in the [mailing list](http://mail.openjdk.java.net/pipermail/openjfx-dev/2021-September/031801.html). Its conclusion might affect this patch, I didn't look at this one closely. The discussion is about whether adding a listener should validate the property. With this fix, both properties are validated in all relevant code paths, so it doesn't matter whether or not any of the properties is validated by adding an invalidation listener. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From jvos at openjdk.java.net Tue Sep 7 12:42:39 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Sep 2021 12:42:39 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 In-Reply-To: <98F5du5eTNWFD_-HMWzismF5RakfuH8qXDFDRSmpMoY=.de14c6d8-27df-4c34-b234-97c03f257660@github.com> References: <98F5du5eTNWFD_-HMWzismF5RakfuH8qXDFDRSmpMoY=.de14c6d8-27df-4c34-b234-97c03f257660@github.com> Message-ID: On Tue, 7 Sep 2021 12:03:51 GMT, Kevin Rushforth wrote: >> Add release notes for JavaFX 17 to the repository > > doc-files/release-notes-17.md line 36: > >> 34: Issue key|Summary|Subcomponent >> 35: ---------|-------|------------ >> 36: [JDK-8092439](https://bugs.openjdk.java.net/browse/JDK-8092439)|[Monocle] Refactor monocle SPI to allow support for multiple screens|graphics > > Since this is just refactoring, I probably wouldn't mention it in the release notes. I added the `noreg-cleanup` label in JBS. The commit does more than refactoring the SPI, so the issue was probably not the best one to link with this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/619 From kcr at openjdk.java.net Tue Sep 7 12:51:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 12:51:39 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 In-Reply-To: References: <98F5du5eTNWFD_-HMWzismF5RakfuH8qXDFDRSmpMoY=.de14c6d8-27df-4c34-b234-97c03f257660@github.com> Message-ID: On Tue, 7 Sep 2021 12:39:53 GMT, Johan Vos wrote: >> doc-files/release-notes-17.md line 36: >> >>> 34: Issue key|Summary|Subcomponent >>> 35: ---------|-------|------------ >>> 36: [JDK-8092439](https://bugs.openjdk.java.net/browse/JDK-8092439)|[Monocle] Refactor monocle SPI to allow support for multiple screens|graphics >> >> Since this is just refactoring, I probably wouldn't mention it in the release notes. I added the `noreg-cleanup` label in JBS. > > The commit does more than refactoring the SPI, so the issue was probably not the best one to link with this PR. I removed the `noreg-cleanup` label. ------------- PR: https://git.openjdk.java.net/jfx/pull/619 From kcr at openjdk.java.net Tue Sep 7 12:51:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 12:51:39 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 In-Reply-To: References: <1xEwJJDmpfQ43NqLFfwznNMhzmsUFPoXEUxW-NWmP9Y=.e9d42322-6d99-4b69-9805-6bd9a2c2ed0d@github.com> Message-ID: On Tue, 7 Sep 2021 12:14:30 GMT, Kevin Rushforth wrote: >> doc-files/release-notes-17.md line 32: >> >>> 30: [JDK-8259680](https://bugs.openjdk.java.net/browse/JDK-8259680)|Need API to query states of CAPS LOCK and NUM LOCK keys|scenegraph >>> 31: >>> 32: ## List of Sub-task >> >> Technically, the following issue is of type Sub-task indeed -- but it is a very old issue. We might move it to enhancement, as today we would probably categorize it as such? > > Yes, since it is a sub-task of an Enhancement, it could be listed as an enhancement. In this case, since it is just cleanup refactoring, and shouldn't have any impact on developers, I would probably just exclude it. Ignore the part about excluding it. I misread what it does. So listing it as an enhancement seems the way to go. ------------- PR: https://git.openjdk.java.net/jfx/pull/619 From github.com+3197675+abhinayagarwal at openjdk.java.net Tue Sep 7 13:09:03 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Tue, 7 Sep 2021 13:09:03 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 [v2] In-Reply-To: References: Message-ID: > Add release notes for JavaFX 17 to the repository Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Remove list items as per review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/619/files - new: https://git.openjdk.java.net/jfx/pull/619/files/d50d5808..58d6bb0e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=619&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=619&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/619.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/619/head:pull/619 PR: https://git.openjdk.java.net/jfx/pull/619 From jvos at openjdk.java.net Tue Sep 7 13:09:04 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 7 Sep 2021 13:09:04 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 [v2] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 13:06:07 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 17 to the repository > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Remove list items as per review Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/619 From kcr at openjdk.java.net Tue Sep 7 13:09:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 13:09:04 GMT Subject: [jfx17] RFR: 8273343: Create release notes for JavaFX 17 [v2] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 13:06:07 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 17 to the repository > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Remove list items as per review Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/619 From github.com+3197675+abhinayagarwal at openjdk.java.net Tue Sep 7 13:09:05 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Tue, 7 Sep 2021 13:09:05 GMT Subject: [jfx17] Integrated: 8273343: Create release notes for JavaFX 17 In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 09:11:41 GMT, Abhinay Agarwal wrote: > Add release notes for JavaFX 17 to the repository This pull request has now been integrated. Changeset: 24d0600a Author: Abhinay Agarwal Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/24d0600a867e889eccd80a114f6141c56f165ad8 Stats: 124 lines in 1 file changed: 124 ins; 0 del; 0 mod 8273343: Create release notes for JavaFX 17 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/619 From jpereda at openjdk.java.net Tue Sep 7 14:45:38 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 7 Sep 2021 14:45:38 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell [v3] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 10:40:01 GMT, Michael Strau? wrote: >> This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed case of multi-selection across several rows modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 386: > 384: selectionModel.clearAndSelect(0, col1); > 385: > 386: // The following asserts should work once JDK-8273336 is fixed: @mstr2 About this issue, I've added a [comment](https://bugs.openjdk.java.net/browse/JDK-8273336?focusedCommentId=14445984&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14445984), in case you have some time to check it. With my possible fix, these assertions work fine, but fail without it. ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From fastegal at openjdk.java.net Tue Sep 7 14:58:51 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 7 Sep 2021 14:58:51 GMT Subject: RFR: 8271474: Tree-/TableCell: inconsistent edit event firing pattern Message-ID: this PR fixes the inconsistent event firing pattern in cell's xxEdit methods (please see the issue for more details): - fires event if column != null - accesses table state if table != null The first requires a change in CellEditEvent which now allows null table in its constructor. Added tests that failed/passed before/after the fix (along with some that also passed before for complete coverage of state permutations). Changed two old test methods which passed/failed before/after the fix - but did test the wrong thingy anyway ;) ------------- Commit messages: - 8271474: Tree-/TableCell: inconsistent edit event firing pattern Changes: https://git.openjdk.java.net/jfx/pull/620/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=620&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271474 Stats: 404 lines in 12 files changed: 358 ins; 22 del; 24 mod Patch: https://git.openjdk.java.net/jfx/pull/620.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/620/head:pull/620 PR: https://git.openjdk.java.net/jfx/pull/620 From kcr at openjdk.java.net Tue Sep 7 18:53:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 18:53:37 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | I think that restoring the existing behavior to fix this regression is important, and needs to be done regardless of what we might do in the future. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From mstrauss at openjdk.java.net Tue Sep 7 19:46:07 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 7 Sep 2021 19:46:07 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 18:50:18 GMT, Kevin Rushforth wrote: > I think that restoring the existing behavior to fix this regression is important, and needs to be done regardless of what we might do in the future. This PR does that. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From kcr at openjdk.java.net Tue Sep 7 19:50:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 19:50:13 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 19:43:36 GMT, Michael Strau? wrote: > > I think that restoring the existing behavior to fix this regression is important, and needs to be done regardless of what we might do in the future. > > This PR does that. Indeed it does. My comment was meant in reply to the point @nlisker raised. Sorry for not making that clear. ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From john at status6.com Tue Sep 7 22:49:56 2021 From: john at status6.com (John Neffenger) Date: Tue, 7 Sep 2021 15:49:56 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: On 8/19/21 1:27 PM, Kevin Rushforth wrote: > Those enhancements that have reached general consensus, are far enough > along in the process that we have a good idea how much they will "cost", > and have a willing contributor and sponsor (for contributors who are not > Committers), are more likely to make JavaFX 18. I'd like to make a pitch for integrating the reproducible build support: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH https://github.com/openjdk/jfx/pull/446 It's not as glamorous as the user interface changes that have been suggested. I think the change is inevitable, though, so it would be great to have it integrated while I can still remember what I did. I've tested it in two separate rounds of tests on all three platforms, and it has been approved by two reviewers. The JDK is also doing this work, driven mostly by Magnus Ihse Bursie at Oracle in the OpenJDK Build Infrastructure Group. He calls it "a low-effort, background-style project to make the build of OpenJDK itself building reproducible." For the original motivation, see the following closed pull request that is now included in the one linked above: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH https://github.com/openjdk/jfx/pull/422 Thanks, John From kevin.rushforth at oracle.com Tue Sep 7 23:10:21 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 7 Sep 2021 16:10:21 -0700 Subject: Enhancements for JavaFX 18 In-Reply-To: References: Message-ID: <8c3d9d18-0c54-3d5f-363a-465afb298109@oracle.com> I'm on board with this, and agree that this would be a good one to move forward. -- Kevin On 9/7/2021 3:49 PM, John Neffenger wrote: > On 8/19/21 1:27 PM, Kevin Rushforth wrote: >> Those enhancements that have reached general consensus, are far >> enough along in the process that we have a good idea how much they >> will "cost", and have a willing contributor and sponsor (for >> contributors who are not Committers), are more likely to make JavaFX 18. > > I'd like to make a pitch for integrating the reproducible build support: > > 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH > https://github.com/openjdk/jfx/pull/446 > > It's not as glamorous as the user interface changes that have been > suggested. I think the change is inevitable, though, so it would be > great to have it integrated while I can still remember what I did. > I've tested it in two separate rounds of tests on all three platforms, > and it has been approved by two reviewers. > > The JDK is also doing this work, driven mostly by Magnus Ihse Bursie > at Oracle in the OpenJDK Build Infrastructure Group. He calls it "a > low-effort, background-style project to make the build of OpenJDK > itself building reproducible." > > For the original motivation, see the following closed pull request > that is now included in the one linked above: > > 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH > https://github.com/openjdk/jfx/pull/422 > > Thanks, > John From kcr at openjdk.java.net Tue Sep 7 23:27:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 23:27:06 GMT Subject: RFR: Merge jfx17 Message-ID: Merge `jfx17` into `master`. This should be the final merge since JavaFX 17 GA was today. ------------- Commit messages: - Merge jfx17 - 8273343: Create release notes for JavaFX 17 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jfx/pull/621/files Stats: 124 lines in 1 file changed: 124 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/621.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/621/head:pull/621 PR: https://git.openjdk.java.net/jfx/pull/621 From kcr at openjdk.java.net Tue Sep 7 23:33:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 23:33:36 GMT Subject: RFR: Merge jfx17 [v2] In-Reply-To: References: Message-ID: > Merge `jfx17` into `master`. This should be the final merge since JavaFX 17 GA was today. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision: - Merge jfx17 - 8269871: CellEditEvent: must not throw NPE in accessors Reviewed-by: aghaisas - 8273071: SeparatorSkin: must remove child on dispose Reviewed-by: arapte - 8269081: Tree/ListViewSkin: must remove flow on dispose Reviewed-by: arapte - 8272779: Package docs for javafx.embed.swing are misleading Reviewed-by: kcr - 8267472: JavaFX modules to include version information Reviewed-by: kcr, jvos - 8169098: [TestBug] Manual test case for JDK-8089915 Reviewed-by: kcr - 8244419: TextAreaSkin: throws UnsupportedOperation on dispose Reviewed-by: mhanl, arapte - Merge - 8272329: Cherry pick GTK WebKit 2.32.3 changes Reviewed-by: kcr, jvos - ... and 21 more: https://git.openjdk.java.net/jfx/compare/50921e19...c1f85b1b ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/621/files - new: https://git.openjdk.java.net/jfx/pull/621/files/c1f85b1b..c1f85b1b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=621&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=621&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/621.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/621/head:pull/621 PR: https://git.openjdk.java.net/jfx/pull/621 From kcr at openjdk.java.net Tue Sep 7 23:33:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Sep 2021 23:33:38 GMT Subject: Integrated: Merge jfx17 In-Reply-To: References: Message-ID: <2fqHb6ZJ8VEXNCvC1WAuiNYiytgpJwcvAa1KI7KPL4E=.e20b0b47-2e1c-4cdd-b645-aef92973fb03@github.com> On Tue, 7 Sep 2021 23:23:41 GMT, Kevin Rushforth wrote: > Merge `jfx17` into `master`. This should be the final merge since JavaFX 17 GA was today. This pull request has now been integrated. Changeset: 5552213b Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/5552213b189b5a9c5ab9362734c148118639ac47 Stats: 124 lines in 1 file changed: 124 ins; 0 del; 0 mod Merge ------------- PR: https://git.openjdk.java.net/jfx/pull/621 From aghaisas at openjdk.java.net Wed Sep 8 06:35:09 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 8 Sep 2021 06:35:09 GMT Subject: RFR: 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel [v6] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 12:41:00 GMT, Marius Hanl wrote: >> This PR fixes multiple NPEs in Choice-and ComboBox, when the selection model is null. >> >> ChoiceBox: >> - Null check in **valueProperty()** listener >> >> ComboBox: >> - Null check in **editableProperty()** listener >> - Null check in **valueProperty()** listener >> - Null check in **ComboBoxListViewSkin#updateValue()** >> - Null check in **ComboBoxListViewSkin#layoutChildren()** >> - 2x Null check in **ComboBoxListViewSkin#createListView()** >> >> ~~The tests checks, that no NPE is printed to the console. >> Some checks, that the set value is still displayed (either in the ComboBox button cell or the ChoiceBox display label)~~ > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Fixed another NPE on skin creation when the cbx selection model is null The latest patch does not apply cleanly due to the change in copyright headers. It was fixed in - [JDK-8270960](https://bugs.openjdk.java.net/browse/JDK-8270960) ------------- PR: https://git.openjdk.java.net/jfx/pull/557 From fkirmaier at openjdk.java.net Wed Sep 8 07:52:31 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 8 Sep 2021 07:52:31 GMT Subject: RFR: 8271395: Fixing crash at printing [v2] In-Reply-To: References: Message-ID: > This PR switches the Thread to the QuantumRenderer, in the case the Disposer is called from another Thread - the printing Thread. > I'm open for better solutions on how to fix this Issue. > Initially i thought there is also a Race Condition in the resource pool, but a new one is created for the Printing Thread. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8271395 QuantumRenderer is no longer public ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/618/files - new: https://git.openjdk.java.net/jfx/pull/618/files/72f9f9f1..0dc9ce1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=618&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=618&range=00-01 Stats: 27 lines in 3 files changed: 15 ins; 10 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/618.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/618/head:pull/618 PR: https://git.openjdk.java.net/jfx/pull/618 From fkirmaier at openjdk.java.net Wed Sep 8 07:52:32 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 8 Sep 2021 07:52:32 GMT Subject: RFR: 8271395: Fixing crash at printing [v2] In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 13:33:11 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8271395 >> QuantumRenderer is no longer public > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumRenderer.java line 57: > >> 55: * Quantum Renderer >> 56: */ >> 57: final public class QuantumRenderer extends ThreadPoolExecutor { > > I am not in favor of making this class public. I would rather add a method to Toolkit, and have the overridden method in QuantumToolkit call the Quantum renderer as needed. I've just updated the PR and moved it to the QuantumToolkit! ------------- PR: https://git.openjdk.java.net/jfx/pull/618 From arapte at openjdk.java.net Wed Sep 8 09:42:08 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 8 Sep 2021 09:42:08 GMT Subject: RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | looks good to me too. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/614 From fkirmaier at openjdk.java.net Wed Sep 8 10:42:17 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 8 Sep 2021 10:42:17 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac Message-ID: When using Swing it's possible to generate a Deadlock. It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. Sample Programm and Threaddump are added to the ticket. Removing the nested loop fixes the Problem. I hope this doesn't have any side effect - so far i don't know of any. ------------- Commit messages: - JDK-8273485 Changes: https://git.openjdk.java.net/jfx/pull/622/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273485 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/622.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/622/head:pull/622 PR: https://git.openjdk.java.net/jfx/pull/622 From mstrauss at openjdk.java.net Wed Sep 8 10:59:06 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Sep 2021 10:59:06 GMT Subject: Integrated: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: <2cHVlEPuyWAn71q7ilJQdMDNQWz3VE6zdphUxB5Vwxg=.57d34570-8e85-4dd2-8f27-aee1e705689c@github.com> On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strau? wrote: > This PR fixes a bug that was introduced in #454. > > Since this fix might impact the performance considerations in the original PR, I ran a performance benchmark against the previous `ChangeListener`-based implementation, which still shows better performance for the new implementation: > > > @State(Scope.Benchmark) > public class BindingBenchmark { > DoubleProperty property1 = new SimpleDoubleProperty(); > DoubleProperty property2 = new SimpleDoubleProperty(); > > public BindingBenchmark() { > property2.bindBidirectional(property1); > } > > @Benchmark > public void benchmark() { > for (int i = 0; i < 10000000; ++i) { > property1.set((i % 2 == 0) ? 12345.0 : 54321.0); > } > } > } > > > | Benchmark | Mode | Cnt | Score | Error | Units | > |-----------|------|-----|-------|-------|--------| > | ChangeListener | thrpt | 5 | 7.463 | 0.040 | ops/s | > | InvalidationListener (fixed) | thrpt | 5 | 15.095 | 0.092 | ops/s | This pull request has now been integrated. Changeset: 26d6438e Author: Michael Strau? Committer: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/26d6438ea267d703039facac7dab67175b863b46 Stats: 54 lines in 2 files changed: 54 ins; 0 del; 0 mod 8273138: BidirectionalBinding fails to observe changes of invalid properties Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/614 From kcr at openjdk.java.net Wed Sep 8 12:17:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Sep 2021 12:17:08 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 10:37:40 GMT, Florian Kirmaier wrote: > When using Swing it's possible to generate a Deadlock. > It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. > Sample Programm and Threaddump are added to the ticket. > > Removing the nested loop fixes the Problem. > I hope this doesn't have any side effect - so far i don't know of any. I am almost certain that this proposed fix will cause problems. At the very least we will now have mismatched enter / exit nested loop calls. The nested loop for full screen on Mac was done for a reason, so you will need to track down what that reason is and either verify that it is no longer needed or else solve that some other way. Also, you don't explain why removing the nested event loop is the right fix for the deadlock. Finally, once you address the above two points, you will need to turn the test program attached to the JBS bug into an automated test. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/622 From kcr at openjdk.java.net Wed Sep 8 12:24:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Sep 2021 12:24:09 GMT Subject: RFR: 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel [v6] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 06:32:06 GMT, Ajit Ghaisas wrote: > The latest patch does not apply cleanly due to the change in copyright headers. @aghaisas If you fetch the PR branch and merge master (which is what I usually do when testing a PR), git is able to auto-resolve it; this is why Skara didn't flag this PR as having a merge conflict (which it will if there is). ------------- PR: https://git.openjdk.java.net/jfx/pull/557 From kcr at openjdk.java.net Wed Sep 8 13:12:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Sep 2021 13:12:12 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v4] In-Reply-To: References: <7zOdT4itDTUHytx49g6scMXHOW4b3pWEhERb96fr_UY=.fcacf5e2-d2f6-4b67-9361-521a1166d179@github.com> <0MA1oKn0b6q1IyqzRGB8pONGvxZ6ATDrdl3zLw1TcMM=.072d4745-4944-475b-8482-e5aae62d0e81@github.com> <93SV4Qk57pLyW711Z7cxfOP6qbN6rBOfdJR_WXHiVR8=.611ad06d-f2d2-4a64-96cd-16a729b3632c@github.com> <8unV9ja2V9qK5x0KehPFcAPmtVOhBLB-70fbebNTOZU=.2892729d-aa87-4603-9acf-5a2c10619058@github.com> Message-ID: On Mon, 6 Sep 2021 11:05:42 GMT, Jose Pereda wrote: >> I don't doubt that the area should be cleared. What I was questioning is whether this was the best place to do it? I'd be OK with it if you document it. > > The two options I see so far to clear the area are the one I've committed (change in `WCGraphicsPrismContext::setClip`) and the one I've mentioned above (`WCPageBackBufferImpl::copyArea`). > After some more testing, I see that the latter doesn't work when there is full transparency, so I will discard it. > > Back to my original commit, it could be moved up to `WebPage::paint2GC`, before the call to `gc.setClip(rq.getClip());`, and that would also remove the need of passing down the opacity level to `WCGraphicsContext`. I also see now that the `clearRect()` call is required for full transparency only. > > This would be the change: > > WCRectangle clip = rq.getClip(); > if (clip != null) { > if (isBackgroundTransparent()) { > // As backbuffer is enabled, new clips are drawn over the old rendered frames > // regardless the alpha channel. While that works fine for alpha > 0, > // for alpha == 0 we need to clear the old frame or it will still be visible. > > gc.clearRect((int) clip.getX(), (int) clip.getY(), (int) clip.getWidth(), (int) clip.getHeight()); > } > gc.setClip(clip); > } This seems like the best approach to me in that it moves the clear to a drawing method rather than as a side effect of setting the clip. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Wed Sep 8 13:12:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Sep 2021 13:12:13 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v6] In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 09:28:20 GMT, Jose Pereda wrote: >> modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 97: >> >>> 95: >>> 96: private int fontSmoothingType; >>> 97: private Color backgroundColor = Color.WHITE; >> >> This might be a problem, since there are code paths that bypass `setBackgroundColor(Color)`. I might recommend storing the converted 32-bit color, and then checking that for transparency. Either that or you will need to derive a `Color` from a 32-bit int in the cases that set a 32-bit int color directly. The former is probably easier. > > In my first commit there was already a method to get the color out of the 32-bit int (which was still referred as hash value at that time): > > private static Color getColorFromHash(int hash) { > String hexString = Integer.toHexString(hash); > int length = hexString.length(); > return Color.valueOf("#" + "0".repeat(8 - length) + hexString); > } > > If we keep it in `WebPage` (renaming it accordingly to `getColorFromInt32` for instance), we could do: > > > public void setBackgroundColor(Color backgroundColor) { > setBackgroundColor(getColorInt32Value(backgroundColor)); > } > > public void setBackgroundColor(int backgroundColor) { > this.backgroundColor = getColorFromInt32(backgroundColor); > lockPage(); > ... > } > ``` > which looks a little bit ugly. > > The other option, as you mention, is finding out if the 32-bit int has alpha 0 or 1, which can be done storing only the int value, not the color, so this looks cleaner, we don't really need to hold a reference to the Color after all: > > > private int backgroundColor = -1; // Color.WHITE > > public void setBackgroundColor(Color backgroundColor) { > setBackgroundColor(getColorInt32Value(backgroundColor)); > } > > public void setBackgroundColor(int backgroundColor) { > this.backgroundColor = backgroundColor; > lockPage(); > ... > } > > private boolean isBackgroundTransparent() { > return (backgroundColor & 0x000000FF) == 0; > } > > private boolean isBackgroundOpaque() { > return (backgroundColor & 0x000000FF) == 255; > } Yes, the second approach does look cleaner, although I think the initial `backgroundColor` would be better defined as a hex constant, `0xffffffff` for clarity. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Wed Sep 8 13:12:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Sep 2021 13:12:14 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v5] In-Reply-To: References: Message-ID: On Sun, 29 Aug 2021 06:36:40 GMT, Michel Jung wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Color to int32 conversion and more changes based on feedback > > modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 629: > >> 627: try { >> 628: log.fine("setBackgroundColor int32: " + backgroundColor + >> 629: " for all frames"); > > I don't know JavaFX's PlatformLogger but this should probably be: > > Suggestion: > > log.fine("setBackgroundColor int32: {} for all frames", backgroundColor); > > or: > > Suggestion: > > if(log.isTraceEnabled()) { > log.fine("setBackgroundColor int32: {} for all frames", backgroundColor); > } > > > Even though this probably isn't something that's called very often :) Or just wrap the call in a test for `if (log.isLoggable(Level.FINE))`, which is similar to what was done earlier. In any case, this is just modifying the contents of the String and is otherwise preexisting code, so I'll leave it up to @jperedadnr as to whether he wants to change it. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Wed Sep 8 13:45:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Sep 2021 13:45:08 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell [v3] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 10:40:01 GMT, Michael Strau? wrote: >> This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed case of multi-selection across several rows The updated fix and new test both look good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/617 From aghaisas at openjdk.java.net Wed Sep 8 13:49:10 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 8 Sep 2021 13:49:10 GMT Subject: RFR: 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel [v6] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 12:20:57 GMT, Kevin Rushforth wrote: > > The latest patch does not apply cleanly due to the change in copyright headers. > > @aghaisas If you fetch the PR branch and merge master (which is what I usually do when testing a PR), git is able to auto-resolve it; this is why Skara didn't flag this PR as having a merge conflict (which it will if there is). Hmm.. interesting. I updated my master branch and then tried to apply this PR diff manually. The patch did not apply and hence I commented the same. I do see that Skara did not flag the merge conflict for this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/557 From jpereda at openjdk.java.net Wed Sep 8 13:59:08 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 8 Sep 2021 13:59:08 GMT Subject: RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell [v3] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 10:40:01 GMT, Michael Strau? wrote: >> This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed case of multi-selection across several rows Looks good to me ------------- Marked as reviewed by jpereda (Committer). PR: https://git.openjdk.java.net/jfx/pull/617 From mstrauss at openjdk.java.net Wed Sep 8 14:30:11 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 8 Sep 2021 14:30:11 GMT Subject: Integrated: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell In-Reply-To: References: Message-ID: On Fri, 3 Sep 2021 18:19:45 GMT, Michael Strau? wrote: > This PR fixes the exception thrown by the sample code in [8273324](https://bugs.openjdk.java.net/browse/JDK-8273324), while retaining the incorrect behavior in the scenario described. This pull request has now been integrated. Changeset: a272c4f6 Author: Michael Strau? Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/a272c4f6bd08fee8928c78e17428574aec485cfd Stats: 53 lines in 2 files changed: 50 ins; 0 del; 3 mod 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/617 From jpereda at openjdk.java.net Wed Sep 8 16:15:36 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 8 Sep 2021 16:15:36 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v7] In-Reply-To: References: Message-ID: > Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. > > In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. > > The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. > > Unit tests and a system test are provided. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Address feedback from reviewers ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/563/files - new: https://git.openjdk.java.net/jfx/pull/563/files/941ba714..02061b9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=05-06 Stats: 61 lines in 4 files changed: 9 ins; 35 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/563.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/563/head:pull/563 PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Wed Sep 8 22:40:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Sep 2021 22:40:10 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v7] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 16:15:36 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback from reviewers I left a few minor comments, but otherwise this all looks good to me. Once you make the one requested change to remove the paragraph break, you can also update the CSR with that change and the two other changes I requested in the CSR, and then move the CSR to proposed. modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 97: > 95: > 96: private int fontSmoothingType; > 97: private int backgroundIntRgba = 0xFFFFFFFF; Maybe add back the comment about this being Color.WHITE? modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 2589: > 2587: private static int getIntRgba(Color color) { > 2588: if (color == null) { > 2589: return -1; Maybe: `return 0xFFFFFFFF;` ? or else assign `color = Color.WHITE;` and fall through? modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 707: > 705: * level of transparency. > 706: * > 707: *

However, if the HTML content being loaded sets its own I looked at the generated javadoc and this will read better without a paragraph break. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Wed Sep 8 22:40:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 8 Sep 2021 22:40:10 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v7] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 21:10:27 GMT, Kevin Rushforth wrote: > I looked at the generated javadoc and this will read better without a paragraph break. When you remove the paragraph break, please also remove the blank line to make it clearer to future readers of the code that it is intended to be part of the same paragraph as the previous sentence. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From aghaisas at openjdk.java.net Thu Sep 9 04:36:08 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 9 Sep 2021 04:36:08 GMT Subject: RFR: 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel [v6] In-Reply-To: References: Message-ID: On Tue, 27 Jul 2021 12:41:00 GMT, Marius Hanl wrote: >> This PR fixes multiple NPEs in Choice-and ComboBox, when the selection model is null. >> >> ChoiceBox: >> - Null check in **valueProperty()** listener >> >> ComboBox: >> - Null check in **editableProperty()** listener >> - Null check in **valueProperty()** listener >> - Null check in **ComboBoxListViewSkin#updateValue()** >> - Null check in **ComboBoxListViewSkin#layoutChildren()** >> - 2x Null check in **ComboBoxListViewSkin#createListView()** >> >> ~~The tests checks, that no NPE is printed to the console. >> Some checks, that the set value is still displayed (either in the ComboBox button cell or the ChoiceBox display label)~~ > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Fixed another NPE on skin creation when the cbx selection model is null Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/557 From fkirmaier at openjdk.java.net Thu Sep 9 07:58:05 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 9 Sep 2021 07:58:05 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 10:37:40 GMT, Florian Kirmaier wrote: > When using Swing it's possible to generate a Deadlock. > It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. > Sample Programm and Threaddump are added to the ticket. > > Removing the nested loop fixes the Problem. > I hope this doesn't have any side effect - so far i don't know of any. Thank you for the feedback - I will start writing an unit test for it because it will help on all further development regarding this issue. ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From arapte at openjdk.java.net Thu Sep 9 08:19:04 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 9 Sep 2021 08:19:04 GMT Subject: RFR: 8172095: Let Node.managed become CSS-styleable [v2] In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 15:44:17 GMT, Abhinay Agarwal wrote: >> 8172095: Let Node.managed become CSS-styleable > > Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: > > - Add default value tests for setting / getting the managed property > - Replace with HTML equivalent code Changes look good to me. The tests, managedSetFromCSS() and Node_cssMethods_Test fail before and pass after. Other tests do pass both before and after, which is expected behaviour. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/602 From mhanl at openjdk.java.net Thu Sep 9 08:33:06 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 9 Sep 2021 08:33:06 GMT Subject: Integrated: 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 15:03:50 GMT, Marius Hanl wrote: > This PR fixes multiple NPEs in Choice-and ComboBox, when the selection model is null. > > ChoiceBox: > - Null check in **valueProperty()** listener > > ComboBox: > - Null check in **editableProperty()** listener > - Null check in **valueProperty()** listener > - Null check in **ComboBoxListViewSkin#updateValue()** > - Null check in **ComboBoxListViewSkin#layoutChildren()** > - 2x Null check in **ComboBoxListViewSkin#createListView()** > > ~~The tests checks, that no NPE is printed to the console. > Some checks, that the set value is still displayed (either in the ComboBox button cell or the ChoiceBox display label)~~ This pull request has now been integrated. Changeset: f987b181 Author: Marius Hanl Committer: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/f987b181aba1d3d56e745bd02fe350287ab57459 Stats: 141 lines in 5 files changed: 127 ins; 3 del; 11 mod 8089398: [ChoiceBox, ComboBox] throws NPE on setting value on null selectionModel Reviewed-by: fastegal, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/557 From jpereda at openjdk.java.net Thu Sep 9 08:47:07 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 9 Sep 2021 08:47:07 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v7] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 16:15:36 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback from reviewers I've also updated the CSR ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Thu Sep 9 08:47:08 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 9 Sep 2021 08:47:08 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v7] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 21:08:40 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Address feedback from reviewers > > modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 2589: > >> 2587: private static int getIntRgba(Color color) { >> 2588: if (color == null) { >> 2589: return -1; > > Maybe: `return 0xFFFFFFFF;` ? or else assign `color = Color.WHITE;` and fall through? Probably better then to create a constant? private static final int DEFAULT_BACKGROUND_INT_RGBA = 0xFFFFFFFF; // Color.WHITE ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Thu Sep 9 08:47:08 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 9 Sep 2021 08:47:08 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v7] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 22:37:18 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 707: >> >>> 705: * level of transparency. >>> 706: * >>> 707: *

However, if the HTML content being loaded sets its own >> >> I looked at the generated javadoc and this will read better without a paragraph break. > >> I looked at the generated javadoc and this will read better without a paragraph break. > > When you remove the paragraph break, please also remove the blank line to make it clearer to future readers of the code that it is intended to be part of the same paragraph as the previous sentence. Done ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Thu Sep 9 08:52:31 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 9 Sep 2021 08:52:31 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v8] In-Reply-To: References: Message-ID: > Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. > > In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. > > The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. > > Unit tests and a system test are provided. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Changes required per reviewer ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/563/files - new: https://git.openjdk.java.net/jfx/pull/563/files/02061b9e..90ab86d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=06-07 Stats: 5 lines in 2 files changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/563.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/563/head:pull/563 PR: https://git.openjdk.java.net/jfx/pull/563 From fastegal at openjdk.java.net Thu Sep 9 09:18:04 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 9 Sep 2021 09:18:04 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 05:15:49 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed undeterministic test failures Just curious: with this in place, would it be possible to use for supporting [JDK-8087926](https://bugs.openjdk.java.net/browse/JDK-8087926) (it's a bit vague, though, at least for me)? ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From mstrauss at openjdk.java.net Thu Sep 9 09:51:08 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 9 Sep 2021 09:51:08 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: Message-ID: <320PNI-3MULDZOUpCr5SqY5vD4PI8oWLQgC12-tcvGs=.78d56839-9046-43ab-80b6-60dc84e23e02@github.com> On Thu, 9 Sep 2021 09:15:06 GMT, Jeanette Winzenburg wrote: > Just curious: with this in place, would it be possible to use for supporting [JDK-8087926](https://bugs.openjdk.java.net/browse/JDK-8087926) (it's a bit vague, though, at least for me)? Yes, `:focus-within` can be used to select an ancestor of the currently-focused node. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From fastegal at openjdk.java.net Thu Sep 9 09:54:06 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 9 Sep 2021 09:54:06 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: <320PNI-3MULDZOUpCr5SqY5vD4PI8oWLQgC12-tcvGs=.78d56839-9046-43ab-80b6-60dc84e23e02@github.com> References: <320PNI-3MULDZOUpCr5SqY5vD4PI8oWLQgC12-tcvGs=.78d56839-9046-43ab-80b6-60dc84e23e02@github.com> Message-ID: On Thu, 9 Sep 2021 09:47:56 GMT, Michael Strau? wrote: > > > > Just curious: with this in place, would it be possible to use for supporting [JDK-8087926](https://bugs.openjdk.java.net/browse/JDK-8087926) (it's a bit vague, though, at least for me)? > > Yes, `:focus-within` can be used to select an ancestor of the currently-focused node. cool - thanks :) ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From nlisker at gmail.com Thu Sep 9 15:13:41 2021 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 9 Sep 2021 18:13:41 +0300 Subject: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18] In-Reply-To: References: <42dd7908-e2c7-1256-5102-8c721b600e1d@oracle.com> <2f6ee873-423f-a798-ce23-be3064e77273@oracle.com> Message-ID: I have updated the PR to use DoubleProperties for the pivots and added 2 BooleanProperties for the normalized coordinates toggle on Node. To the Rotate/ScaleTransitions I added only the pivot properties that update those of the node. It's a prototype, so ignore docs and other miscellania. I also posted in a comment an interactive test app. It should be simple enough to modify it for local testing. I wasn't sure if the boolean properties should also be added to the transitions. The rotation axis and pivot properties are mostly a convenience since those can be updated on the node directly. My greatest concern is the confusion that happens with transforms: I need to be very careful when mixing those in since they use a different coordinate system by default. In a way, if Node and the transitions find it more natural to use normalized coordinates, shouldn't transforms find it natural too? Not sure if this is inconvenient only for me. On Sat, Aug 28, 2021 at 2:56 AM Nir Lisker wrote: > The problem I have with additional booleans is that they are not > reflected in the transitions, and to a lesser extent in the transforms. > > I'm going to have to write an implementation and test it out to know how > well this works and how much trouble it really saves. > > And while we could use NaN as an out of band value meaning "computed", >> that still runs into the problem of allowing for the odd case where X is >> computed and Y is specified. > > > I don't see this as a problem. Each direction is independent. The bigger > problem I see is the surprise factor of NaN as a computed value. > > On Tue, Aug 24, 2021 at 6:16 PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I definitely don't like having a "magic" initial value that can't be >> reset, so that won't work. And while we could use NaN as an out of band >> value meaning "computed", that still runs into the problem of allowing for >> the odd case where X is computed and Y is specified. >> >> If we do go with the idea of allowing the coordinates to be a percentage >> of the bounding box, with 0.5 as the default, then we could be informed by >> what ImagePattern does. It defines a "proportional" property as follows: >> >> "a boolean that indicates whether start and end locations are >> proportional or absolute. If this flag is true, the two end points are >> defined in a coordinate space where coordinates in the range [0..1] are >> scaled to map onto the bounds of the shape that the pattern fills. If this >> flag is false, then the coordinates are specified in the local coordinate >> system of the node." >> >> That's basically what we are doing if we go with Michael's idea. So if we >> do this, the two boolean properties could be named something like >> scalePivotProportional and rotatePivotProportional, with a default of true. >> >> What do you think? >> >> -- Kevin >> >> >> >> On 8/23/2021 7:25 PM, Michael Strau? wrote: >> >> I think normalized coordinates are a very natural fit for the >> definition of a pivot point, which is why the current default value is >> an implicitly-specified normalized coordinate. Adding general-purpose >> coordinate transformations here feels like bringing a sledgehammer to >> crack a nut. >> >> Having a property with an automagically updated "initial" value is >> quite non-standard behavior for properties. It would appear as if the >> property was bound, yet there's no binding. That's markedly different >> from a Transition's 'from' and 'to' properties, which are standard >> properties with normal behavior. A running transition doesn't bind to >> those properties, it uses a snapshot of their values when the >> transition starts. >> >> >> On Sun, Aug 22, 2021 at 9:55 PM Nir Lisker wrote: >> >> Now I understand what you meant. However, the concept of normalized coordinates does not appear anywhere in JavaFX (at least not in these contexts). I still think that coordinate transformations should be handled via dedicated means, like coordinate system transformations are. Maybe when we work on mapped bindings (I forgot that I need to review that) this pain point will be alleviated. >> >> Kevin, what if we only set the initial value of the pivot (doesn't matter what the implementation detail is) to the center of the node for backwards compatibility, but if the developer changes it to a custom value then it's on them to compute the value again if they want to go back? The default behavior remains. >> Another relevant point is that Transitions do something similar with their from_, to_ and by_ methods. They start with Double.NaN to signal that the value should be ignored. While the developer can reset the value to NaN, it is not something that is likely to happen during, say, an interpolation or as a result of a binding. >> >> >> >> From kcr at openjdk.java.net Thu Sep 9 15:53:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 9 Sep 2021 15:53:07 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v8] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 08:52:31 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Changes required per reviewer Latest changes look good. The new test fails for me on Linux, though. I tried it both on my Ubuntu 20.04 VM and on an older Ubuntu 16.0.4 physical machine. I don't think it's just a test issue, either. When the OpenGL pipeline I get some odd looking ghosting around the text while the test is scrolling. Have you tested this on Linux? ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From wookey.dean at gmail.com Thu Sep 9 16:37:54 2021 From: wookey.dean at gmail.com (Dean Wookey) Date: Thu, 9 Sep 2021 18:37:54 +0200 Subject: [External] : Re: apps compilation fails on ubuntu 20.04 In-Reply-To: References: <8d90e44b-a774-58d0-7398-405ef433525a@oracle.com> Message-ID: I'm having the same issue on Windows. I'm not really sure what's different about my setup. Originally I thought it was failing every time, but every now and then it gets past that and successfully builds for me. After changing from JDK 15.0.2 to 16.0.2 it worked, but that's when I realised it was somewhat random. Based on this, it shouldn't be related to operating system or JDK version. I usually have more success after a clean, but not always... Dean On Fri, Aug 13, 2021 at 1:16 PM Abhinay Agarwal wrote: > The piece of code responsible for the exception is: > > for (File f : configurations.compileClasspath.files) { > // Have to rename the swt jar because it is some platform specific > name but > // for the sake of the IDEs we need to have a single stable name that > works > // on every platform > copy { > into libsDir > from f.getParentFile() > include "**/*swt*.jar" > includeEmptyDirs = false > rename ".*swt.*jar", "swt-debug\\.jar" > } > } > > From the code snippet, it looks like Gradle is being very pro-active and > complaining that this could end up with multiple jar files containing "swt" > in their name and we need to provide a duplicate strategy for it. > > > We can either provide a duplicatesStrategy or update the above to the > following: > > copy { > into libsDir > from configurations.compileClasspath.files > include "**/*swt*.jar" > includeEmptyDirs = false > rename ".*swt.*jar", "swt-debug\\.jar" > // duplicatesStrategy = DuplicatesStrategy.WARN > } > > ________________________________ > From: Kevin Rushforth > Sent: Friday, August 13, 2021 2:24 AM > To: Abhinay Agarwal ; > openjfx-dev at openjdk.java.net > Subject: Re: [External] : Re: apps compilation fails on ubuntu 20.04 > > Interesting. I wonder what it is about your environment that causes the > duplicate, since we don't see the problem in our CI builds nor in the > GitHub Actions builds. I presume you have done a clean build and still see > it? It is possible that you have some SWT classes in your classpath or > jlink'ed into your boot JDK? > > -- Kevin > > > On 8/12/2021 1:39 PM, Abhinay Agarwal wrote: > Hi Kevin, > > My local repository is up-to-date with the jfx repository. > > The failure happens while trying to copy swt-debug.jar: > > $ sh gradlew sdk > ... > > Task :swt:classes FAILED > > FAILURE: Build failed with an exception. > > * Where: > Build file '/tmp/jfx/build.gradle' line: 2677 > > * What went wrong: > Execution failed for task ':swt:classes'. > > Entry swt-debug.jar is a duplicate but no duplicate handling strategy > has been set. Please refer to > https://docs.gradle.org/7.0.1/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy > < > https://urldefense.com/v3/__https://docs.gradle.org/7.0.1/dsl/org.gradle.api.tasks.Copy.html*org.gradle.api.tasks.Copy:duplicatesStrategy__;Iw!!ACWV5N9M2RV99hQ!fkRdlKBh300gss2krEHXu3UBrH7WOoht8YhvBygI4oIQd5dXyA2dXSrcTpkY5GOP5IQU$> > for details. > > P.S. Adding a `duplicatesStrategy` to the copy task also helps with the > issue. > > --Abhinay > > ________________________________ > From: openjfx-dev openjfx-dev-retn at openjdk.java.net> on behalf of Kevin Rushforth < > kevin.rushforth at oracle.com> > Sent: Friday, August 13, 2021 1:22 AM > To: openjfx-dev at openjdk.java.net < > openjfx-dev at openjdk.java.net> > Subject: Re: apps compilation fails on ubuntu 20.04 > > I still need to catch up on my email, since I still have the original > question in my queue. > > The answer to the original query is that there is a known bug with ant > 1.10.7 [1] that will cause this error. You can either use ant 1.10.5 > (which is the one we specify in build.properties) or use ant 1.10.8. > > As for the gradle sdk problem, I've not seen any problems relating to > using gradle 7.0.1. Is your repo up to date? Specifically, you need the > following commit: > > > https://github.com/openjdk/jfx/commit/111bac4180a646662a81223bdbb56880789d5a90 > < > https://urldefense.com/v3/__https://github.com/openjdk/jfx/commit/111bac4180a646662a81223bdbb56880789d5a90__;!!ACWV5N9M2RV99hQ!fkRdlKBh300gss2krEHXu3UBrH7WOoht8YhvBygI4oIQd5dXyA2dXSrcTpkY5KEBj0BS$ > > > > -- Kevin > > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63874< > https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?id=63874__;!!ACWV5N9M2RV99hQ!fkRdlKBh300gss2krEHXu3UBrH7WOoht8YhvBygI4oIQd5dXyA2dXSrcTpkY5Bmaafi0$ > > > > > > On 8/12/2021 12:33 PM, Abhinay Agarwal wrote: > > I am on Ubuntu 20.04. Using ANT 1.10.8, "gradlew apps" works for me. > > > > However, "gradlew sdk" fails for me since we upgraded to Gradle 7.0.1. I > always switch back to Gradle 6.9 to build a local sdk. > > ________________________________ > > From: openjfx-dev openjfx-dev-retn at openjdk.java.net> on behalf of Thiago Milczarek Say?o < > thiago.sayao at gmail.com> > > Sent: Friday, August 6, 2021 8:05 AM > > To: openjfx-dev at openjdk.java.net < > openjfx-dev at openjdk.java.net> > > Subject: apps compilation fails on ubuntu 20.04 > > > > Hi > > > > Does anyone knows how to get *gradlew apps* working on ubuntu 20.04? > > > > I have: > > Apache Ant(TM) version 1.10.7 compiled on October 24 2019 > > openjdk version "16.0.1" 2021-04-20 > > > > I want to run the test apps. > > > > -do-compile: > > [javac] Compiling 143 source files to > > /home/tsayao/IdeaProjects/jfx/apps/samples/3DViewer/build/classes > > [javac] error: invalid flag: > > @/home/tsayao/IdeaProjects/jfx/build/compile.args > > [javac] Usage: javac > > [javac] use --help for a list of possible options > > > > Thanks. > > > From jpereda at openjdk.java.net Thu Sep 9 17:28:08 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 9 Sep 2021 17:28:08 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v8] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 08:52:31 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Changes required per reviewer Yes, I have been testing on MacOS (11.5.1), Linux (Ubuntu 20.04) and Windows (10) with a manual test. I do a quick visual test with transparent, translucent and solid color, including scrolling and selecting some text. However, the `PageFillTest` system test (which was actually based on this manual test) involves also taking snapshots and pixel comparison. On MacOS it works fine. On Linux I see this "ghosting" while scrolling, but snapshots are taken on a steady position, and it shouldn't be there. What assertion fails for you? ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From nlisker at openjdk.java.net Thu Sep 9 23:00:04 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 9 Sep 2021 23:00:04 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: <4jwwsPx1DVeTlLIsTSke_SZlMdkzdHEZgWyYz4iaQHg=.e809373a-94dd-4274-888f-0d7b7cf84e3a@github.com> Message-ID: On Fri, 3 Sep 2021 21:08:27 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 366: >> >>> 364: */ >>> 365: public static Background fill(Paint fill) { >>> 366: return new Background(new BackgroundFill(fill, null, null)); >> >> null **CornerRaddii** and null **Insets** will use **CornerRadii.EMPTY** and **Insets.EMPTY**. Maybe we should use those here instead so it's more clear for anyone having a look in the source code? I also always use those instead of null. >> Same for **BorderStroke** > > Are you talking about the implementation or the code? I guess both, since the `@implSepc` indicates what this call is equivalent to. I don't have a strong opinion on this one. You don't need to look at the source code, I can link to the delegated constructor and the docs will show those. I prefer using `null`s because the point of these is that you want a border/background with 1 color and you don't care about things like widths, insets and corners - they default to whatever the default is. If you care what they are, this method is probably not what you're looking for. It's also shorter and less to read through when the extra info is defaults. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From nlisker at openjdk.java.net Thu Sep 9 23:27:03 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 9 Sep 2021 23:27:03 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v2] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 06:31:18 GMT, Ambarish Rapte wrote: >> Since the `Background` constructors take a list of `Paint` objects, I think saying a "single" `{@code Paint}` is helpful. I can see how adding "for `BackgroundFill`" (or maybe "as a `BackgroundFill`"?) might make it clearer. > > Sound good to me, It would read like `A convenience factory method for creating a Background by specifying a single {@code Paint} as a BackgroundFill` Does mentioning `BackgroundFill` in the description contribute something? The `@implSpec` tag gives that info. In my eyes, if the docs say the background will use a single `Paint` then I know exactly what I'm going to get regardless of what it uses in the implementation. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From nlisker at openjdk.java.net Thu Sep 9 23:43:29 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 9 Sep 2021 23:43:29 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: > Added convenience factory factory methods for Background and Border. Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: - Removed whitespaces - Added tests and doc updates ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/610/files - new: https://git.openjdk.java.net/jfx/pull/610/files/bb54859e..345d759f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=610&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=610&range=01-02 Stats: 28 lines in 4 files changed: 20 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/610.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/610/head:pull/610 PR: https://git.openjdk.java.net/jfx/pull/610 From nlisker at openjdk.java.net Fri Sep 10 00:01:05 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 10 Sep 2021 00:01:05 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: <_K5xEsHymJdCUrHsaXzHHxi2BovcXp5oamcDQ0zIZLg=.57517db0-e30f-4866-beed-b6f1dbb1420b@github.com> On Thu, 9 Sep 2021 23:43:29 GMT, Nir Lisker wrote: >> Added convenience factory factory methods for Background and Border. > > Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: > > - Removed whitespaces > - Added tests and doc updates Added a couple of simple tests. My approach to the documentation here is that these are the simplest ways to create a border (background) where you provide only 1 color/gradient and not care about the rest, and what you are going to get is rather obvious. If you want to see what the implementation does and what all the defaults are, the `@implSpec` section has a link that you can follow. I prefer not to start giving these details since they end up taking more attention than those few important details of what the method does. When I tried to expand upon the behavior of the method it quickly became "noise", with details I didn't care for. If people insist I will add them, but think about: is what you get not what you expected to get with the current docs? What surprised you or what were you not sure about? ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From github.com+69410606+rationalityfrontline at openjdk.java.net Fri Sep 10 10:34:07 2021 From: github.com+69410606+rationalityfrontline at openjdk.java.net (RationalityFrontline) Date: Fri, 10 Sep 2021 10:34:07 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v6] In-Reply-To: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> References: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> Message-ID: On Mon, 12 Apr 2021 08:40:56 GMT, Ambarish Rapte wrote: >> The method `ControlAcceleratorSupport.doAcceleratorInstall(final List items, final Scene scene)` adds a `ChangeListener` on `MenuItem.acceleratorProperty()`. This listener is not removed when the MenuItem is removed from scenegraph. >> Adding and removing a MenuItem results in multiple copies of the listener added to MenuItem.acceleratorProperty(). >> >> Fix is to remove the listener when MenuItem is removed. >> Fix can be verified by checking the number of instances of `ControlAcceleratorSupport.lambda` using _jvisualvm_. >> Without this fix, the number of `ControlAcceleratorSupport.lambda` increase in multiple of number of MenuItems being removed and added back. >> With fix, the count is always same as number of MenuItems in scenegraph. >> >> Also there is another ListChangeListener added to a `ObservableList items` in the method `ControlAcceleratorSupport.doAcceleratorInstall(final ObservableList items, final Scene scene)`. There was a TODO note to remove this listener. >> This listener is added on `MenuBarButton.getItems()` and not on `Menu.getItems()`. This `MenuBarButton` is created by `MenuBarSkin` to show a `Menu`. This `MenuBarButton` gets disposed when the related `Menu` is removed from scenegraph, and so the added `ListChangeListener` gets GCed. Hence it is not required to explicitly remove the listener. >> Added a comment explaining this behavior in place of the TODO. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > remove indirect test After updating to jfx 17, I detected memory leak in my application (every controller that has menu items won't get garbage collected after closing its stage), with visualvm I found it was caused by class ControlAcceleratorSupport. This kind of memory leak doesn't happen on jfx 16, so I guess there is something wrong with this PR. I've created a sample project that could reproduce and verify the memory leak: [jfx-test](https://github.com/RationalityFrontline/jfx-test/tree/ControlAcceleratorSupport) (on git branch ControlAcceleratorSupport). Run command `gradlew run` and you should see the following ui interface: ![image](https://user-images.githubusercontent.com/69410606/132838128-ac5a3883-2170-441f-b926-37bde77751b0.png) Clicking button `Call GC and Print MenuItems` will call `System.gc()` and print current ungarbaged menu items to console, clicking menu `Restart Stage` will call `Stage.close()` and launch a new same Stage. After clicking `Restart Stage` several times, click `Call GC and Print MenuItems`, you will see lots of ungarbaged menu items. However, by changing jfx version to 16 in `build.gradle.kts`, you will always see only one menu item. If menu items are set with action listeners, then these listeners also won't be garbage collected, typically these listeners hold references to controllers, which made all closed controllers leaked. This made jfx 17 unusable. ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From clemens.lanthaler at itarchitects.at Fri Sep 10 10:47:54 2021 From: clemens.lanthaler at itarchitects.at (Clemens Lanthaler) Date: Fri, 10 Sep 2021 12:47:54 +0200 Subject: Javafx 17 and moditect no longer working Message-ID: <31797649-98cb-21ae-efe6-1d851db61250@itarchitects.at> Hello everyone, I have just updated from javafx 17-ea+14 to the GA release and I am not able to build one of my projects (PhotoSlide, librawFX, JeditFX, ...) anymore. The root cause is that via maven the it downloads for each component two files (e.g. javafx-base.jar nad javafx-base-mac.jar). The first one contains only the MANIFEST file and nothing more. The problem I have is that until ea+14 the MANIFEST file contained to automatic-module-name and therefore moditect or similar tools can pick this name up. Now the automatic module name is missing in this MANIFEST file and therefore moditect is no finding any module naming anymore and try to use the file name instatt. The problem is that this results in a module name "javafx.base" which is also defined in module-info.class inside of javafx-base-mac.jar. In this case moditect cannot proceed because of duplicate items. Question from my side: Why is this extra jar file necessary ? If it is necessary is there a possability to get back the automatic-module-nam entry in the MANIFEST file ? cheers, Clemens -- ITArchitects CEO: B.Sc. Clemens Lanthaler Forchachstrasse 3 A-6166 Fulpmes Tel.: +43 (0)650 855 2954 email: office at itarchitects.at homepage: http://www.itarchitects.at ------------------------------------------------- Notice: This e-mail and any attachments are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem System und veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. From mhanl at openjdk.java.net Fri Sep 10 11:31:03 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 10 Sep 2021 11:31:03 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v6] In-Reply-To: References: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> Message-ID: <_F481AYKwZD0C3BKdUiuKIIAv445wQu-nCRGhNlNsFQ=.c2d065d0-d6d8-462e-adc3-c5986ba0d95b@github.com> On Fri, 10 Sep 2021 10:30:07 GMT, RationalityFrontline wrote: > After updating to jfx 17, I detected memory leak in my application (every controller that has menu items won't get garbage collected after closing its stage), with visualvm I found it was caused by class ControlAcceleratorSupport. This kind of memory leak doesn't happen on jfx 16, so I guess there is something wrong with this PR. > > I've created a sample project that could reproduce and verify the memory leak: [jfx-test](https://github.com/RationalityFrontline/jfx-test/tree/ControlAcceleratorSupport) (on git branch ControlAcceleratorSupport). > > Run command `gradlew run` and you should see the following ui interface: > ![image](https://user-images.githubusercontent.com/69410606/132838128-ac5a3883-2170-441f-b926-37bde77751b0.png) > > Clicking button `Call GC and Print MenuItems` will call `System.gc()` and print current ungarbaged menu items to console, clicking menu `Restart Stage` will call `Stage.close()` and launch a new same Stage. > > After clicking `Restart Stage` several times, click `Call GC and Print MenuItems`, you will see lots of ungarbaged menu items. However, by changing jfx version to 16 in `build.gradle.kts`, you will always see only one menu item. > > If menu items are set with action listeners, then these listeners also won't be garbage collected, typically these listeners hold references to controllers, which made all closed controllers leaked. This made jfx 17 unusable. Could you please report the bug at https://bugreport.java.com/ with a minimum reproducible example (written in Java)? ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From kcr at openjdk.java.net Fri Sep 10 11:38:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Sep 2021 11:38:15 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v6] In-Reply-To: <_F481AYKwZD0C3BKdUiuKIIAv445wQu-nCRGhNlNsFQ=.c2d065d0-d6d8-462e-adc3-c5986ba0d95b@github.com> References: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> <_F481AYKwZD0C3BKdUiuKIIAv445wQu-nCRGhNlNsFQ=.c2d065d0-d6d8-462e-adc3-c5986ba0d95b@github.com> Message-ID: On Fri, 10 Sep 2021 11:28:25 GMT, Marius Hanl wrote: > Could you please report the bug at https://bugreport.java.com/ with a minimum reproducible example (written in Java)? I was just going to mention the same thing. See the project [README](https://github.com/openjdk/jfx#readme). ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From fastegal at openjdk.java.net Fri Sep 10 11:45:02 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 10 Sep 2021 11:45:02 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit In-Reply-To: References: Message-ID: <7ZdkqrOMPRdJ5gk4X3QqSzHr8UdsR5ZnTVHCTIm3LQc=.4b38cac5-6190-461f-b0f5-32b141f81293@github.com> On Thu, 22 Jul 2021 19:15:54 GMT, Marius Hanl wrote: >>> > just checked my notes (there's a cell-editing branch in my fork where I'm experimenting) - astonishingly the answer is no, could not see anything :) And actually, seems like we don't even need to return immediately: would have expected some unhealthy side-effects on doing the switching into visual editing state more than once, but couldn't detect anything. You might try, though :) >>> >>> Okay. Question is, should we guard against a double edit? There is already one in `TreeTableCell#startEdit`, but probably forgotten in TableCell. I think it makes sense and as there is already the check in TreeTableCell, there was at least a thought of it somewhere in the past. >> >> good question, next question ;) >> >> - the oversight in startEdit of the base List/TableCell is not part of this (covered and soon fixed by [JDK-8188027](https://bugs.openjdk.java.net/browse/JDK-8188027), the concrete misbehavior is that they fire multiple edit events >> - as to the "real" editing cell types (that is those that actually have an editingComponent) - we (that is now you *grin) should try hard to find a scenario where multiple starts (== multiple configuration passes of the editingComponent) might hurt. Like when the user already typed something and for some reason startEdit is called again, the configuration would delete the input. >> >> > If there is nothing left, should I create a ticket for `startEdit` and for `cancelEdit` (this only affects the sub classes) ? :) >> >> hmm - not sure I understand what you are asking: startEdit is covered, and cancelEdit would be similar - either you find a scenario where multiple un-configure of the cell (after cancel) would hurt or not? > >> > > just checked my notes (there's a cell-editing branch in my fork where I'm experimenting) - astonishingly the answer is no, could not see anything :) And actually, seems like we don't even need to return immediately: would have expected some unhealthy side-effects on doing the switching into visual editing state more than once, but couldn't detect anything. You might try, though :) >> > >> > >> > Okay. Question is, should we guard against a double edit? There is already one in `TreeTableCell#startEdit`, but probably forgotten in TableCell. I think it makes sense and as there is already the check in TreeTableCell, there was at least a thought of it somewhere in the past. >> >> good question, next question ;) >> >> * the oversight in startEdit of the base List/TableCell is not part of this (covered and soon fixed by [JDK-8188027](https://bugs.openjdk.java.net/browse/JDK-8188027), the concrete misbehavior is that they fire multiple edit events >> * as to the "real" editing cell types (that is those that actually have an editingComponent) - we (that is now you *grin) should try hard to find a scenario where multiple starts (== multiple configuration passes of the editingComponent) might hurt. Like when the user already typed something and for some reason startEdit is called again, the configuration would delete the input. >> >> > If there is nothing left, should I create a ticket for `startEdit` and for `cancelEdit` (this only affects the sub classes) ? :) >> >> hmm - not sure I understand what you are asking: startEdit is covered, and cancelEdit would be similar - either you find a scenario where multiple un-configure of the cell (after cancel) would hurt or not? > > Finally coming back to this, when firing a **startEdit()** while already editing e.g. a TextFieldCell, the input which was made by you gets lost and you need to start over. So this can be a potential follow-up. I didn't found anything for **cancelEdit()**. @Maran23 wondering why my review comments aren't addressed? Anything unclear? ------------- PR: https://git.openjdk.java.net/jfx/pull/569 From daniel.peintner at gmail.com Fri Sep 10 12:14:41 2021 From: daniel.peintner at gmail.com (Daniel Peintner) Date: Fri, 10 Sep 2021 14:14:41 +0200 Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v6] In-Reply-To: References: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> <_F481AYKwZD0C3BKdUiuKIIAv445wQu-nCRGhNlNsFQ=.c2d065d0-d6d8-462e-adc3-c5986ba0d95b@github.com> Message-ID: Hi, I don't wanna clutter the list but I noticed this issue also and can point you to a simple test (adding MenuButton is sufficient, no need for any MenuItem). See test here: https://github.com/Sandec/JMemoryBuddy/issues/5#issuecomment-911617849 The test provided fails on JavaFX (v17) and succeeds on v16. @FlorianKirmaier mentioned that for him the test on Mac works also for JavaFX17. Maybe it depends on the operating system also... Note: The test should be usable "as is" since it uses JMemoryBuddy which is already part of the JFX repo. (some minor tweaks might be necessary due to the minor assert differences in Junit4 vs. Junit5) Hope this helps, -- Daniel On Fri, Sep 10, 2021 at 1:40 PM Kevin Rushforth wrote: > On Fri, 10 Sep 2021 11:28:25 GMT, Marius Hanl wrote: > > > Could you please report the bug at https://bugreport.java.com/ with a > minimum reproducible example (written in Java)? > > I was just going to mention the same thing. See the project [README]( > https://github.com/openjdk/jfx#readme). > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/429 > From youngty1997 at gmail.com Fri Sep 10 13:00:43 2021 From: youngty1997 at gmail.com (Ty Young) Date: Fri, 10 Sep 2021 08:00:43 -0500 Subject: Javafx 17 and moditect no longer working In-Reply-To: <31797649-98cb-21ae-efe6-1d851db61250@itarchitects.at> References: <31797649-98cb-21ae-efe6-1d851db61250@itarchitects.at> Message-ID: <7a53b260-9ebe-2ae1-f90f-7e76a145fd61@gmail.com> My application also does not work with 17. The module-info.java spits out random duplicate module reading errors and JavaFX classes can't be found at compile time. On 9/10/21 5:47 AM, Clemens Lanthaler wrote: > Hello everyone, > > I have just updated from javafx 17-ea+14 to the GA release and I am > not able to build one of my projects (PhotoSlide, librawFX, JeditFX, > ...) anymore. The root cause is that via maven the it downloads for > each component two files (e.g. javafx-base.jar nad > javafx-base-mac.jar). The first one contains only the MANIFEST file > and nothing more. The problem I have is that until ea+14 the MANIFEST > file contained to automatic-module-name and therefore moditect or > similar tools can pick this name up. Now the automatic module name is > missing in this MANIFEST file and therefore moditect is no finding any > module naming anymore and try to use the file name instatt. The > problem is that this results in a module name "javafx.base" which is > also defined in module-info.class inside of javafx-base-mac.jar. In > this case moditect cannot proceed because of duplicate items. > > Question from my side: Why is this extra jar file necessary ? If it is > necessary is there a possability to get back the automatic-module-nam > entry in the MANIFEST file ? > > cheers, > Clemens > From abhinay_agarwal at live.com Fri Sep 10 13:07:56 2021 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 10 Sep 2021 13:07:56 +0000 Subject: Java 17 Maven Artifacts Message-ID: JavaFX 17 Maven artifacts currently fail to compile modular JavaFX application. The non-modular application still work. To explain what's going on, let have a look at JavaFX and its Maven distribution since version 11: 1. JavaFX is distributed in non-platform (empty) and platform specific artifacts 2. These artifacts along with the JavaFX plugins have helped developers to use JavaFX in platform agnostic way 3. Platform jars have the `module-info.java` file, whereas, `Automatic-Module-Name` was present in the empty jar's MANIFEST.MF. 4. However, using `maven-jlink-plugin` with a JavaFX application fails since Automatic modules are not supported in JLink [1] 5. After a brief discussion, it was decided to remove the Automatic Module Name from non-platform jars [2] The EA releases were working perfectly after the change was made. However, with recent JavaFX 17, modular applications are failing to compile with Maven. The reason behind this lies in the `plexus-java` library used by `maven-compiler-plugin`: 1. `plexus-java` doesn't allow duplicate entries with same module-name on module-path 2. For 17, `plexus-java` resolves both empty and platform jar to have the same module-name 3. However, with `-ea+xx`, `plexus-java` resolves the module name for empty jar as null and we never discovered the bug until 17 was released 17 --- /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17.jar Module Name: javafx.controls /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17-linux.jar Module Name: javafx.controls 17-ea+18 -------- /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18.jar Module Name: null /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18-linux.jar Module Name: javafx.controls ----X---- This whole experience has made us realised we need to rethink how we package JavaFX Maven artifacts. We are still discussing about the approach and naming, and would like to gather feedback: 1. Instead of 1 module per component, we will have 2 modules (javafx.base.api and javafx.base.platform) 2. The `javafx.base.api`, unlike empty jar, will contain all generic Java code 3. The `javafx.base.platform` will contain platform-specific native + Java code 4. Current application declare their module-descriptor as: ``` module app { requires javafx.base; } ``` 5. In future this may be changed depending on how we end up wiring these modules together: ``` module app { requires javafx.base [.api or .platform]; } ``` [1] https://www.mail-archive.com/dev at maven.apache.org/msg123978.html [2] https://bugs.openjdk.java.net/browse/JDK-8264998 From github.com+69410606+rationalityfrontline at openjdk.java.net Fri Sep 10 13:08:14 2021 From: github.com+69410606+rationalityfrontline at openjdk.java.net (RationalityFrontline) Date: Fri, 10 Sep 2021 13:08:14 GMT Subject: RFR: 8208088: Memory Leak in ControlAcceleratorSupport [v6] In-Reply-To: <_F481AYKwZD0C3BKdUiuKIIAv445wQu-nCRGhNlNsFQ=.c2d065d0-d6d8-462e-adc3-c5986ba0d95b@github.com> References: <49-AIzsdm0rbCixYd3b95nS1g0ygX-VlKQvYJZGrN2M=.f3aa0402-4893-43ad-bb03-c2ed8268a70d@github.com> <_F481AYKwZD0C3BKdUiuKIIAv445wQu-nCRGhNlNsFQ=.c2d065d0-d6d8-462e-adc3-c5986ba0d95b@github.com> Message-ID: On Fri, 10 Sep 2021 11:28:25 GMT, Marius Hanl wrote: >> After updating to jfx 17, I detected memory leak in my application (every controller that has menu items won't get garbage collected after closing its stage), with visualvm I found it was caused by class ControlAcceleratorSupport. This kind of memory leak doesn't happen on jfx 16, so I guess there is something wrong with this PR. >> >> I've created a sample project that could reproduce and verify the memory leak: [jfx-test](https://github.com/RationalityFrontline/jfx-test/tree/ControlAcceleratorSupport) (on git branch ControlAcceleratorSupport). >> >> Run command `gradlew run` and you should see the following ui interface: >> ![image](https://user-images.githubusercontent.com/69410606/132838128-ac5a3883-2170-441f-b926-37bde77751b0.png) >> >> Clicking button `Call GC and Print MenuItems` will call `System.gc()` and print current ungarbaged menu items to console, clicking menu `Restart Stage` will call `Stage.close()` and launch a new same Stage. >> >> After clicking `Restart Stage` several times, click `Call GC and Print MenuItems`, you will see lots of ungarbaged menu items. However, by changing jfx version to 16 in `build.gradle.kts`, you will always see only one menu item. >> >> If menu items are set with action listeners, then these listeners also won't be garbage collected, typically these listeners hold references to controllers, which made all closed controllers leaked. This made jfx 17 unusable. > >> After updating to jfx 17, I detected memory leak in my application (every controller that has menu items won't get garbage collected after closing its stage), with visualvm I found it was caused by class ControlAcceleratorSupport. This kind of memory leak doesn't happen on jfx 16, so I guess there is something wrong with this PR. >> >> I've created a sample project that could reproduce and verify the memory leak: [jfx-test](https://github.com/RationalityFrontline/jfx-test/tree/ControlAcceleratorSupport) (on git branch ControlAcceleratorSupport). >> >> Run command `gradlew run` and you should see the following ui interface: >> ![image](https://user-images.githubusercontent.com/69410606/132838128-ac5a3883-2170-441f-b926-37bde77751b0.png) >> >> Clicking button `Call GC and Print MenuItems` will call `System.gc()` and print current ungarbaged menu items to console, clicking menu `Restart Stage` will call `Stage.close()` and launch a new same Stage. >> >> After clicking `Restart Stage` several times, click `Call GC and Print MenuItems`, you will see lots of ungarbaged menu items. However, by changing jfx version to 16 in `build.gradle.kts`, you will always see only one menu item. >> >> If menu items are set with action listeners, then these listeners also won't be garbage collected, typically these listeners hold references to controllers, which made all closed controllers leaked. This made jfx 17 unusable. > > Could you please report the bug at https://bugreport.java.com/ with a minimum reproducible example (written in Java)? @Maran23 @kevinrushforth Bug reported via https://bugreport.java.com/bugreport/ with a minimum reproducible example written in Java, internal review ID : 9071415. ------------- PR: https://git.openjdk.java.net/jfx/pull/429 From abhinay_agarwal at live.com Fri Sep 10 13:10:25 2021 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 10 Sep 2021 13:10:25 +0000 Subject: JavaFX 17 Maven Artifacts Message-ID: JavaFX 17 Maven artifacts currently fail to compile modular JavaFX application. The non-modular application still works. To explain what's going on, let have a look at JavaFX and its Maven distribution since version 11: 1. JavaFX is distributed in non-platform (empty) and platform specific artifacts 2. These artifacts along with the javafx plugins have helped developers to use JavaFX in platform agnostic way 3. Platform jars have the `module-info.java` file, whereas, `Automatic-Module-Name` was present in the empty jar's MANIFEST.MF. 4. However, using `maven-jlink-plugin` with a JavaFX application fails since Automatic modules are not supported in JLink [1] 5. After a brief discussion, it was decided to remove the Automatic Module Name from non-platform jars [2] The EA releases were working perfectly after the change was made. However, with recent JavaFX 17, modular applications are failing to compile with Maven. The reason behind this lies in the `plexus-java` library used by `maven-compiler-plugin`: 1. `plexus-java` doesn't allow duplicate entries with same module-name on module-path 2. For 17, `plexus-java` resolves both empty and platform jar to have the same module-name 3. However, with `-ea+xx`, `plexus-java` resolves the module name for empty jar as null and we never discovered the bug until 17 was released 17 --- /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17.jar org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c1c939a0 Module Name: javafx.controls /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17-linux.jar org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at 31c3da0e Module Name: javafx.controls 17-ea+18 -------- /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18.jar Module Name: null /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18-linux.jar org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c896ba80 Module Name: javafx.controls ----X---- This whole experience has made us realised we need to rethink how we package JavaFX Maven artifacts. We are still discussing about the approach and naming, but we are throwing it out in the open to gather feedback: 1. Instead of 1 module per component, we will have 2 modules (javafx.base.api and javafx.base.platform) 2. The `javafx.base.api`, unlike empty jar, will contain all generic Java code 3. The `javafx.base.platform` will contain platform-specific native + Java code 4. Current application declare their module-descriptor as: ``` module app { requires javafx.base; } ``` 5. In future this may be changed depending on how we end up wiring these modules together: ``` module app { requires javafx.base [.api or .platform]; } ``` [1] https://www.mail-archive.com/dev at maven.apache.org/msg123978.html [2] https://bugs.openjdk.java.net/browse/JDK-8264998 From clemens.lanthaler at itarchitects.at Fri Sep 10 13:16:36 2021 From: clemens.lanthaler at itarchitects.at (clemens.lanthaler at itarchitects.at) Date: Fri, 10 Sep 2021 15:16:36 +0200 Subject: JavaFX 17 Maven Artifacts In-Reply-To: References: Message-ID: Thanks allot for the detailed explanation! Than I wait until a final solution will be available. My plan was to upgrade all projects after the jdk 17 release to the newest javafx version. > On 10. Sep 2021, at 15:11, Abhinay Agarwal wrote: > > ?JavaFX 17 Maven artifacts currently fail to compile modular JavaFX application. The non-modular application still works. > > To explain what's going on, let have a look at JavaFX and its Maven distribution since version 11: > > 1. JavaFX is distributed in non-platform (empty) and platform specific artifacts > 2. These artifacts along with the javafx plugins have helped developers to use JavaFX in platform agnostic way > 3. Platform jars have the `module-info.java` file, whereas, `Automatic-Module-Name` was present in the empty jar's MANIFEST.MF. > 4. However, using `maven-jlink-plugin` with a JavaFX application fails since Automatic modules are not supported in JLink [1] > 5. After a brief discussion, it was decided to remove the Automatic Module Name from non-platform jars [2] > > The EA releases were working perfectly after the change was made. However, with recent JavaFX 17, modular applications are failing to compile with Maven. > > The reason behind this lies in the `plexus-java` library used by `maven-compiler-plugin`: > > 1. `plexus-java` doesn't allow duplicate entries with same module-name on module-path > 2. For 17, `plexus-java` resolves both empty and platform jar to have the same module-name > 3. However, with `-ea+xx`, `plexus-java` resolves the module name for empty jar as null and we never discovered the bug until 17 was released > > 17 > --- > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17.jar > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c1c939a0 > Module Name: javafx.controls > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17-linux.jar > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at 31c3da0e > Module Name: javafx.controls > > 17-ea+18 > -------- > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18.jar > Module Name: null > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18-linux.jar > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c896ba80 > Module Name: javafx.controls > > ----X---- > > This whole experience has made us realised we need to rethink how we package JavaFX Maven artifacts. > We are still discussing about the approach and naming, but we are throwing it out in the open to gather feedback: > > 1. Instead of 1 module per component, we will have 2 modules (javafx.base.api and javafx.base.platform) > 2. The `javafx.base.api`, unlike empty jar, will contain all generic Java code > 3. The `javafx.base.platform` will contain platform-specific native + Java code > 4. Current application declare their module-descriptor as: > > ``` > module app { > requires javafx.base; > } > ``` > > 5. In future this may be changed depending on how we end up wiring these modules together: > > ``` > module app { > requires javafx.base [.api or .platform]; > } > ``` > > > [1] https://www.mail-archive.com/dev at maven.apache.org/msg123978.html > [2] https://bugs.openjdk.java.net/browse/JDK-8264998 From abhinay_agarwal at live.com Fri Sep 10 13:18:04 2021 From: abhinay_agarwal at live.com (Abhinay Agarwal) Date: Fri, 10 Sep 2021 13:18:04 +0000 Subject: JavaFX 17 Maven Artifacts In-Reply-To: References: Message-ID: Hi Clemens, If you have any thoughts/suggestions, please let us know. -Abhinay ________________________________ From: clemens.lanthaler at itarchitects.at Sent: Friday, September 10, 2021 6:46 PM To: Abhinay Agarwal Cc: openjfx-dev at openjdk.java.net Subject: Re: JavaFX 17 Maven Artifacts Thanks allot for the detailed explanation! Than I wait until a final solution will be available. My plan was to upgrade all projects after the jdk 17 release to the newest javafx version. > On 10. Sep 2021, at 15:11, Abhinay Agarwal wrote: > > ?JavaFX 17 Maven artifacts currently fail to compile modular JavaFX application. The non-modular application still works. > > To explain what's going on, let have a look at JavaFX and its Maven distribution since version 11: > > 1. JavaFX is distributed in non-platform (empty) and platform specific artifacts > 2. These artifacts along with the javafx plugins have helped developers to use JavaFX in platform agnostic way > 3. Platform jars have the `module-info.java` file, whereas, `Automatic-Module-Name` was present in the empty jar's MANIFEST.MF. > 4. However, using `maven-jlink-plugin` with a JavaFX application fails since Automatic modules are not supported in JLink [1] > 5. After a brief discussion, it was decided to remove the Automatic Module Name from non-platform jars [2] > > The EA releases were working perfectly after the change was made. However, with recent JavaFX 17, modular applications are failing to compile with Maven. > > The reason behind this lies in the `plexus-java` library used by `maven-compiler-plugin`: > > 1. `plexus-java` doesn't allow duplicate entries with same module-name on module-path > 2. For 17, `plexus-java` resolves both empty and platform jar to have the same module-name > 3. However, with `-ea+xx`, `plexus-java` resolves the module name for empty jar as null and we never discovered the bug until 17 was released > > 17 > --- > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17.jar > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c1c939a0 > Module Name: javafx.controls > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17-linux.jar > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at 31c3da0e > Module Name: javafx.controls > > 17-ea+18 > -------- > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18.jar > Module Name: null > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18-linux.jar > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c896ba80 > Module Name: javafx.controls > > ----X---- > > This whole experience has made us realised we need to rethink how we package JavaFX Maven artifacts. > We are still discussing about the approach and naming, but we are throwing it out in the open to gather feedback: > > 1. Instead of 1 module per component, we will have 2 modules (javafx.base.api and javafx.base.platform) > 2. The `javafx.base.api`, unlike empty jar, will contain all generic Java code > 3. The `javafx.base.platform` will contain platform-specific native + Java code > 4. Current application declare their module-descriptor as: > > ``` > module app { > requires javafx.base; > } > ``` > > 5. In future this may be changed depending on how we end up wiring these modules together: > > ``` > module app { > requires javafx.base [.api or .platform]; > } > ``` > > > [1] https://www.mail-archive.com/dev at maven.apache.org/msg123978.html > [2] https://bugs.openjdk.java.net/browse/JDK-8264998 From clemens.lanthaler at itarchitects.at Fri Sep 10 13:45:00 2021 From: clemens.lanthaler at itarchitects.at (clemens.lanthaler at itarchitects.at) Date: Fri, 10 Sep 2021 15:45:00 +0200 Subject: JavaFX 17 Maven Artifacts In-Reply-To: References: Message-ID: <07EE1778-4794-460D-A910-8D352D56F2F9@itarchitects.at> Hi Abhinay, The curios thing is that if the automatic module name is present all is working fine at least with jdeps and therefore with moditect . A short fix would be to bring the entry from 17ea+14 back into the manifest file until the your described end solution will be implemented. Cheers Clemens > On 10. Sep 2021, at 15:18, Abhinay Agarwal wrote: > > ? > Hi Clemens, > > If you have any thoughts/suggestions, please let us know. > > -Abhinay > From: clemens.lanthaler at itarchitects.at > Sent: Friday, September 10, 2021 6:46 PM > To: Abhinay Agarwal > Cc: openjfx-dev at openjdk.java.net > Subject: Re: JavaFX 17 Maven Artifacts > > Thanks allot for the detailed explanation! > > Than I wait until a final solution will be available. My plan was to upgrade all projects after the jdk 17 release to the newest javafx version. > > > On 10. Sep 2021, at 15:11, Abhinay Agarwal wrote: > > > > ?JavaFX 17 Maven artifacts currently fail to compile modular JavaFX application. The non-modular application still works. > > > > To explain what's going on, let have a look at JavaFX and its Maven distribution since version 11: > > > > 1. JavaFX is distributed in non-platform (empty) and platform specific artifacts > > 2. These artifacts along with the javafx plugins have helped developers to use JavaFX in platform agnostic way > > 3. Platform jars have the `module-info.java` file, whereas, `Automatic-Module-Name` was present in the empty jar's MANIFEST.MF. > > 4. However, using `maven-jlink-plugin` with a JavaFX application fails since Automatic modules are not supported in JLink [1] > > 5. After a brief discussion, it was decided to remove the Automatic Module Name from non-platform jars [2] > > > > The EA releases were working perfectly after the change was made. However, with recent JavaFX 17, modular applications are failing to compile with Maven. > > > > The reason behind this lies in the `plexus-java` library used by `maven-compiler-plugin`: > > > > 1. `plexus-java` doesn't allow duplicate entries with same module-name on module-path > > 2. For 17, `plexus-java` resolves both empty and platform jar to have the same module-name > > 3. However, with `-ea+xx`, `plexus-java` resolves the module name for empty jar as null and we never discovered the bug until 17 was released > > > > 17 > > --- > > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17.jar > > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c1c939a0 > > Module Name: javafx.controls > > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17-linux.jar > > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at 31c3da0e > > Module Name: javafx.controls > > > > 17-ea+18 > > -------- > > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18.jar > > Module Name: null > > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18-linux.jar > > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c896ba80 > > Module Name: javafx.controls > > > > ----X---- > > > > This whole experience has made us realised we need to rethink how we package JavaFX Maven artifacts. > > We are still discussing about the approach and naming, but we are throwing it out in the open to gather feedback: > > > > 1. Instead of 1 module per component, we will have 2 modules (javafx.base.api and javafx.base.platform) > > 2. The `javafx.base.api`, unlike empty jar, will contain all generic Java code > > 3. The `javafx.base.platform` will contain platform-specific native + Java code > > 4. Current application declare their module-descriptor as: > > > > ``` > > module app { > > requires javafx.base; > > } > > ``` > > > > 5. In future this may be changed depending on how we end up wiring these modules together: > > > > ``` > > module app { > > requires javafx.base [.api or .platform]; > > } > > ``` > > > > > > [1] https://www.mail-archive.com/dev at maven.apache.org/msg123978.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8264998 > From tbee at tbee.org Fri Sep 10 15:01:03 2021 From: tbee at tbee.org (Tom Eugelink) Date: Fri, 10 Sep 2021 17:01:03 +0200 Subject: Javafx 17 and moditect no longer working In-Reply-To: <7a53b260-9ebe-2ae1-f90f-7e76a145fd61@gmail.com> References: <31797649-98cb-21ae-efe6-1d851db61250@itarchitects.at> <7a53b260-9ebe-2ae1-f90f-7e76a145fd61@gmail.com> Message-ID: <9f307999-187a-28a4-b8d7-abb6f808686f@tbee.org> Ahm. What does JPMS bring besides headaches? On 2021-09-10 15:00, Ty Young wrote: > My application also does not work with 17. The module-info.java spits out random duplicate module reading errors and JavaFX classes can't be found at compile time. > > > On 9/10/21 5:47 AM, Clemens Lanthaler wrote: >> Hello everyone, >> >> I have just updated from javafx 17-ea+14 to the GA release and I am not able to build one of my projects (PhotoSlide, librawFX, JeditFX, ...) anymore. The root cause is that via maven the it downloads for each component two files (e.g. javafx-base.jar nad javafx-base-mac.jar). The first one contains only the MANIFEST file and nothing more. The problem I have is that until ea+14 the MANIFEST file contained to automatic-module-name and therefore moditect or similar tools can pick this name up. Now the automatic module name is missing in this MANIFEST file and therefore moditect is no finding any module naming anymore and try to use the file name instatt. The problem is that this results in a module name "javafx.base" which is also defined in module-info.class inside of javafx-base-mac.jar. In this case moditect cannot proceed because of duplicate items. >> >> Question from my side: Why is this extra jar file necessary ? If it is necessary is there a possability to get back the automatic-module-nam entry in the MANIFEST file ? >> >> cheers, >> Clemens >> From kevin.rushforth at oracle.com Fri Sep 10 15:11:11 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 10 Sep 2021 08:11:11 -0700 Subject: Announcing the new jfx-sandbox repo Message-ID: We have created a new jfx-sandbox repo: https://github.com/openjdk/jfx-sandbox This repository serves the same purpose as the jdk-sandbox: It allows multiple OpenJFX Committers to collaborate on larger shared fixes, prototypes, or projects. By way of example, it could be used for a macOS Metal pipeline, a GTK 4 platform, or Wayland. All OpenJFX Committers have direct push access to the jfx-sandbox repo (just like the JDK Committers do for jdk-sandbox). General rules and guidelines: There are only two hard-and-fast rules that must be observed: 1. Don't push any commits to the master branch and don't open a PR against master. The master branch is continuously mirrored from the jfx:master branch and should be considered read-only in jfx-sandbox. 2. Don't push to someone else's branch without talking to them first. And a couple general guidelines that will make this a more pleasant place to play: 3. Unless this is intended to be a shared, semi-formal project (e.g., metal, gtk4, wayland-x11, wayland-native), please prefix the name of your branch with either a JBS bug ID or your openjdk username. 4. Don't force push to a branch without getting consensus among the collaborators. Let me know if you have any questions. -- Kevin From swpalmer at gmail.com Fri Sep 10 16:20:57 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 10 Sep 2021 12:20:57 -0400 Subject: JavaFX 17 Maven Artifacts In-Reply-To: References: Message-ID: <5E66EFD3-A01A-4AE0-B6C3-07F0324921CB@gmail.com> I still think having .jmod files available from an artifact repository would be helpful. I?ve deployed them from the SDK to my local Artifactory repo for my own builds. Using Gradle I create a JRE with jlink if needed for running debug/tests during development, or I use an OpenJDK distribution that has bundled in JavaFX (like those available from Azul or BellSoft). The primary downside of using the .jmod files is that they can?t be used at runtimes o you need to build a JRE, but that is the recommended practice now for distributing applications anyway. I use jpackage for distribution so I'm bundling a JRE with the JavaFX modules. Using .jar files for libraries that contain native code is messy IMO. JMOD files are supposed to solve that - they should be the preferred way to include JavaFX in a build, but installing the JavaFX SDK is a pain when we use dependency management for everything else. Scott > On Sep 10, 2021, at 9:10 AM, Abhinay Agarwal wrote: > > JavaFX 17 Maven artifacts currently fail to compile modular JavaFX application. The non-modular application still works. > > To explain what's going on, let have a look at JavaFX and its Maven distribution since version 11: > > 1. JavaFX is distributed in non-platform (empty) and platform specific artifacts > 2. These artifacts along with the javafx plugins have helped developers to use JavaFX in platform agnostic way > 3. Platform jars have the `module-info.java` file, whereas, `Automatic-Module-Name` was present in the empty jar's MANIFEST.MF. > 4. However, using `maven-jlink-plugin` with a JavaFX application fails since Automatic modules are not supported in JLink [1] > 5. After a brief discussion, it was decided to remove the Automatic Module Name from non-platform jars [2] > > The EA releases were working perfectly after the change was made. However, with recent JavaFX 17, modular applications are failing to compile with Maven. > > The reason behind this lies in the `plexus-java` library used by `maven-compiler-plugin`: > > 1. `plexus-java` doesn't allow duplicate entries with same module-name on module-path > 2. For 17, `plexus-java` resolves both empty and platform jar to have the same module-name > 3. However, with `-ea+xx`, `plexus-java` resolves the module name for empty jar as null and we never discovered the bug until 17 was released > > 17 > --- > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17.jar > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c1c939a0 > Module Name: javafx.controls > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17-linux.jar > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at 31c3da0e > Module Name: javafx.controls > > 17-ea+18 > -------- > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18.jar > Module Name: null > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18-linux.jar > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c896ba80 > Module Name: javafx.controls > > ----X---- > > This whole experience has made us realised we need to rethink how we package JavaFX Maven artifacts. > We are still discussing about the approach and naming, but we are throwing it out in the open to gather feedback: > > 1. Instead of 1 module per component, we will have 2 modules (javafx.base.api and javafx.base.platform) > 2. The `javafx.base.api`, unlike empty jar, will contain all generic Java code > 3. The `javafx.base.platform` will contain platform-specific native + Java code > 4. Current application declare their module-descriptor as: > > ``` > module app { > requires javafx.base; > } > ``` > > 5. In future this may be changed depending on how we end up wiring these modules together: > > ``` > module app { > requires javafx.base [.api or .platform]; > } > ``` > > > [1] https://www.mail-archive.com/dev at maven.apache.org/msg123978.html > [2] https://bugs.openjdk.java.net/browse/JDK-8264998 From jpereda at openjdk.java.net Fri Sep 10 18:15:21 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 10 Sep 2021 18:15:21 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v9] In-Reply-To: References: Message-ID: > Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. > > In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. > > The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. > > Unit tests and a system test are provided. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Fix test to pass all 3 platforms ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/563/files - new: https://git.openjdk.java.net/jfx/pull/563/files/90ab86d4..40302d8c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=07-08 Stats: 17 lines in 1 file changed: 2 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/563.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/563/head:pull/563 PR: https://git.openjdk.java.net/jfx/pull/563 From jpereda at openjdk.java.net Fri Sep 10 18:15:23 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Fri, 10 Sep 2021 18:15:23 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v6] In-Reply-To: References: Message-ID: <3kRX5yyLefoi_Eu54-TPmtNSwkm-U2Egq12SsYJYLK0=.e71c778b-802f-4bc7-bfd5-6b7ebbd811aa@github.com> On Mon, 6 Sep 2021 13:30:46 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Use color to int32 converter instead of hash > >> The other option, as you mention, is finding out if the 32-bit int has alpha 0 or 1, which can be done storing only the int value, not the color, so this looks cleaner, we don't really need to hold a reference to the Color after all > > Yes, I like this better, too. > > I also agree with the point about including `rgba` in the name. It is also meaningful to keep `int` in the name. We would typically call this format `IntRgba`. @kevinrushforth It should be fixed now, the test should pass on the three platforms. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Fri Sep 10 19:45:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Sep 2021 19:45:02 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v9] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 18:15:21 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Fix test to pass all 3 platforms I'll test on all three platforms and report back. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From johan.vos at gluonhq.com Sat Sep 11 09:26:24 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 11 Sep 2021 11:26:24 +0200 Subject: JavaFX 17 Maven Artifacts In-Reply-To: <5E66EFD3-A01A-4AE0-B6C3-07F0324921CB@gmail.com> References: <5E66EFD3-A01A-4AE0-B6C3-07F0324921CB@gmail.com> Message-ID: Hi Scott, Your points about .jmod are very valid, but I see this discussion somehow separated from the original one. There are plenty of developers using maven to compile, build and run JavaFX applications. They need a maven-solution for those lifecycles. Being pragmatic, I don't think native code in jar files is messy. There are resources in jar files, meta-info etc. Unless I'm missing something, we don't have a real alternative to address the requests from the developers using maven? Besides, I believe a split of generic code (Java) and platform specific code (Java + native) is always a good thing, so I believe this is something we have to do anyhow. - Johan On Fri, Sep 10, 2021 at 6:21 PM Scott Palmer wrote: > I still think having .jmod files available from an artifact repository > would be helpful. I?ve deployed them from the SDK to my local Artifactory > repo for my own builds. Using Gradle I create a JRE with jlink if needed > for running debug/tests during development, or I use an OpenJDK > distribution that has bundled in JavaFX (like those available from Azul or > BellSoft). The primary downside of using the .jmod files is that they > can?t be used at runtimes o you need to build a JRE, but that is the > recommended practice now for distributing applications anyway. I use > jpackage for distribution so I'm bundling a JRE with the JavaFX modules. > > Using .jar files for libraries that contain native code is messy IMO. > JMOD files are supposed to solve that - they should be the preferred way to > include JavaFX in a build, but installing the JavaFX SDK is a pain when we > use dependency management for everything else. > > Scott > > > On Sep 10, 2021, at 9:10 AM, Abhinay Agarwal > wrote: > > > > JavaFX 17 Maven artifacts currently fail to compile modular JavaFX > application. The non-modular application still works. > > > > To explain what's going on, let have a look at JavaFX and its Maven > distribution since version 11: > > > > 1. JavaFX is distributed in non-platform (empty) and platform specific > artifacts > > 2. These artifacts along with the javafx plugins have helped developers > to use JavaFX in platform agnostic way > > 3. Platform jars have the `module-info.java` file, whereas, > `Automatic-Module-Name` was present in the empty jar's MANIFEST.MF. > > 4. However, using `maven-jlink-plugin` with a JavaFX application fails > since Automatic modules are not supported in JLink [1] > > 5. After a brief discussion, it was decided to remove the Automatic > Module Name from non-platform jars [2] > > > > The EA releases were working perfectly after the change was made. > However, with recent JavaFX 17, modular applications are failing to compile > with Maven. > > > > The reason behind this lies in the `plexus-java` library used by > `maven-compiler-plugin`: > > > > 1. `plexus-java` doesn't allow duplicate entries with same module-name > on module-path > > 2. For 17, `plexus-java` resolves both empty and platform jar to have > the same module-name > > 3. However, with `-ea+xx`, `plexus-java` resolves the module name for > empty jar as null and we never discovered the bug until 17 was released > > > > 17 > > --- > > > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17.jar > > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c1c939a0 > > Module Name: javafx.controls > > > /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17-linux.jar > > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at 31c3da0e > > Module Name: javafx.controls > > > > 17-ea+18 > > -------- > > > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18.jar > > Module Name: null > > > /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18-linux.jar > > org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor at c896ba80 > > Module Name: javafx.controls > > > > ----X---- > > > > This whole experience has made us realised we need to rethink how we > package JavaFX Maven artifacts. > > We are still discussing about the approach and naming, but we are > throwing it out in the open to gather feedback: > > > > 1. Instead of 1 module per component, we will have 2 modules > (javafx.base.api and javafx.base.platform) > > 2. The `javafx.base.api`, unlike empty jar, will contain all generic > Java code > > 3. The `javafx.base.platform` will contain platform-specific native + > Java code > > 4. Current application declare their module-descriptor as: > > > > ``` > > module app { > > requires javafx.base; > > } > > ``` > > > > 5. In future this may be changed depending on how we end up wiring these > modules together: > > > > ``` > > module app { > > requires javafx.base [.api or .platform]; > > } > > ``` > > > > > > [1] https://www.mail-archive.com/dev at maven.apache.org/msg123978.html > > [2] https://bugs.openjdk.java.net/browse/JDK-8264998 > > From kcr at openjdk.java.net Sat Sep 11 13:30:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 11 Sep 2021 13:30:14 GMT Subject: [jfx17u] RFR: 8273280: Update README.md and CONTRIBUTING.md for jfx17u Message-ID: This PR updates [`README.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/README.md) and [`CONTRIBUTING.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/CONTRIBUTING.md) to be suitable for update releases. The two files were copied from jfx11u, with the only changes being to replace "11" with "17" in the two files. ------------- Commit messages: - 8273280: Update README.md and CONTRIBUTING.md for jfx17u Changes: https://git.openjdk.java.net/jfx17u/pull/1/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=1&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273280 Stats: 237 lines in 2 files changed: 0 ins; 227 del; 10 mod Patch: https://git.openjdk.java.net/jfx17u/pull/1.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/1/head:pull/1 PR: https://git.openjdk.java.net/jfx17u/pull/1 From kcr at openjdk.java.net Sat Sep 11 13:33:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 11 Sep 2021 13:33:09 GMT Subject: [jfx17u] RFR: 8273279: Change JavaFX release version in jfx17u to 17.0.1 Message-ID: Bump release version in `jfx17u` repo to 17.0.1 for the start of a new release. ------------- Commit messages: - 8273279: Change JavaFX release version in jfx17u to 17.0.1 Changes: https://git.openjdk.java.net/jfx17u/pull/2/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=2&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273279 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/2/head:pull/2 PR: https://git.openjdk.java.net/jfx17u/pull/2 From hjohn at xs4all.nl Sat Sep 11 15:16:07 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 11 Sep 2021 17:16:07 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: References: <009017d1-572b-e03c-f5c7-d045b3f57592@xs4all.nl> Message-ID: I'm willing to invest the necessary time in this. What should a concrete proposal consist of? Is there a format for this that I can follow (like https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 for example?) Otherwise I can flesh out a small document with the Why, What, How of this addition, broken into several parts to keep each addition small but coherent with a larger whole. My current proposal adds around 400 lines of code, which is about as small as I can get it while still offering something of value. The newly introduced public API surface can be reduced a bit further. A summary of the changes are: ObservableValue interface - 5 new methods with default implementations to support fluent mappings - 2 new methods for registration of subscribers (could be removed from the public API for now). ObjectBinding - adds two new protected methods with trivial implementations in order to support the functionality needed by LazyObjectBinding - functionality of class unaltered for any existing code, fully backwards compatible Subcription interface - new public interface with two methods (does not need to be part of the initial API, could be internal for now) All the other code is just implementation and can be moved to internal packages which means that this change could be limited to introducing five new public methods and two protected ones. If you can point me in the right direction, I'll work on a concrete proposal. I also have a small Maven dependency with these changes as part of JavaFX (breaking module boundaries) that can serve as a preview of the feature if there is any interest. --John On 27/08/2021 18:58, Kevin Rushforth wrote: > This is a rather large addition to the properties API, but there seems > to be enough interest in it that it might be worth getting to the point > of a concrete proposal that we could discuss on the list. > > I wouldn't expect it for JavaFX 18, since it will almost certainly take > longer than that. Which makes this a good time to remind folks that the > development model under the six month release cycle is such that > features go in when ready, rather than necessarily being tied to a > specific release. > > -- Kevin > > > On 8/4/2021 3:25 PM, John Hendrikx wrote: >> Perhaps: >> >> Fluent bindings for ObservableValue >> https://github.com/openjdk/jfx/pull/434 >> >> It was received well I think, and there was some interest from Nir >> Lisker to work on a proposal. >> >> --John >> >> On 30/07/2021 14:56, Kevin Rushforth wrote: >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >>> and enhancement requests for JavaFX 18. It's the summer, so there may be >>> delays as some people are out at various times (including me), but I >>> would like to get some of the outstanding enhancement requests moving >>> over the next few weeks. >>> >>> Specifically, I'd like to see the following proceed: >>> >>> * Transparent backgrounds in WebView >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >>> PR: https://github.com/openjdk/jfx/pull/563 >>> >>> * Add DirectionalLight >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >>> PR: https://github.com/openjdk/jfx/pull/548 >>> >>> * CSS pseudoclasses :focus-visible and :focus-within >>> https://bugs.openjdk.java.net/browse/JDK-8268225 >>> PR: https://github.com/openjdk/jfx/pull/475 >>> >>> * Improve property system to facilitate correct usage (minus the binary >>> incompatible API change) >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >>> >>> And maybe the following: >>> >>> * Add CSS themes as a first-class concept (need a consensus on how to >>> proceed) >>> >>> * Undecorated interactive stage style (still in early discussion, but >>> the concept looks interesting and useful) >>> >>> There are probably others I'm forgetting. >>> >>> Each of the above should be discussed in their own thread on openjfx-dev >>> rather than a reply to this thread. >>> >>> -- Kevin >>> >>> > From kcr at openjdk.java.net Sat Sep 11 15:38:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 11 Sep 2021 15:38:54 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v9] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 18:15:21 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Fix test to pass all 3 platforms The test now passes on one of my Linux machines, but I still see the smearing of the text when scrolling. I took the html file from your test and used it in a simple interactive program using a transparent background that will show the problem. If you run the test program on either Mac or Linux (using the es2 pipeline) and scroll the window, you will see that the scroll area isn't cleared. I found that if the color has any alpha > 0 it works correctly. This means that something is behaving differently with fully transparent (alpha == 0) in the ES2 pipeline. It might be related to why you needed to change the initial fill color for the ES2 pipeline. [SimpleWebViewTransp.java.txt](https://github.com/openjdk/jfx/files/7148102/SimpleWebViewTransp.java.txt) ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From nlisker at gmail.com Sat Sep 11 16:41:06 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 11 Sep 2021 19:41:06 +0300 Subject: Eager Evaluation of Invalidation Listeners In-Reply-To: References: <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl> Message-ID: I think that we need your input on this to move it forward. On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker wrote: > so the value field should perhaps be nulled out when bound. > > > There was a PR for something like that in the old repo: > https://github.com/javafxports/openjdk-jfx/pull/110 > > On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx wrote: > >> >> >> On 02/09/2021 11:57, Nir Lisker wrote: >> > So in order >> > to make sure that a new interested invalidation listener does not >> miss >> > the fact that a property was *already* invalid, the easiest solution >> > might have been to revalidate it upon registration of a new listener >> > >> > >> > But why does an invalidation listener need to know the past state of the >> > property? It is only interested in the valid -> invalid transition. If >> > the property was invalid then the listener (in theory) shouldn't receive >> > any events anyway on subsequent invalidations. (I understand that you >> > don't justify this, I'm posing it as a general question.) >> >> Strictly speaking, no, if users are using InvalidationListener correctly >> then this is definitely correct behavior. I'm not really advocating a >> change, and I'd even prefer that it be brought in line with the >> documentation. >> >> I think however that many users are not using it correctly and expect an >> invalidation event always the next time the value changes (and their >> listener will read that value, validating it again), making it act like >> a light-weight ChangeListener. I know that I probably have written code >> that made that assumption, and would in the past not even think twice >> about replacing a change with an invalidation listener or vice versa if >> that happened to be a better fit. Which is sort of what happened as well >> in the bidirectional binding PR, and the issue slipped past the author >> and two reviewers. >> >> > I suggest that we split the problem into 2: one is the case where the >> > property was valid when the listener was attached, and the other is when >> > it was invalid. >> > * A valid starting state. In this case attaching a listener shouldn't >> > need to do anything. A subsequent invalidation event will be sent >> > regardless. Currently, it is calling get() redundantly. >> >> True, the call to get is redundant in this case. Ugly too, calling get >> and discarding its result, while the intention is to force the property >> to become valid. >> >> > * An invalid starting state. In this case the documentation says that >> > nothing needs to happen, but get() is called anyway. Here, the >> > difference is that a subsequent invalidation event is sent in one case >> > and not in the other. The only way to advance here is to make a design >> > decision on what should happen, at least that's how I see it. >> >> The docs are even more specific I think, they say no more events will be >> generated until it becomes valid -- it doesn't leave any option open >> that it could generate events if it wanted to. >> >> > As to the implementation of a possible solution, suppose we add the >> > isValid method. Upon attaching an invalidation listener, if the property >> > is valid, we can skip the get() call. That solves the valid starting >> > state issue. The question is what to do if the property is not valid. >> > >> > I also noticed an odd design choice in the implementation of properties: >> > the value field does not update if the property is bound, instead, the >> > result of the binding is returned and the value field holds an outdated >> > value (until the property is unbound). >> >> Yeah, that might not be a wise decision as that can lead to memory being >> referenced that users might expect to be freed. I didn't see anywhere >> defined what will happen to the value of the property when it is unbound >> again. The current implementation will keep its last value (during the >> unbind it will take the last value and assign it to its own value >> field), so the value field should perhaps be nulled out when bound. >> >> --John >> > From jpereda at openjdk.java.net Sat Sep 11 16:40:54 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sat, 11 Sep 2021 16:40:54 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v9] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 18:15:21 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Fix test to pass all 3 platforms Thanks for testing it, I can reproduce the issue indeed. I had my interactive test too which doesn't fail with alpha = 0, and comparing both tests I realise now that in my case I was using a transparent VBox instead of a Group as a container for the WebView, and later on when I created the system test, I removed such container. If you try: webView.setPageFill(Color.TRANSPARENT); var root = new VBox(); root.setStyle("-fx-background-color: transparent"); root.getChildren().add(webView); that should work for you as well... Obviously there is an issue with alpha = 0 in case we use Group or not container at all, vs when we use a Region. The comment at [Region::doComputeGeomBounds](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java#L3310) my be relevant though? > the geom bounds forms the basis of the dirty regions ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From tom.schindl at bestsolution.at Sat Sep 11 23:38:30 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sun, 12 Sep 2021 01:38:30 +0200 Subject: Enhancements for JavaFX 18 In-Reply-To: <009017d1-572b-e03c-f5c7-d045b3f57592@xs4all.nl> References: <009017d1-572b-e03c-f5c7-d045b3f57592@xs4all.nl> Message-ID: <747d56a4-20c2-873d-2167-b62a794ce34b@bestsolution.at> I have not looked at the code yet but why does this have to be part of OpenJFX and can not be implemented as an external library? Tom Am 05.08.21 um 00:25 schrieb John Hendrikx: > Perhaps: > > Fluent bindings for ObservableValue https://github.com/openjdk/jfx/pull/434 > > It was received well I think, and there was some interest from Nir > Lisker to work on a proposal. > > --John > > On 30/07/2021 14:56, Kevin Rushforth wrote: >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes >> and enhancement requests for JavaFX 18. It's the summer, so there may be >> delays as some people are out at various times (including me), but I >> would like to get some of the outstanding enhancement requests moving >> over the next few weeks. >> >> Specifically, I'd like to see the following proceed: >> >> * Transparent backgrounds in WebView >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 >> PR: https://github.com/openjdk/jfx/pull/563 >> >> * Add DirectionalLight >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 >> PR: https://github.com/openjdk/jfx/pull/548 >> >> * CSS pseudoclasses :focus-visible and :focus-within >> https://bugs.openjdk.java.net/browse/JDK-8268225 >> PR: https://github.com/openjdk/jfx/pull/475 >> >> * Improve property system to facilitate correct usage (minus the binary >> incompatible API change) >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 >> PR: https://github.com/openjdk/jfx/pull/590 (Draft) >> >> And maybe the following: >> >> * Add CSS themes as a first-class concept (need a consensus on how to >> proceed) >> >> * Undecorated interactive stage style (still in early discussion, but >> the concept looks interesting and useful) >> >> There are probably others I'm forgetting. >> >> Each of the above should be discussed in their own thread on openjfx-dev >> rather than a reply to this thread. >> >> -- Kevin >> >> -- Tom Schindl - CTO BestSolution.at EDV Systemhaus GmbH Salurner Stra?e 15, A-6020 Innsbruck Phone: ++43 (0)512 935834 http://www.BestSolution.at - http://efxclipse.org From nlisker at gmail.com Sun Sep 12 00:05:10 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 12 Sep 2021 03:05:10 +0300 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> Message-ID: I've gotten back to look at this. For now I'm dealing only with the nullableMapping method in Bindings so we can limit the amount of new classes to LazyObjectBinding (FlatMapBinding and ConditionalBinding can come later). This method is used by map, orElse and orElseGet in ObservableValue. Of these, map is the only fundamental one since the other 2 can be represented by it. I don't mind keeping them in the discussion, though I will be centered on the map method. The implementation of these methods rely on Bindings, LazyObjectBinding, and Subscription in the current implementation. I think that we can introduce these internally for now. The biggest hurdle left are the public changes to ObjectBinding. If we add protected methods, we need to be sure that by the end of this large task they would have been the right ones to add and at the right place. This is why I recommend adding them at the package visibility level and add LazyObjectBinding (and friends) in its package so they can extend it. I understand that this can look ugly, but moving internal implementation is cheap, and in this case, since the coupling involves about 3 classes, is very cheap. This will lower the initial integration barrier and let the community get used to- and give feedback on the new changes. This will leave only 1 change that we are committed to, and that's the new API on ObservableValue (which is the map method in this case). The method looks good; the only question, which has arisen in a few places, is how to handle null. As we discussed here, this method works like its ReactFX counterpart, ignoring null. My questions would be: 1. Is there a good reason to allow null? If so, do we add a new method for it, or do we pass some parameter to the current method to indicate that? 2. If we want to replace the Bindings.select (non-type safe) API, can we do it with our current way of treating null? Do you think that this is a valid approach? - Nir On Wed, Apr 7, 2021 at 11:30 PM John Hendrikx wrote: > On 07/04/2021 03:41, Nir Lisker wrote: > > In the PoC I made I specifically also disallowed 'null' as an input > > > > > > I like the way ReactFX does it where the property is empty. I think that > > this is also what you mean by disallowing `null` (in other contexts, > > "disallowing null" would mean throwing an exception). > > Yes, it is the same concept as ReactFX calling a property "empty", but I > was hesitant to call this as `null` is a valid value for many JavaFX > properties (a Scene can be null, a String can be null, etc.) which I > don't think means the same as it being empty (in the Optional sense). > But as long as the documentation is clear, I don't mind calling it either. > > > > > Not entirely sure what you mean by this. > > > > > > Basically, what you said. My point was that this is a different API > > section. The first deals with expanding the observables/properties > > methods. The second with listeners methods. Even if mapping a property > > requires a new listening model, like subscriptions, this is done under > > the hood. Exposing this API should be a separate step. At least that's > > how I see it. > > Yes, I think it is good to limit new API as much as possible to reduce > scope and increase the chances of its acceptance. The subscription parts > can be designed separately and do not need to be public at this point. > They can be moved to a helper, or the implementation can take the extra > effort to use standard listeners. > > > > > I'd be happy to spend more time and work on this. Perhaps it would be > > possible to collaborate on this? > > > > > > That would be good. I will need to re-review the ReactFX internals and > > see how your proposal differs exactly. > > Yes, I think that would be good to do. > > I've done some comparisons myself and didn't find a difference in > functionality with `Val` (so far). It is a new implementation though, I > didn't really look at how `Val` was done internally as implementing it > directly into JavaFX is quite different (I had to make a few minor > changes in `ObjectBinding` to allow for the choice of lazy binding). I > was also initially more focused on Streams only to realize at a later > point that having a Stream implement ObservableValue was not going to be > pretty (I suspect this also happened when ReactFX was created, which is > why Val/Var were later introduced in 2.x). > > Both the PoC and Val do lazy binding and are null safe and provide > methods to deal with null/empty. > > The main thing I didn't do yet is provide a `filter` method. Filtering > properties that you want to use for bindings seems awkard as a binding > should always have some kind of value. The `filter` method in ReactFX > basically maps the value to `null` when it doesn't match the filter. > I've left this out as you can easily achieve this with `map` and > `filter` seems to be too easy to misunderstand. > > Aside from that, ReactFX's Val offers a lot of other methods that are I > think a bit too specialized to consider at this point, like the > `animate`, `pin`, `mapDynamic` and `suspendable` methods. > > Val also has all the other `Optional` methods (ifPresent, isPresent, > isEmpty) but I think they may make the API a bit confusing (an > observable value is not the same as an optional). I've also not had a > need for these so far in practice and you can easily convert the current > value to get this functionality with `Optional.ofNullable`. > > Finally Val offers a few methods to convert to ReactFX's streams. While > convenient, I think static methods like `Values.of`, `Invalidations.of` > or `Changes.of` would make for a less cluttered API to do stream > conversions -- this would also make it possible to leave this part of > the API up to a 3rd party. > > > By the way, do you make a distinction between ReactFX's Val and Var in > > your proposal (one being read-only)? > > No, `ObservableValue` is basically the same as `Val`, and the equivalent > to `Var` is `ObjectProperty`. Aside from it being a good companion to > `Val` (and less typing), I don't see a reason to implement `Var`. > > --John > > > > > On Sun, Apr 4, 2021 at 12:43 PM John Hendrikx > > wrote: > > > > > > > > On 02/04/2021 08:47, Nir Lisker wrote: > > > Hi John, > > > > > > I've had my eyes set on ReactFX enhancements for a while too, > > especially as > > > a replacement for the unsafe "select" mechanism. One of the things > > that > > > kept me from going forward with this is seeing what Valhalla will > > bring. > > > Generic specialization might save a lot of duplication work on > > something > > > like this, and Tomas touched another related issue [1], but since > > it could > > > be a long time before that happens, it's worth planning what we > > can extract > > > from ReactFX currently. > > > > Agreed, Valhalla is certainly a highly anticipated feature but I > > fear it > > is still a couple of years away. > > > > Even without any initial support for dealing with "? extends Number" > > from the various ObservableValue specializations I think looking into > > this can already be tremendous help. > > > > The proof of concept mainly requires you convert the Number to a > > suitable type when reading the property but has no problems in the > > other > > direction: > > > > label.widthProperty().map(Number::doubleValue).map(x -> x + 1); > > > > Not pretty, but certainly workable. Specific methods could be > > introduced > > (even at a later time) to make this more streamlined, similar to what > > the Stream API offers with 'mapToDouble' etc. > > > > > I think that we should break the enhancements into parts. > > > The first that I would advise to look at are the additions to > > > properties/observables. Tomas had to create Val and Var because he > > couldn't > > > change the core interfaces, but we can. Fitting them with the > Optional > > > methods like `isPresent`, `isEmpty`, `ifPresent`, `map`. `flatMap` > > etc.; > > > and `select` and friends, is already a good start that will > > address many > > > common requirements. > > > > Yes, Val/Var had to be created for that reason, and also because > > properties don't quite behave the same as streams -- streams with a > > "toBinding" method results in things people didn't quite expect. > > > > As far as the Optional methods go, I'm not entirely sure properties > > would benefit from all of them. Properties are not immutable like > > Optional and it may make less sense to fit them with 'isPresent', > > 'isEmpty' and 'ifPresent' ('ifPresent' would I think need to behave > > similar to 'addListener' or 'subscribe'). > > > > In the PoC I made I specifically also disallowed 'null' as an input > for > > functions like 'map' and 'flatMap' (opting to use 'orElse' semantics > > for > > 'null'), as this for allows much cleaner mapping (and especially flat > > mapping when selecting nested properties). If 'null' were to be > > allowed, > > I think at a minimum we'd need to add another method to allow for > easy > > selecting of nested properties to avoid: > > > > obs.flatMap(x -> x == null ? null : x.otherProperty()) > > > > > The second part is related to listeners. The subscription model > > and event > > > streams try to solve the memory issues with hard and weak > > references, and > > > allow better composition. > > > > Not entirely sure what you mean by this. JavaFX's current model uses > > weak references which was I think an unfortunate decision as it can > > result in huge confusion. For example, a direct binding will work, > but > > with an indirection step a binding stops working: > > > > button.textProperty() > > .concat("World") // weak binding used here > > .addListener((obs, old, cur) -> System.out.println(cur)); > > > > The above stops working, but without the 'concat' it keeps working. > > > > I think the use of weak listeners should be avoided and instead other > > mechanisms should be provided to make cleaning up easier. This is the > > main reason for 'conditionOn' and why ReactFX even had a specialized > > version of it: 'conditionOnShowing(Node)'. > > > > > The third part is for collections - things like transformation > lists > > > (LiveList) and for other collections. > > > > This is indeed best saved for last. The problems there I think are > less > > of an issue for now. > > > > > Since these share behavior under the hood, we need to look ahead, > > but in > > > terms of functionality, I think we should take smaller steps. It > > will also > > > be easier to propose these then. > > > > I've for this reason kept the PoC small with only the most basic > > functionality. I did however add some work for a different > > subscription > > model, mainly because the internals of this code benefits greatly > from > > it. It is however kept to a minimum. > > > > I'd be happy to spend more time and work on this. Perhaps it would be > > possible to collaborate on this? > > > > --John > > > > > > > > - Nir > > > > > > [1] > > > > > > https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issue > > > > > > On Wed, Mar 24, 2021 at 11:49 PM John Hendrikx > > wrote: > > > > > >> I just wanted to draw some attention to a recent proof of concept > > I made > > >> in this pull request: https://github.com/openjdk/jfx/pull/434 > > >> > > >> It is based on the work I did in > > >> https://github.com/hjohn/hs.jfx.eventstream which is in part > based on > > >> work done in ReactFX by Tomas Mikula. The PR itself however > shares no > > >> code with ReactFX and is > > >> completely written by me. > > >> > > >> If there is interest, I'm willing to invest more time in > > smoothing out > > >> the API and documentation, investigating further how this would > > interact > > >> with the primitive types and adding unit test coverage (I have > > extensive > > >> tests, but thesea are written in JUnit 5, so they would require > > >> conversion or JavaFX could move to support JUnit 5). > > >> > > >> What follows below is the text of the PR for easy reading. > > Feedback is > > >> appreciated. > > >> > > >> ================ > > >> > > >> This is a proof of concept of how fluent bindings could be > > introduced to > > >> JavaFX. The main benefit of fluent bindings are ease of use, type > > safety > > >> and less surprises. Features: > > >> > > >> Flexible Mappings > > >> Map the contents of a property any way you like with map, or map > > nested > > >> properties with flatMap. > > >> > > >> Lazy > > >> The bindings created are lazy, which means they are always > > invalid when > > >> not themselves observed. This allows for easier garbage > > collection (once > > >> the last observer is removed, a chain of bindings will stop > observing > > >> their parents) and less listener management when dealing with > nested > > >> properties. Furthermore, this allows inclusion of such bindings in > > >> classes such as Node without listeners being created when the > binding > > >> itself is not used (this would allow for the inclusion of a > > >> treeShowingProperty in Node without creating excessive listeners, > see > > >> this fix I did in an earlier PR: #185) > > >> > > >> Null Safe > > >> The map and flatMap methods are skipped, similar to > > java.util.Optional > > >> when the value they would be mapping is null. This makes mapping > > nested > > >> properties with flatMap trivial as the null case does not need to > be > > >> taken into account in a chain like this: > > >> > > > node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). > > >> > > >> Instead a default can be provided with orElse or orElseGet. > > >> > > >> Conditional Bindings > > >> Bindings can be made conditional using the conditionOn method. A > > >> conditional binding retains its last value when its condition is > > false. > > >> Conditional bindings donot observe their source when the > condition is > > >> false, allowing developers to automatically stop listening to > > properties > > >> when a certain condition is met. A major use of this feature is > > to have > > >> UI components that need to keep models updated which may outlive > > the UI > > >> conditionally update the long lived model only when the UI is > > showing. > > >> > > >> Some examples: > > >> > > >> void mapProperty() { > > >> // Standard JavaFX: > > >> label.textProperty().bind(Bindings.createStringBinding(() -> > > >> text.getValueSafe().toUpperCase(), text)); > > >> > > >> // Fluent: much more compact, no need to handle null > > >> label.textProperty().bind(text.map(String::toUpperCase)); > > >> } > > >> > > >> void calculateCharactersLeft() { > > >> // Standard JavaFX: > > >> > > >> > > > label.textProperty().bind(text.length().negate().add(100).asString().concat(" > > >> > > >> characters left")); > > >> > > >> // Fluent: slightly more compact and more clear (no negate > needed) > > >> label.textProperty().bind(text.orElse("").map(v -> 100 - > > v.length() + > > >> " characters left")); > > >> } > > >> > > >> void mapNestedValue() { > > >> // Standard JavaFX: > > >> label.textProperty().bind(Bindings.createStringBinding( > > >> () -> employee.get() == null ? "" > > >> : employee.get().getCompany() == null ? "" > > >> : employee.get().getCompany().getName(), > > >> employee > > >> )); > > >> > > >> // Fluent: no need to handle nulls everywhere > > >> label.textProperty().bind( > > >> employee.map(Employee::getCompany) > > >> .map(Company::getName) > > >> .orElse("") > > >> ); > > >> } > > >> > > >> void mapNestedProperty() { > > >> // Standard JavaFX: > > >> label.textProperty().bind( > > >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), > > >> "window", "showing")) > > >> .then("Visible") > > >> .otherwise("Not Visible") > > >> ); > > >> > > >> // Fluent: type safe > > >> label.textProperty().bind(label.sceneProperty() > > >> .flatMap(Scene::windowProperty) > > >> .flatMap(Window::showingProperty) > > >> .orElse(false) > > >> .map(showing -> showing ? "Visible" : "Not Visible") > > >> ); > > >> } > > >> > > >> void updateLongLivedModelWhileAvoidingMemoryLeaks() { > > >> // Standard JavaFX: naive, memory leak; UI won't get garbage > > collected > > >> > listView.getSelectionModel().selectedItemProperty().addListener( > > >> (obs, old, current) -> > > >> longLivedModel.lastSelectedProperty().set(current) > > >> ); > > >> > > >> // Standard JavaFX: no leak, but stops updating after a while > > >> > listView.getSelectionModel().selectedItemProperty().addListener( > > >> new WeakChangeListener<>( > > >> (obs, old, current) -> > > >> longLivedModel.lastSelectedProperty().set(current) > > >> ) > > >> ); > > >> > > >> // Standard JavaFX: fixed version > > >> listenerReference = (obs, old, current) -> > > >> longLivedModel.lastSelectedProperty().set(current); > > >> > > >> > listView.getSelectionModel().selectedItemProperty().addListener( > > >> new WeakChangeListener<>(listenerReference) > > >> ); > > >> > > >> // Fluent: naive, memory leak... fluent won't solve this... > > >> listView.getSelectionModel().selectedItemProperty() > > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > > >> > > >> // Fluent: conditional update when control visible > > >> > > >> // Create a property which is only true when the UI is visible: > > >> ObservableValue showing = listView.sceneProperty() > > >> .flatMap(Scene::windowProperty) > > >> .flatMap(Window::showingProperty) > > >> .orElse(false); > > >> > > >> // Use showing property to automatically disconnect long lived > > model > > >> // allowing garbage collection of the UI: > > >> listView.getSelectionModel().selectedItemProperty() > > >> .conditionOn(showing) > > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > > >> > > >> // Note that the 'showing' property can be provided in > > multiple ways: > > >> // - create manually (can be re-used for multiple bindings > though) > > >> // - create with a helper: Nodes.showing(Node node) -> > > >> ObservableValue > > >> // - make it part of the Node class; as the fluent bindings > > only bind > > >> themselves > > >> // to their source when needed (lazy binding), this won't > create > > >> overhead > > >> // for each node in the scene > > >> } > > >> Note that this is based on ideas in ReactFX and my own > experiments in > > >> https://github.com/hjohn/hs.jfx.eventstream. I've come to the > > conclusion > > >> that this is much better directly integrated into JavaFX, and I'm > > hoping > > >> this proof of concept will be able to move such an effort forward. > > >> > > >> --John > > >> > > > > > > From jpereda at openjdk.java.net Sun Sep 12 00:34:14 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Sun, 12 Sep 2021 00:34:14 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v9] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 18:15:21 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Fix test to pass all 3 platforms Somehow by accident I've found out that doing in `WebPage::paint2GC`: if (clip != null) { if (isBackgroundColorTransparent()) { + gc.clearRect(0, 0, 0, 0); // extra call to clear rect gc.clearRect((int) clip.getX(), (int) clip.getY(), (int) clip.getWidth(), (int) clip.getHeight()); } gc.setClip(clip); fixes the issue for the Group test (same for no container case). Ultimately, this is the same as calling twice `ES2Graphics::clearQuad`. After some testing, I modified this method to get it working with the expected single call with just this change: CompositeMode mode = getCompositeMode(); - // set the blend mode to CLEAR - context.updateCompositeMode(CompositeMode.CLEAR); Paint oldPaint = getPaint(); setPaint(Color.BLACK); // any color will do... fillQuad(x1, y1, x2, y2); + // set the blend mode to CLEAR + context.updateCompositeMode(CompositeMode.CLEAR); context.flushVertexBuffer(); which seems to indicate that `fillQuad` requires SRC_OVER and we can use the original black color, and only before flushing we set the CLEAR mode. Does this make sense? ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From tsayao at openjdk.java.net Sun Sep 12 16:37:58 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Sun, 12 Sep 2021 16:37:58 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: <_rx9AalZNfMzhWtdk8n7ODjN9356jfjuJSPS9hKcPWo=.b58f0693-5921-48d9-8006-8a469929b41e@github.com> References: <3bjat4WLePrqj9ZLIXfU9QQFNY8Xji2h5OMyTuieVcg=.d30af751-a0b7-4023-af91-41456a5df715@github.com> <_rx9AalZNfMzhWtdk8n7ODjN9356jfjuJSPS9hKcPWo=.b58f0693-5921-48d9-8006-8a469929b41e@github.com> Message-ID: On Mon, 16 Aug 2021 06:23:01 GMT, Pankaj Bansal wrote: >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > > I am running a 20.04 VM. The test fails for me 60-70% of the time. I will request someone in team to try this once. @pankaj-bansal Could you please re-test to confirm that it does not work on your VM? ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From thiago.sayao at gmail.com Sun Sep 12 22:52:39 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 12 Sep 2021 19:52:39 -0300 Subject: Announcing the new jfx-sandbox repo In-Reply-To: References: Message-ID: Hi Kevin, https://github.com/tsayao/jfx-sandbox/tree/tsayao_gtk4_playground I have started this as an experiment to make a gtk4 version of the native lib. I did a fork because I don't have permission to branch on jfx-sandbox (or maybe I did something wrong). @Johan Vos has stated that he is experimenting too, maybe we can join forces. -- Cheers Em sex., 10 de set. de 2021 ?s 12:12, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > We have created a new jfx-sandbox repo: > > https://github.com/openjdk/jfx-sandbox > > This repository serves the same purpose as the jdk-sandbox: It allows > multiple OpenJFX Committers to collaborate on larger shared fixes, > prototypes, or projects. By way of example, it could be used for a macOS > Metal pipeline, a GTK 4 platform, or Wayland. > > All OpenJFX Committers have direct push access to the jfx-sandbox repo > (just like the JDK Committers do for jdk-sandbox). > > General rules and guidelines: > > There are only two hard-and-fast rules that must be observed: > > 1. Don't push any commits to the master branch and don't open a PR > against master. The master branch is continuously mirrored from the > jfx:master branch and should be considered read-only in jfx-sandbox. > > 2. Don't push to someone else's branch without talking to them first. > > And a couple general guidelines that will make this a more pleasant > place to play: > > 3. Unless this is intended to be a shared, semi-formal project (e.g., > metal, gtk4, wayland-x11, wayland-native), please prefix the name of > your branch with either a JBS bug ID or your openjdk username. > > 4. Don't force push to a branch without getting consensus among the > collaborators. > > Let me know if you have any questions. > > -- Kevin > > From hjohn at xs4all.nl Mon Sep 13 00:05:50 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Mon, 13 Sep 2021 02:05:50 +0200 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> Message-ID: On 12/09/2021 02:05, Nir Lisker wrote: > I've gotten back to look at this. > > For now I'm dealing only with the nullableMapping method in Bindings so > we can limit the amount of new classes to LazyObjectBinding > (FlatMapBinding and ConditionalBinding can come later). This method is > used by map, orElse and orElseGet in ObservableValue. Of these, map is > the only fundamental one since the other 2 can be represented by it. I > don't mind keeping them in the discussion, though I will be centered on > the map method. > > The implementation of these methods rely on Bindings, LazyObjectBinding, > and Subscription in the current implementation. I think that we can > introduce these internally for now. The biggest hurdle left are the > public changes to ObjectBinding. If we add protected methods, we need to > be sure that by the end of this large task they would have been the > right ones to add and at the right place. This is why I recommend adding > them at the package visibility level and add LazyObjectBinding (and > friends) in its package so they can extend it. I understand that this > can look ugly, but moving internal implementation is cheap, and in this > case, since the coupling involves about 3 classes, is very cheap. This > will lower the initial integration barrier and let the community get > used to- and give feedback on the new changes. I think that's a good idea, there is no direct need to make those protected methods part of the public API as the usefulness of those methods will be limited and the major use case will basically be provided by LazyObjectBinding already. > This will leave only 1 change that we are committed to, and that's the > new API on ObservableValue (which is the map method in this case). The > method looks good; the only question, which has arisen in a few places, > is how to handle null. As we discussed here, this method works like its > ReactFX counterpart, ignoring null. My questions would be: > 1. Is there a good reason to allow null? If so, do we add a new method > for it, or do we pass some parameter to the current method to indicate that? In JavaFX, null is something we have to deal in some fashion as properties can easily be null. For the "primitive" properties, null (if encountered) is translated to a default value. For StringProperty it could be an empty string although JavaFX doesn't do this. For ObjectProperty there is no sensible default possible. In ReactFX, nulls are indeed skipped when mapping as it considers null to be an empty value, and empty values are skipped according to the documentation. The code below will not throw an NPE in the mapping function and will simply result in null: Var.newSimpleVar(null).map(x -> x + "2").getValue(); This is similar to the PoC implementation: new SimpleStringProperty().map(x -> x + "2").getValue()); Having worked with ReactFX and also the PoC, I think it would be very cumbersome to have to deal with nulls in mapping functions, as many simple mappings expressed with a short lambda would need to deal with the null case with a ternary or an if/else block. In the PoC any mapping you could need that requires mapping null explicitely can be expressed in another form: .map(x -> x == null ? "empty!" : x + "2") becomes: .map(x -> x + "2").orElse("empty!) which is not only more concise, but allows to delay dealing with null until the very end: .map(x -> x == null ? "empty!" : fetchDataWhichCouldBeNull(x)) .map(x -> x == null ? "empty!" : x + "2") versus: .map(Helper::fetchDataThatCouldBeNull) .map(x -> x + "2") .orElse("empty!") You don't have to delay it though, if for some reason you would want to map the 2nd null case differently, you could use "orElse" after each mapping still. Although for mapping this may seem somewhat contrived, for selecting (or flatMapping) where you go through a chain of properties (like Node->Scene->Window) being able to delay dealing with nulls leads to more concise and IMHO more expressive code. So in summary, and to answer your first question, I don't think there is a good reason to allow null to be passed to mapping functions. We do need to deal with nulls though, and that's what "orElse" is for. This could also be done with an additional parameter to "map" (a "mapOrDefault" similar to "getOrDefault" from the collections API) but I think we'd be better served with multiple methods that take a single argument as the resulting code is easier to understand especially when one of the arguments is a lambda. > 2. If we want to replace the Bindings.select (non-type safe) API, can we > do it with our current way of treating null? In the current Bindings.select API, null is skipped when encountered and the resulting value of the chain will be null. This is exactly what "flatMap" in the PoC does as well, in other words: Bindings.select(nodeProperty, "scene", "window", "showing") is exactly equivalent to: nodeProperty.flatMap(Node::sceneProperty) .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) No null checks are needed, and the binding will be null if any of the selected properties contain null. Note that both versions return null despite the fact that the last property selected is a primitive boolean which normally cannot hold null. However, Bindings also offers selectBoolean. In this case it does indeed return false when any of the properties contains null, but it also logs this uncomfortable warning then: WARNING: Value of select-binding has wrong type, returning default value (+ stack trace omitted) The warning is somewhat deceptive as the binding does refer to a boolean so it is not strictly of the wrong type, but an intermediate value encountered was null and this cannot be cast to a primitive boolean. It should probably just convert to the default value without any warning. So, to answer your question, I think we can indeed replace Bindings.select with the PoC's typesafe equivalent. There is almost no need to create specific primitive versions of this mechanism as users can use "orElse" to map to a suitable primitive value as the last step if null is undesired. > Do you think that this is a valid approach? Yes, I think our messages may have crossed paths as I suggested limiting the API (based on your earlier recommendations) in a post on the "Enhancements for JavaFX 18" thread in a reply to Kevin Rushforth. Your suggestion takes this a bit further by leaving the new methods in ObjectBinding package protected and reducing the new API in ObservableValue to its bare essentials. I think that's a fine approach as it keeps the API that we're commiting to small and allows the highest flexibility for future extensions. If an agreement can be reached on the initial API, I can rework the PoC and also add the unit tests (I'll need to convert the JUnit 5 tests I have to JUnit 4). --John > > - Nir > > On Wed, Apr 7, 2021 at 11:30 PM John Hendrikx > wrote: > > On 07/04/2021 03:41, Nir Lisker wrote: > > In the PoC I made I specifically also disallowed 'null' as an > input > > > > > > I like the way ReactFX does it where the property is empty. I > think that > > this is also what you mean by disallowing `null` (in other contexts, > > "disallowing null" would mean throwing an exception). > > Yes, it is the same concept as ReactFX calling a property "empty", > but I > was hesitant to call this as `null` is a valid value for many JavaFX > properties (a Scene can be null, a String can be null, etc.) which I > don't think means the same as it being empty (in the Optional sense). > But as long as the documentation is clear, I don't mind calling it > either. > > > > > Not entirely sure what you mean by this. > > > > > > Basically, what you said. My point was that this is a different API > > section. The first deals with expanding the observables/properties > > methods. The second with listeners methods. Even if mapping a property > > requires a new listening model, like subscriptions, this is done under > > the hood. Exposing this API should be a separate step. At least that's > > how I see it. > > Yes, I think it is good to limit new API as much as possible to reduce > scope and increase the chances of its acceptance. The subscription > parts > can be designed separately and do not need to be public at this point. > They can be moved to a helper, or the implementation can take the extra > effort to use standard listeners. > > > > > I'd be happy to spend more time and work on this. Perhaps it > would be > > possible to collaborate on this? > > > > > > That would be good. I will need to re-review the ReactFX internals and > > see how your proposal differs exactly. > > Yes, I think that would be good to do. > > I've done some comparisons myself and didn't find a difference in > functionality with `Val` (so far). It is a new implementation though, I > didn't really look at how `Val` was done internally as implementing it > directly into JavaFX is quite different (I had to make a few minor > changes in `ObjectBinding` to allow for the choice of lazy binding). I > was also initially more focused on Streams only to realize at a later > point that having a Stream implement ObservableValue was not going > to be > pretty (I suspect this also happened when ReactFX was created, which is > why Val/Var were later introduced in 2.x). > > Both the PoC and Val do lazy binding and are null safe and provide > methods to deal with null/empty. > > The main thing I didn't do yet is provide a `filter` method. Filtering > properties that you want to use for bindings seems awkard as a binding > should always have some kind of value. The `filter` method in ReactFX > basically maps the value to `null` when it doesn't match the filter. > I've left this out as you can easily achieve this with `map` and > `filter` seems to be too easy to misunderstand. > > Aside from that, ReactFX's Val offers a lot of other methods that are I > think a bit too specialized to consider at this point, like the > `animate`, `pin`, `mapDynamic` and `suspendable` methods. > > Val also has all the other `Optional` methods (ifPresent, isPresent, > isEmpty) but I think they may make the API a bit confusing (an > observable value is not the same as an optional). I've also not had a > need for these so far in practice and you can easily convert the > current > value to get this functionality with `Optional.ofNullable`. > > Finally Val offers a few methods to convert to ReactFX's streams. While > convenient, I think static methods like `Values.of`, `Invalidations.of` > or `Changes.of` would make for a less cluttered API to do stream > conversions -- this would also make it possible to leave this part of > the API up to a 3rd party. > > > By the way, do you make a distinction between ReactFX's Val and > Var in > > your proposal (one being read-only)? > > No, `ObservableValue` is basically the same as `Val`, and the > equivalent > to `Var` is `ObjectProperty`. Aside from it being a good companion to > `Val` (and less typing), I don't see a reason to implement `Var`. > > --John > > > > > On Sun, Apr 4, 2021 at 12:43 PM John Hendrikx > > >> wrote: > > > > > > > > On 02/04/2021 08:47, Nir Lisker wrote: > > > Hi John, > > > > > > I've had my eyes set on ReactFX enhancements for a while too, > > especially as > > > a replacement for the unsafe "select" mechanism. One of the > things > > that > > > kept me from going forward with this is seeing what Valhalla > will > > bring. > > > Generic specialization might save a lot of duplication work on > > something > > > like this, and Tomas touched another related issue [1], but > since > > it could > > > be a long time before that happens, it's worth planning what we > > can extract > > > from ReactFX currently. > > > > Agreed, Valhalla is certainly a highly anticipated feature but I > > fear it > > is still a couple of years away. > > > > Even without any initial support for dealing with "? extends > Number" > > from the various ObservableValue specializations I think > looking into > > this can already be tremendous help. > > > > The proof of concept mainly requires you convert the Number to a > > suitable type when reading the property but has no problems in the > > other > > direction: > > > > label.widthProperty().map(Number::doubleValue).map(x -> x > + 1); > > > > Not pretty, but certainly workable. Specific methods could be > > introduced > > (even at a later time) to make this more streamlined, similar > to what > > the Stream API offers with 'mapToDouble' etc. > > > > > I think that we should break the enhancements into parts. > > > The first that I would advise to look at are the additions to > > > properties/observables. Tomas had to create Val and Var > because he > > couldn't > > > change the core interfaces, but we can. Fitting them with > the Optional > > > methods like `isPresent`, `isEmpty`, `ifPresent`, `map`. > `flatMap` > > etc.; > > > and `select` and friends, is already a good start that will > > address many > > > common requirements. > > > > Yes, Val/Var had to be created for that reason, and also because > > properties don't quite behave the same as streams -- streams > with a > > "toBinding" method results in things people didn't quite expect. > > > > As far as the Optional methods go, I'm not entirely sure > properties > > would benefit from all of them. Properties are not immutable like > > Optional and it may make less sense to fit them with 'isPresent', > > 'isEmpty' and 'ifPresent' ('ifPresent' would I think need to > behave > > similar to 'addListener' or 'subscribe'). > > > > In the PoC I made I specifically also disallowed 'null' as an > input for > > functions like 'map' and 'flatMap' (opting to use 'orElse' > semantics > > for > > 'null'), as this for allows much cleaner mapping (and > especially flat > > mapping when selecting nested properties). If 'null' were to be > > allowed, > > I think at a minimum we'd need to add another method to allow > for easy > > selecting of nested properties to avoid: > > > > obs.flatMap(x -> x == null ? null : x.otherProperty()) > > > > > The second part is related to listeners. The subscription model > > and event > > > streams try to solve the memory issues with hard and weak > > references, and > > > allow better composition. > > > > Not entirely sure what you mean by this. JavaFX's current > model uses > > weak references which was I think an unfortunate decision as > it can > > result in huge confusion. For example, a direct binding will > work, but > > with an indirection step a binding stops working: > > > > button.textProperty() > > .concat("World") // weak binding used here > > .addListener((obs, old, cur) -> System.out.println(cur)); > > > > The above stops working, but without the 'concat' it keeps > working. > > > > I think the use of weak listeners should be avoided and > instead other > > mechanisms should be provided to make cleaning up easier. This > is the > > main reason for 'conditionOn' and why ReactFX even had a > specialized > > version of it: 'conditionOnShowing(Node)'. > > > > > The third part is for collections - things like > transformation lists > > > (LiveList) and for other collections. > > > > This is indeed best saved for last. The problems there I think > are less > > of an issue for now. > > > > > Since these share behavior under the hood, we need to look > ahead, > > but in > > > terms of functionality, I think we should take smaller steps. It > > will also > > > be easier to propose these then. > > > > I've for this reason kept the PoC small with only the most basic > > functionality. I did however add some work for a different > > subscription > > model, mainly because the internals of this code benefits > greatly from > > it. It is however kept to a minimum. > > > > I'd be happy to spend more time and work on this. Perhaps it > would be > > possible to collaborate on this? > > > > --John > > > > > > > > - Nir > > > > > > [1] > > > > > > https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issue > > > > > > On Wed, Mar 24, 2021 at 11:49 PM John Hendrikx > > > >> wrote: > > > > > >> I just wanted to draw some attention to a recent proof of > concept > > I made > > >> in this pull request: https://github.com/openjdk/jfx/pull/434 > > >> > > >> It is based on the work I did in > > >> https://github.com/hjohn/hs.jfx.eventstream which is in > part based on > > >> work done in ReactFX by Tomas Mikula. The PR itself however > shares no > > >> code with ReactFX and is > > >> completely written by me. > > >> > > >> If there is interest, I'm willing to invest more time in > > smoothing out > > >> the API and documentation, investigating further how this would > > interact > > >> with the primitive types and adding unit test coverage (I have > > extensive > > >> tests, but thesea are written in JUnit 5, so they would require > > >> conversion or JavaFX could move to support JUnit 5). > > >> > > >> What follows below is the text of the PR for easy reading. > > Feedback is > > >> appreciated. > > >> > > >> ================ > > >> > > >> This is a proof of concept of how fluent bindings could be > > introduced to > > >> JavaFX. The main benefit of fluent bindings are ease of > use, type > > safety > > >> and less surprises. Features: > > >> > > >> Flexible Mappings > > >> Map the contents of a property any way you like with map, > or map > > nested > > >> properties with flatMap. > > >> > > >> Lazy > > >> The bindings created are lazy, which means they are always > > invalid when > > >> not themselves observed. This allows for easier garbage > > collection (once > > >> the last observer is removed, a chain of bindings will stop > observing > > >> their parents) and less listener management when dealing > with nested > > >> properties. Furthermore, this allows inclusion of such > bindings in > > >> classes such as Node without listeners being created when > the binding > > >> itself is not used (this would allow for the inclusion of a > > >> treeShowingProperty in Node without creating excessive > listeners, see > > >> this fix I did in an earlier PR: #185) > > >> > > >> Null Safe > > >> The map and flatMap methods are skipped, similar to > > java.util.Optional > > >> when the value they would be mapping is null. This makes > mapping > > nested > > >> properties with flatMap trivial as the null case does not > need to be > > >> taken into account in a chain like this: > > >> > > > node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). > > >> > > >> Instead a default can be provided with orElse or orElseGet. > > >> > > >> Conditional Bindings > > >> Bindings can be made conditional using the conditionOn > method. A > > >> conditional binding retains its last value when its > condition is > > false. > > >> Conditional bindings donot observe their source when the > condition is > > >> false, allowing developers to automatically stop listening to > > properties > > >> when a certain condition is met. A major use of this feature is > > to have > > >> UI components that need to keep models updated which may > outlive > > the UI > > >> conditionally update the long lived model only when the UI is > > showing. > > >> > > >> Some examples: > > >> > > >> void mapProperty() { > > >> // Standard JavaFX: > > >> label.textProperty().bind(Bindings.createStringBinding(() -> > > >> text.getValueSafe().toUpperCase(), text)); > > >> > > >> // Fluent: much more compact, no need to handle null > > >> label.textProperty().bind(text.map(String::toUpperCase)); > > >> } > > >> > > >> void calculateCharactersLeft() { > > >> // Standard JavaFX: > > >> > > >> > > > label.textProperty().bind(text.length().negate().add(100).asString().concat(" > > >> > > >> characters left")); > > >> > > >> // Fluent: slightly more compact and more clear (no > negate needed) > > >> label.textProperty().bind(text.orElse("").map(v -> 100 - > > v.length() + > > >> " characters left")); > > >> } > > >> > > >> void mapNestedValue() { > > >> // Standard JavaFX: > > >> label.textProperty().bind(Bindings.createStringBinding( > > >> () -> employee.get() == null ? "" > > >> : employee.get().getCompany() == null ? "" > > >> : employee.get().getCompany().getName(), > > >> employee > > >> )); > > >> > > >> // Fluent: no need to handle nulls everywhere > > >> label.textProperty().bind( > > >> employee.map(Employee::getCompany) > > >> .map(Company::getName) > > >> .orElse("") > > >> ); > > >> } > > >> > > >> void mapNestedProperty() { > > >> // Standard JavaFX: > > >> label.textProperty().bind( > > >> > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), > > >> "window", "showing")) > > >> .then("Visible") > > >> .otherwise("Not Visible") > > >> ); > > >> > > >> // Fluent: type safe > > >> label.textProperty().bind(label.sceneProperty() > > >> .flatMap(Scene::windowProperty) > > >> .flatMap(Window::showingProperty) > > >> .orElse(false) > > >> .map(showing -> showing ? "Visible" : "Not Visible") > > >> ); > > >> } > > >> > > >> void updateLongLivedModelWhileAvoidingMemoryLeaks() { > > >> // Standard JavaFX: naive, memory leak; UI won't get garbage > > collected > > >> > listView.getSelectionModel().selectedItemProperty().addListener( > > >> (obs, old, current) -> > > >> longLivedModel.lastSelectedProperty().set(current) > > >> ); > > >> > > >> // Standard JavaFX: no leak, but stops updating after a > while > > >> > listView.getSelectionModel().selectedItemProperty().addListener( > > >> new WeakChangeListener<>( > > >> (obs, old, current) -> > > >> longLivedModel.lastSelectedProperty().set(current) > > >> ) > > >> ); > > >> > > >> // Standard JavaFX: fixed version > > >> listenerReference = (obs, old, current) -> > > >> longLivedModel.lastSelectedProperty().set(current); > > >> > > >> > listView.getSelectionModel().selectedItemProperty().addListener( > > >> new WeakChangeListener<>(listenerReference) > > >> ); > > >> > > >> // Fluent: naive, memory leak... fluent won't solve this... > > >> listView.getSelectionModel().selectedItemProperty() > > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > > >> > > >> // Fluent: conditional update when control visible > > >> > > >> // Create a property which is only true when the UI is > visible: > > >> ObservableValue showing = listView.sceneProperty() > > >> .flatMap(Scene::windowProperty) > > >> .flatMap(Window::showingProperty) > > >> .orElse(false); > > >> > > >> // Use showing property to automatically disconnect long > lived > > model > > >> // allowing garbage collection of the UI: > > >> listView.getSelectionModel().selectedItemProperty() > > >> .conditionOn(showing) > > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > > >> > > >> // Note that the 'showing' property can be provided in > > multiple ways: > > >> // - create manually (can be re-used for multiple > bindings though) > > >> // - create with a helper: Nodes.showing(Node node) -> > > >> ObservableValue > > >> // - make it part of the Node class; as the fluent bindings > > only bind > > >> themselves > > >> // to their source when needed (lazy binding), this > won't create > > >> overhead > > >> // for each node in the scene > > >> } > > >> Note that this is based on ideas in ReactFX and my own > experiments in > > >> https://github.com/hjohn/hs.jfx.eventstream. I've come to the > > conclusion > > >> that this is much better directly integrated into JavaFX, > and I'm > > hoping > > >> this proof of concept will be able to move such an effort > forward. > > >> > > >> --John > > >> > > > > > > From johan.vos at gluonhq.com Mon Sep 13 09:11:05 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 13 Sep 2021 11:11:05 +0200 Subject: Announcing the new jfx-sandbox repo In-Reply-To: References: Message-ID: I created a johanvos-gtk3-wayland branch and that worked. I will add a commit soon with a diff for the Robot API. I will have a look at Thiago's gtk4 branch as well. - Johan On Mon, Sep 13, 2021 at 12:52 AM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Hi Kevin, > > https://github.com/tsayao/jfx-sandbox/tree/tsayao_gtk4_playground > > I have started this as an experiment to make a gtk4 version of the native > lib. > > I did a fork because I don't have permission to branch on jfx-sandbox (or > maybe I did something wrong). > > @Johan Vos has stated that he is experimenting > too, maybe we can join forces. > > -- Cheers > > > > > Em sex., 10 de set. de 2021 ?s 12:12, Kevin Rushforth < > kevin.rushforth at oracle.com> escreveu: > >> We have created a new jfx-sandbox repo: >> >> https://github.com/openjdk/jfx-sandbox >> >> This repository serves the same purpose as the jdk-sandbox: It allows >> multiple OpenJFX Committers to collaborate on larger shared fixes, >> prototypes, or projects. By way of example, it could be used for a macOS >> Metal pipeline, a GTK 4 platform, or Wayland. >> >> All OpenJFX Committers have direct push access to the jfx-sandbox repo >> (just like the JDK Committers do for jdk-sandbox). >> >> General rules and guidelines: >> >> There are only two hard-and-fast rules that must be observed: >> >> 1. Don't push any commits to the master branch and don't open a PR >> against master. The master branch is continuously mirrored from the >> jfx:master branch and should be considered read-only in jfx-sandbox. >> >> 2. Don't push to someone else's branch without talking to them first. >> >> And a couple general guidelines that will make this a more pleasant >> place to play: >> >> 3. Unless this is intended to be a shared, semi-formal project (e.g., >> metal, gtk4, wayland-x11, wayland-native), please prefix the name of >> your branch with either a JBS bug ID or your openjdk username. >> >> 4. Don't force push to a branch without getting consensus among the >> collaborators. >> >> Let me know if you have any questions. >> >> -- Kevin >> >> From fkirmaier at openjdk.java.net Mon Sep 13 12:14:28 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 13 Sep 2021 12:14:28 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v2] In-Reply-To: References: Message-ID: <1mJnGxXInVW4qImauq1wf1_xgTQxvZHZfMF1jUpBHHU=.bd9cf022-70f5-4742-9420-646ee0f2f31b@github.com> > When using Swing it's possible to generate a Deadlock. > It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. > Sample Programm and Threaddump are added to the ticket. > > Removing the nested loop fixes the Problem. > I hope this doesn't have any side effect - so far i don't know of any. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8273485 Added unit-test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/622/files - new: https://git.openjdk.java.net/jfx/pull/622/files/bbe006d6..f302d180 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=00-01 Stats: 66 lines in 1 file changed: 66 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/622.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/622/head:pull/622 PR: https://git.openjdk.java.net/jfx/pull/622 From thiago.sayao at gmail.com Mon Sep 13 15:31:21 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 13 Sep 2021 12:31:21 -0300 Subject: Announcing the new jfx-sandbox repo In-Reply-To: References: Message-ID: I just started moving things around after reading the gtk docs (specially gtk3 to 4 porting). It does not compile yet. Will focus on windowing code first. - Thiago. Em seg., 13 de set. de 2021 ?s 06:11, Johan Vos escreveu: > I created a johanvos-gtk3-wayland branch and that worked. I will add a > commit soon with a diff for the Robot API. > I will have a look at Thiago's gtk4 branch as well. > > - Johan > > On Mon, Sep 13, 2021 at 12:52 AM Thiago Milczarek Say?o < > thiago.sayao at gmail.com> wrote: > >> Hi Kevin, >> >> https://github.com/tsayao/jfx-sandbox/tree/tsayao_gtk4_playground >> >> I have started this as an experiment to make a gtk4 version of the native >> lib. >> >> I did a fork because I don't have permission to branch on jfx-sandbox (or >> maybe I did something wrong). >> >> @Johan Vos has stated that he is experimenting >> too, maybe we can join forces. >> >> -- Cheers >> >> >> >> >> Em sex., 10 de set. de 2021 ?s 12:12, Kevin Rushforth < >> kevin.rushforth at oracle.com> escreveu: >> >>> We have created a new jfx-sandbox repo: >>> >>> https://github.com/openjdk/jfx-sandbox >>> >>> This repository serves the same purpose as the jdk-sandbox: It allows >>> multiple OpenJFX Committers to collaborate on larger shared fixes, >>> prototypes, or projects. By way of example, it could be used for a macOS >>> Metal pipeline, a GTK 4 platform, or Wayland. >>> >>> All OpenJFX Committers have direct push access to the jfx-sandbox repo >>> (just like the JDK Committers do for jdk-sandbox). >>> >>> General rules and guidelines: >>> >>> There are only two hard-and-fast rules that must be observed: >>> >>> 1. Don't push any commits to the master branch and don't open a PR >>> against master. The master branch is continuously mirrored from the >>> jfx:master branch and should be considered read-only in jfx-sandbox. >>> >>> 2. Don't push to someone else's branch without talking to them first. >>> >>> And a couple general guidelines that will make this a more pleasant >>> place to play: >>> >>> 3. Unless this is intended to be a shared, semi-formal project (e.g., >>> metal, gtk4, wayland-x11, wayland-native), please prefix the name of >>> your branch with either a JBS bug ID or your openjdk username. >>> >>> 4. Don't force push to a branch without getting consensus among the >>> collaborators. >>> >>> Let me know if you have any questions. >>> >>> -- Kevin >>> >>> From fkirmaier at openjdk.java.net Mon Sep 13 13:35:52 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 13 Sep 2021 13:35:52 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v3] In-Reply-To: References: Message-ID: > When using Swing it's possible to generate a Deadlock. > It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. > Sample Programm and Threaddump are added to the ticket. > > Removing the nested loop fixes the Problem. > I hope this doesn't have any side effect - so far i don't know of any. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8273485 Removed the enter/leave nested event loop logic, for mac fullscreen ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/622/files - new: https://git.openjdk.java.net/jfx/pull/622/files/f302d180..417ac2fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=01-02 Stats: 34 lines in 5 files changed: 0 ins; 33 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/622.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/622/head:pull/622 PR: https://git.openjdk.java.net/jfx/pull/622 From kcr at openjdk.java.net Mon Sep 13 14:06:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Sep 2021 14:06:34 GMT Subject: [jfx17u] RFR: 8273279: Change JavaFX release version in jfx17u to 17.0.1 In-Reply-To: References: Message-ID: <402ISP-0HeimmNR3BVjyr6KrHq7HxcR6BEEC9GpeBDk=.ae72105f-fd82-49c2-8bea-cabea548188f@github.com> On Sat, 11 Sep 2021 13:27:59 GMT, Kevin Rushforth wrote: > Bump release version in `jfx17u` repo to 17.0.1 for the start of a new release. @johanvos can you review? ------------- PR: https://git.openjdk.java.net/jfx17u/pull/2 From kcr at openjdk.java.net Mon Sep 13 14:06:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Sep 2021 14:06:43 GMT Subject: [jfx17u] RFR: 8273280: Update README.md and CONTRIBUTING.md for jfx17u In-Reply-To: References: Message-ID: <4eR5Y1skeH4kUAQb9Hp5JzkygoO5cNOpal6KPT4G_rc=.84058f09-37e7-45e5-abf1-f153d7013e5a@github.com> On Sat, 11 Sep 2021 13:25:35 GMT, Kevin Rushforth wrote: > This PR updates [`README.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/README.md) and [`CONTRIBUTING.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/CONTRIBUTING.md) to be suitable for update releases. The two files were copied from jfx11u, with the only changes being to replace "11" with "17" in the two files. @johanvos can you review? ------------- PR: https://git.openjdk.java.net/jfx17u/pull/1 From kevin.rushforth at oracle.com Mon Sep 13 14:37:37 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Sep 2021 07:37:37 -0700 Subject: CFV: New OpenJFX Committer: Thiago Sayao Message-ID: I hereby nominate Thiago Sayao [1] to OpenJFX Committer. Thiago is an OpenJFX community member, who has contributed 15 commits [2] to OpenJFX. Votes are due by September 27, 2021 at 15:00 UTC. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] https://openjdk.java.net/census#tsayao [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Thiago+Sayao%22&s=author-date&type=commits [3] https://openjdk.java.net/census#openjfx [4] https://openjdk.java.net/bylaws#lazy-consensus [6] https://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Mon Sep 13 14:38:15 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Sep 2021 07:38:15 -0700 Subject: CFV: New OpenJFX Committer: Thiago Sayao In-Reply-To: References: Message-ID: Vote: YES On 9/13/2021 7:37 AM, Kevin Rushforth wrote: > I hereby nominate Thiago Sayao [1] to OpenJFX Committer. From fkirmaier at openjdk.java.net Mon Sep 13 14:38:20 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 13 Sep 2021 14:38:20 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v3] In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 13:35:52 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273485 > Removed the enter/leave nested event loop logic, for mac fullscreen I've now added a unit test. I've adapted the solution to entirely remove the nested event loop, for the fullscreen. So far everything seems to work. I've tested it with a simple application to check how the fullscreen behaves. The logic seems to be added before the beginning of the VCS / 2013 Is there away to look into the history before 2013? Maybe there is a hint, why this was added. Otherwise i would guess that it is not too important, and it is just an unnecessary overcomplicated solution. ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From kevin.rushforth at oracle.com Mon Sep 13 14:41:04 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Sep 2021 07:41:04 -0700 Subject: [External] : Re: Announcing the new jfx-sandbox repo In-Reply-To: References: Message-ID: <7a0bd71b-4321-3387-ad25-2cc9d1c6dd37@oracle.com> > I did a fork because I don't have permission to branch on jfx-sandbox > (or maybe I did something wrong). No, you didn't do anything wrong. The jfx-sandbox is writable by those with the Committer role in the jfx-sandbox. It seems like an oversight that you weren't already a committer, so I just sent out the call for votes to address this. -- Kevin On 9/12/2021 3:52 PM, Thiago Milczarek Say?o wrote: > Hi Kevin, > > https://github.com/tsayao/jfx-sandbox/tree/tsayao_gtk4_playground > > > I have started this as an experiment to make a gtk4 version of the > native lib. > > I did a fork because I don't have permission to branch on jfx-sandbox > (or maybe I did something wrong). > > @Johan Vos has stated that he is > experimenting too, maybe we can join forces. > > -- Cheers > > > > > Em sex., 10 de set. de 2021 ?s 12:12, Kevin Rushforth > > escreveu: > > We have created a new jfx-sandbox repo: > > https://github.com/openjdk/jfx-sandbox > > > This repository serves the same purpose as the jdk-sandbox: It allows > multiple OpenJFX Committers to collaborate on larger shared fixes, > prototypes, or projects. By way of example, it could be used for a > macOS > Metal pipeline, a GTK 4 platform, or Wayland. > > All OpenJFX Committers have direct push access to the jfx-sandbox > repo > (just like the JDK Committers do for jdk-sandbox). > > General rules and guidelines: > > There are only two hard-and-fast rules that must be observed: > > 1. Don't push any commits to the master branch and don't open a PR > against master. The master branch is continuously mirrored from the > jfx:master branch and should be considered read-only in jfx-sandbox. > > 2. Don't push to someone else's branch without talking to them first. > > And a couple general guidelines that will make this a more pleasant > place to play: > > 3. Unless this is intended to be a shared, semi-formal project (e.g., > metal, gtk4, wayland-x11, wayland-native), please prefix the name of > your branch with either a JBS bug ID or your openjdk username. > > 4. Don't force push to a branch without getting consensus among the > collaborators. > > Let me know if you have any questions. > > -- Kevin > From kevin.rushforth at oracle.com Mon Sep 13 14:42:21 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 13 Sep 2021 07:42:21 -0700 Subject: [External] : Re: Announcing the new jfx-sandbox repo In-Reply-To: <7a0bd71b-4321-3387-ad25-2cc9d1c6dd37@oracle.com> References: <7a0bd71b-4321-3387-ad25-2cc9d1c6dd37@oracle.com> Message-ID: <668b0141-3218-3dfa-39ea-e91471a7623b@oracle.com> > The jfx-sandbox is writable by those with the Committer role in the > jfx-sandbox That should be Committer role in the *OpenJFX Project*. -- Kevin On 9/13/2021 7:41 AM, Kevin Rushforth wrote: > >> I did a fork because I don't have permission to branch on jfx-sandbox >> (or maybe I did something wrong). > > No, you didn't do anything wrong. The jfx-sandbox is writable by those > with the Committer role in the jfx-sandbox. It seems like an oversight > that you weren't already a committer, so I just sent out the call for > votes to address this. > > -- Kevin > > > > On 9/12/2021 3:52 PM, Thiago Milczarek Say?o wrote: >> Hi Kevin, >> >> https://github.com/tsayao/jfx-sandbox/tree/tsayao_gtk4_playground >> >> >> I have started this as an experiment to make a gtk4 version of the >> native lib. >> >> I did a fork because I don't have permission to branch on jfx-sandbox >> (or maybe I did something wrong). >> >> @Johan Vos has stated that he is >> experimenting too, maybe we can join forces. >> >> -- Cheers >> >> >> >> >> Em sex., 10 de set. de 2021 ?s 12:12, Kevin Rushforth >> > >> escreveu: >> >> We have created a new jfx-sandbox repo: >> >> https://github.com/openjdk/jfx-sandbox >> >> >> This repository serves the same purpose as the jdk-sandbox: It >> allows >> multiple OpenJFX Committers to collaborate on larger shared fixes, >> prototypes, or projects. By way of example, it could be used for >> a macOS >> Metal pipeline, a GTK 4 platform, or Wayland. >> >> All OpenJFX Committers have direct push access to the jfx-sandbox >> repo >> (just like the JDK Committers do for jdk-sandbox). >> >> General rules and guidelines: >> >> There are only two hard-and-fast rules that must be observed: >> >> 1. Don't push any commits to the master branch and don't open a PR >> against master. The master branch is continuously mirrored from the >> jfx:master branch and should be considered read-only in jfx-sandbox. >> >> 2. Don't push to someone else's branch without talking to them first. >> >> And a couple general guidelines that will make this a more pleasant >> place to play: >> >> 3. Unless this is intended to be a shared, semi-formal project >> (e.g., >> metal, gtk4, wayland-x11, wayland-native), please prefix the name of >> your branch with either a JBS bug ID or your openjdk username. >> >> 4. Don't force push to a branch without getting consensus among the >> collaborators. >> >> Let me know if you have any questions. >> >> -- Kevin >> > From johan.vos at gluonhq.com Mon Sep 13 14:42:41 2021 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 13 Sep 2021 16:42:41 +0200 Subject: CFV: New OpenJFX Committer: Thiago Sayao In-Reply-To: References: Message-ID: Vote: YES On Mon, Sep 13, 2021 at 4:38 PM Kevin Rushforth wrote: > I hereby nominate Thiago Sayao [1] to OpenJFX Committer. > > Thiago is an OpenJFX community member, who has contributed 15 commits > [2] to OpenJFX. > > Votes are due by September 27, 2021 at 15:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#tsayao > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Thiago+Sayao%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > > From pankaj.b.bansal at oracle.com Mon Sep 13 14:45:23 2021 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Mon, 13 Sep 2021 14:45:23 +0000 Subject: CFV: New OpenJFX Committer: Thiago Sayao In-Reply-To: References: Message-ID: Vote: YES From: openjfx-dev on behalf of Kevin Rushforth Date: Monday, 13 September 2021 at 8:07 PM To: openjfx-dev at openjdk.java.net , Thiago Milczarek Sayao Subject: CFV: New OpenJFX Committer: Thiago Sayao I hereby nominate Thiago Sayao [1] to OpenJFX Committer. Thiago is an OpenJFX community member, who has contributed 15 commits [2] to OpenJFX. Votes are due by September 27, 2021 at 15:00 UTC. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [6]. Thanks. -- Kevin [1] https://openjdk.java.net/census#tsayao [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Thiago+Sayao%22&s=author-date&type=commits [3] https://openjdk.java.net/census#openjfx [4] https://openjdk.java.net/bylaws#lazy-consensus [6] https://openjdk.java.net/projects#project-committer From nlisker at gmail.com Mon Sep 13 15:26:10 2021 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 13 Sep 2021 18:26:10 +0300 Subject: CFV: New OpenJFX Committer: Thiago Sayao In-Reply-To: References: Message-ID: Vote: YES On Mon, Sep 13, 2021 at 5:45 PM Pankaj Bansal wrote: > Vote: YES > > From: openjfx-dev on behalf of Kevin > Rushforth > Date: Monday, 13 September 2021 at 8:07 PM > To: openjfx-dev at openjdk.java.net , Thiago > Milczarek Sayao > Subject: CFV: New OpenJFX Committer: Thiago Sayao > I hereby nominate Thiago Sayao [1] to OpenJFX Committer. > > Thiago is an OpenJFX community member, who has contributed 15 commits > [2] to OpenJFX. > > Votes are due by September 27, 2021 at 15:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#tsayao > > [2] > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Thiago+Sayao%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > From fastegal at swingempire.de Mon Sep 13 15:54:07 2021 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 13 Sep 2021 17:54:07 +0200 Subject: CFV: New OpenJFX Committer: Thiago Sayao In-Reply-To: References: Message-ID: <20210913175407.Horde.n21VYQfDqGP2KmpTcyFZdQ1@webmail.df.eu> Vote: YES Zitat von Kevin Rushforth : > I hereby nominate Thiago Sayao [1] to OpenJFX Committer. > > Thiago is an OpenJFX community member, who has contributed 15 > commits [2] to OpenJFX. > > Votes are due by September 27, 2021 at 15:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a > project Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#tsayao > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Thiago+Sayao%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer From jose.pereda at gluonhq.com Mon Sep 13 16:15:51 2021 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Mon, 13 Sep 2021 18:15:51 +0200 Subject: CFV: New OpenJFX Committer: Thiago Sayao In-Reply-To: <20210913175407.Horde.n21VYQfDqGP2KmpTcyFZdQ1@webmail.df.eu> References: <20210913175407.Horde.n21VYQfDqGP2KmpTcyFZdQ1@webmail.df.eu> Message-ID: Vote: YES Jose On Mon, Sep 13, 2021 at 5:55 PM Jeanette Winzenburg wrote: > > Vote: YES > > Zitat von Kevin Rushforth : > > > I hereby nominate Thiago Sayao [1] to OpenJFX Committer. > > > > Thiago is an OpenJFX community member, who has contributed 15 > > commits [2] to OpenJFX. > > > > Votes are due by September 27, 2021 at 15:00 UTC. > > > > Only current OpenJFX Committers [3] are eligible to vote on this > > nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Lazy Consensus voting instructions, see [4]. Nomination to a > > project Committer is described in [6]. > > > > Thanks. > > > > -- Kevin > > > > > > [1] https://openjdk.java.net/census#tsayao > > > > [2] > > > https://github.com/openjdk/jfx/search?q=author-name%3A%22Thiago+Sayao%22&s=author-date&type=commits > > > > [3] https://openjdk.java.net/census#openjfx > > > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > > > [6] https://openjdk.java.net/projects#project-committer > > > > -- From mhanl at openjdk.java.net Mon Sep 13 19:44:24 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 13 Sep 2021 19:44:24 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 19:15:54 GMT, Marius Hanl wrote: >>> > just checked my notes (there's a cell-editing branch in my fork where I'm experimenting) - astonishingly the answer is no, could not see anything :) And actually, seems like we don't even need to return immediately: would have expected some unhealthy side-effects on doing the switching into visual editing state more than once, but couldn't detect anything. You might try, though :) >>> >>> Okay. Question is, should we guard against a double edit? There is already one in `TreeTableCell#startEdit`, but probably forgotten in TableCell. I think it makes sense and as there is already the check in TreeTableCell, there was at least a thought of it somewhere in the past. >> >> good question, next question ;) >> >> - the oversight in startEdit of the base List/TableCell is not part of this (covered and soon fixed by [JDK-8188027](https://bugs.openjdk.java.net/browse/JDK-8188027), the concrete misbehavior is that they fire multiple edit events >> - as to the "real" editing cell types (that is those that actually have an editingComponent) - we (that is now you *grin) should try hard to find a scenario where multiple starts (== multiple configuration passes of the editingComponent) might hurt. Like when the user already typed something and for some reason startEdit is called again, the configuration would delete the input. >> >> > If there is nothing left, should I create a ticket for `startEdit` and for `cancelEdit` (this only affects the sub classes) ? :) >> >> hmm - not sure I understand what you are asking: startEdit is covered, and cancelEdit would be similar - either you find a scenario where multiple un-configure of the cell (after cancel) would hurt or not? > >> > > just checked my notes (there's a cell-editing branch in my fork where I'm experimenting) - astonishingly the answer is no, could not see anything :) And actually, seems like we don't even need to return immediately: would have expected some unhealthy side-effects on doing the switching into visual editing state more than once, but couldn't detect anything. You might try, though :) >> > >> > >> > Okay. Question is, should we guard against a double edit? There is already one in `TreeTableCell#startEdit`, but probably forgotten in TableCell. I think it makes sense and as there is already the check in TreeTableCell, there was at least a thought of it somewhere in the past. >> >> good question, next question ;) >> >> * the oversight in startEdit of the base List/TableCell is not part of this (covered and soon fixed by [JDK-8188027](https://bugs.openjdk.java.net/browse/JDK-8188027), the concrete misbehavior is that they fire multiple edit events >> * as to the "real" editing cell types (that is those that actually have an editingComponent) - we (that is now you *grin) should try hard to find a scenario where multiple starts (== multiple configuration passes of the editingComponent) might hurt. Like when the user already typed something and for some reason startEdit is called again, the configuration would delete the input. >> >> > If there is nothing left, should I create a ticket for `startEdit` and for `cancelEdit` (this only affects the sub classes) ? :) >> >> hmm - not sure I understand what you are asking: startEdit is covered, and cancelEdit would be similar - either you find a scenario where multiple un-configure of the cell (after cancel) would hurt or not? > > Finally coming back to this, when firing a **startEdit()** while already editing e.g. a TextFieldCell, the input which was made by you gets lost and you need to start over. So this can be a potential follow-up. I didn't found anything for **cancelEdit()**. > @Maran23 wondering why my review comments aren't addressed? Anything unclear? Everything clear, I was just busy the last days. But I think I will address everything in this week. If you can't continue without it e.g. this PR is blocking your (future) work, you can also continue on this. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/569 From kcr at openjdk.java.net Mon Sep 13 20:27:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 13 Sep 2021 20:27:03 GMT Subject: [jfx17u] RFR: 8268849: Update to 612.1 version of WebKit Message-ID: Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. ------------- Commit messages: - 8268849: Update to 612.1 version of WebKit Changes: https://git.openjdk.java.net/jfx17u/pull/3/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=3&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268849 Stats: 286061 lines in 5711 files changed: 175196 ins; 68118 del; 42747 mod Patch: https://git.openjdk.java.net/jfx17u/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/3/head:pull/3 PR: https://git.openjdk.java.net/jfx17u/pull/3 From nlisker at gmail.com Tue Sep 14 01:14:30 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 14 Sep 2021 04:14:30 +0300 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> Message-ID: Sounds good. Some points I have (maybe some are premature): 1. I still think that adding the Optional methods for orElse and orElseGet could be useful. Unless I can be convinced otherwise, I suggest that we be careful with the naming of current methods that return a binding. 2. I see that in ReactFX the Val.map will pass to MappedVal the mapping function as-is, and the null check is done in computeValue(). In your implementation, the LazyBinding (equivalent of MappedVal) is passed a composite mapping that deals with null and the computeValue() can just use that new mapping function. I think that the end behavior is the same, but does your way use more memory for the extra Function lambda? 3. Why does nullableMapping creates an anonymous subtype of LazyBinding, while flatMapping creates a concrete instance of FlatMapBinding? 4. Why does orElseGet call Bindings.nullableMapping directly, while map calls Bindings.mapping which in turn calls Bindings.nullableMapping? 5. I noticed also that subscribeInvalidations in ObservableValue will need to be hidden. Some related JBS issues that I found that we might be able to use (or at least close at some point): https://bugs.openjdk.java.net/browse/JDK-8091544 https://bugs.openjdk.java.net/browse/JDK-8091316 On Mon, Sep 13, 2021 at 3:05 AM John Hendrikx wrote: > > > On 12/09/2021 02:05, Nir Lisker wrote: > > I've gotten back to look at this. > > > > For now I'm dealing only with the nullableMapping method in Bindings so > > we can limit the amount of new classes to LazyObjectBinding > > (FlatMapBinding and ConditionalBinding can come later). This method is > > used by map, orElse and orElseGet in ObservableValue. Of these, map is > > the only fundamental one since the other 2 can be represented by it. I > > don't mind keeping them in the discussion, though I will be centered on > > the map method. > > > > The implementation of these methods rely on Bindings, LazyObjectBinding, > > and Subscription in the current implementation. I think that we can > > introduce these internally for now. The biggest hurdle left are the > > public changes to ObjectBinding. If we add protected methods, we need to > > be sure that by the end of this large task they would have been the > > right ones to add and at the right place. This is why I recommend adding > > them at the package visibility level and add LazyObjectBinding (and > > friends) in its package so they can extend it. I understand that this > > can look ugly, but moving internal implementation is cheap, and in this > > case, since the coupling involves about 3 classes, is very cheap. This > > will lower the initial integration barrier and let the community get > > used to- and give feedback on the new changes. > > I think that's a good idea, there is no direct need to make those > protected methods part of the public API as the usefulness of those > methods will be limited and the major use case will basically be > provided by LazyObjectBinding already. > > > This will leave only 1 change that we are committed to, and that's the > > new API on ObservableValue (which is the map method in this case). The > > method looks good; the only question, which has arisen in a few places, > > is how to handle null. As we discussed here, this method works like its > > ReactFX counterpart, ignoring null. My questions would be: > > 1. Is there a good reason to allow null? If so, do we add a new method > > for it, or do we pass some parameter to the current method to indicate > that? > > In JavaFX, null is something we have to deal in some fashion as > properties can easily be null. For the "primitive" properties, null (if > encountered) is translated to a default value. For StringProperty it > could be an empty string although JavaFX doesn't do this. For > ObjectProperty there is no sensible default possible. > > In ReactFX, nulls are indeed skipped when mapping as it considers null > to be an empty value, and empty values are skipped according to the > documentation. The code below will not throw an NPE in the mapping > function and will simply result in null: > > Var.newSimpleVar(null).map(x -> x + "2").getValue(); > > This is similar to the PoC implementation: > > new SimpleStringProperty().map(x -> x + "2").getValue()); > > Having worked with ReactFX and also the PoC, I think it would be very > cumbersome to have to deal with nulls in mapping functions, as many > simple mappings expressed with a short lambda would need to deal with > the null case with a ternary or an if/else block. > > In the PoC any mapping you could need that requires mapping null > explicitely can be expressed in another form: > > .map(x -> x == null ? "empty!" : x + "2") > > becomes: > > .map(x -> x + "2").orElse("empty!) > > which is not only more concise, but allows to delay dealing with null > until the very end: > > .map(x -> x == null ? "empty!" : fetchDataWhichCouldBeNull(x)) > .map(x -> x == null ? "empty!" : x + "2") > > versus: > > .map(Helper::fetchDataThatCouldBeNull) > .map(x -> x + "2") > .orElse("empty!") > > You don't have to delay it though, if for some reason you would want to > map the 2nd null case differently, you could use "orElse" after each > mapping still. > > Although for mapping this may seem somewhat contrived, for selecting (or > flatMapping) where you go through a chain of properties (like > Node->Scene->Window) being able to delay dealing with nulls leads to > more concise and IMHO more expressive code. > > So in summary, and to answer your first question, I don't think there is > a good reason to allow null to be passed to mapping functions. We do > need to deal with nulls though, and that's what "orElse" is for. This > could also be done with an additional parameter to "map" (a > "mapOrDefault" similar to "getOrDefault" from the collections API) but I > think we'd be better served with multiple methods that take a single > argument as the resulting code is easier to understand especially when > one of the arguments is a lambda. > > > > 2. If we want to replace the Bindings.select (non-type safe) API, can we > > do it with our current way of treating null? > > In the current Bindings.select API, null is skipped when encountered and > the resulting value of the chain will be null. This is exactly what > "flatMap" in the PoC does as well, in other words: > > Bindings.select(nodeProperty, "scene", "window", "showing") > > is exactly equivalent to: > > nodeProperty.flatMap(Node::sceneProperty) > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > > No null checks are needed, and the binding will be null if any of the > selected properties contain null. Note that both versions return null > despite the fact that the last property selected is a primitive boolean > which normally cannot hold null. > > However, Bindings also offers selectBoolean. In this case it does > indeed return false when any of the properties contains null, but it > also logs this uncomfortable warning then: > > WARNING: Value of select-binding has wrong type, returning default value > (+ stack trace omitted) > > The warning is somewhat deceptive as the binding does refer to a boolean > so it is not strictly of the wrong type, but an intermediate value > encountered was null and this cannot be cast to a primitive boolean. It > should probably just convert to the default value without any warning. > > So, to answer your question, I think we can indeed replace > Bindings.select with the PoC's typesafe equivalent. There is almost no > need to create specific primitive versions of this mechanism as users > can use "orElse" to map to a suitable primitive value as the last step > if null is undesired. > > > Do you think that this is a valid approach? > > Yes, I think our messages may have crossed paths as I suggested limiting > the API (based on your earlier recommendations) in a post on the > "Enhancements for JavaFX 18" thread in a reply to Kevin Rushforth. > > Your suggestion takes this a bit further by leaving the new methods in > ObjectBinding package protected and reducing the new API in > ObservableValue to its bare essentials. I think that's a fine approach > as it keeps the API that we're commiting to small and allows the highest > flexibility for future extensions. > > If an agreement can be reached on the initial API, I can rework the PoC > and also add the unit tests (I'll need to convert the JUnit 5 tests I > have to JUnit 4). > > --John > > > > > - Nir > > > > On Wed, Apr 7, 2021 at 11:30 PM John Hendrikx > > wrote: > > > > On 07/04/2021 03:41, Nir Lisker wrote: > > > In the PoC I made I specifically also disallowed 'null' as an > > input > > > > > > > > > I like the way ReactFX does it where the property is empty. I > > think that > > > this is also what you mean by disallowing `null` (in other > contexts, > > > "disallowing null" would mean throwing an exception). > > > > Yes, it is the same concept as ReactFX calling a property "empty", > > but I > > was hesitant to call this as `null` is a valid value for many JavaFX > > properties (a Scene can be null, a String can be null, etc.) which I > > don't think means the same as it being empty (in the Optional sense). > > But as long as the documentation is clear, I don't mind calling it > > either. > > > > > > > > Not entirely sure what you mean by this. > > > > > > > > > Basically, what you said. My point was that this is a different API > > > section. The first deals with expanding the observables/properties > > > methods. The second with listeners methods. Even if mapping a > property > > > requires a new listening model, like subscriptions, this is done > under > > > the hood. Exposing this API should be a separate step. At least > that's > > > how I see it. > > > > Yes, I think it is good to limit new API as much as possible to > reduce > > scope and increase the chances of its acceptance. The subscription > > parts > > can be designed separately and do not need to be public at this > point. > > They can be moved to a helper, or the implementation can take the > extra > > effort to use standard listeners. > > > > > > > > I'd be happy to spend more time and work on this. Perhaps it > > would be > > > possible to collaborate on this? > > > > > > > > > That would be good. I will need to re-review the ReactFX internals > and > > > see how your proposal differs exactly. > > > > Yes, I think that would be good to do. > > > > I've done some comparisons myself and didn't find a difference in > > functionality with `Val` (so far). It is a new implementation > though, I > > didn't really look at how `Val` was done internally as implementing > it > > directly into JavaFX is quite different (I had to make a few minor > > changes in `ObjectBinding` to allow for the choice of lazy > binding). I > > was also initially more focused on Streams only to realize at a later > > point that having a Stream implement ObservableValue was not going > > to be > > pretty (I suspect this also happened when ReactFX was created, which > is > > why Val/Var were later introduced in 2.x). > > > > Both the PoC and Val do lazy binding and are null safe and provide > > methods to deal with null/empty. > > > > The main thing I didn't do yet is provide a `filter` method. > Filtering > > properties that you want to use for bindings seems awkard as a > binding > > should always have some kind of value. The `filter` method in ReactFX > > basically maps the value to `null` when it doesn't match the filter. > > I've left this out as you can easily achieve this with `map` and > > `filter` seems to be too easy to misunderstand. > > > > Aside from that, ReactFX's Val offers a lot of other methods that > are I > > think a bit too specialized to consider at this point, like the > > `animate`, `pin`, `mapDynamic` and `suspendable` methods. > > > > Val also has all the other `Optional` methods (ifPresent, isPresent, > > isEmpty) but I think they may make the API a bit confusing (an > > observable value is not the same as an optional). I've also not had a > > need for these so far in practice and you can easily convert the > > current > > value to get this functionality with `Optional.ofNullable`. > > > > Finally Val offers a few methods to convert to ReactFX's streams. > While > > convenient, I think static methods like `Values.of`, > `Invalidations.of` > > or `Changes.of` would make for a less cluttered API to do stream > > conversions -- this would also make it possible to leave this part of > > the API up to a 3rd party. > > > > > By the way, do you make a distinction between ReactFX's Val and > > Var in > > > your proposal (one being read-only)? > > > > No, `ObservableValue` is basically the same as `Val`, and the > > equivalent > > to `Var` is `ObjectProperty`. Aside from it being a good companion > to > > `Val` (and less typing), I don't see a reason to implement `Var`. > > > > --John > > > > > > > > On Sun, Apr 4, 2021 at 12:43 PM John Hendrikx > > > > >> wrote: > > > > > > > > > > > > On 02/04/2021 08:47, Nir Lisker wrote: > > > > Hi John, > > > > > > > > I've had my eyes set on ReactFX enhancements for a while too, > > > especially as > > > > a replacement for the unsafe "select" mechanism. One of the > > things > > > that > > > > kept me from going forward with this is seeing what Valhalla > > will > > > bring. > > > > Generic specialization might save a lot of duplication work > on > > > something > > > > like this, and Tomas touched another related issue [1], but > > since > > > it could > > > > be a long time before that happens, it's worth planning what > we > > > can extract > > > > from ReactFX currently. > > > > > > Agreed, Valhalla is certainly a highly anticipated feature but > I > > > fear it > > > is still a couple of years away. > > > > > > Even without any initial support for dealing with "? extends > > Number" > > > from the various ObservableValue specializations I think > > looking into > > > this can already be tremendous help. > > > > > > The proof of concept mainly requires you convert the Number to > a > > > suitable type when reading the property but has no problems in > the > > > other > > > direction: > > > > > > label.widthProperty().map(Number::doubleValue).map(x -> x > > + 1); > > > > > > Not pretty, but certainly workable. Specific methods could be > > > introduced > > > (even at a later time) to make this more streamlined, similar > > to what > > > the Stream API offers with 'mapToDouble' etc. > > > > > > > I think that we should break the enhancements into parts. > > > > The first that I would advise to look at are the additions to > > > > properties/observables. Tomas had to create Val and Var > > because he > > > couldn't > > > > change the core interfaces, but we can. Fitting them with > > the Optional > > > > methods like `isPresent`, `isEmpty`, `ifPresent`, `map`. > > `flatMap` > > > etc.; > > > > and `select` and friends, is already a good start that will > > > address many > > > > common requirements. > > > > > > Yes, Val/Var had to be created for that reason, and also > because > > > properties don't quite behave the same as streams -- streams > > with a > > > "toBinding" method results in things people didn't quite > expect. > > > > > > As far as the Optional methods go, I'm not entirely sure > > properties > > > would benefit from all of them. Properties are not immutable > like > > > Optional and it may make less sense to fit them with > 'isPresent', > > > 'isEmpty' and 'ifPresent' ('ifPresent' would I think need to > > behave > > > similar to 'addListener' or 'subscribe'). > > > > > > In the PoC I made I specifically also disallowed 'null' as an > > input for > > > functions like 'map' and 'flatMap' (opting to use 'orElse' > > semantics > > > for > > > 'null'), as this for allows much cleaner mapping (and > > especially flat > > > mapping when selecting nested properties). If 'null' were to be > > > allowed, > > > I think at a minimum we'd need to add another method to allow > > for easy > > > selecting of nested properties to avoid: > > > > > > obs.flatMap(x -> x == null ? null : x.otherProperty()) > > > > > > > The second part is related to listeners. The subscription > model > > > and event > > > > streams try to solve the memory issues with hard and weak > > > references, and > > > > allow better composition. > > > > > > Not entirely sure what you mean by this. JavaFX's current > > model uses > > > weak references which was I think an unfortunate decision as > > it can > > > result in huge confusion. For example, a direct binding will > > work, but > > > with an indirection step a binding stops working: > > > > > > button.textProperty() > > > .concat("World") // weak binding used here > > > .addListener((obs, old, cur) -> > System.out.println(cur)); > > > > > > The above stops working, but without the 'concat' it keeps > > working. > > > > > > I think the use of weak listeners should be avoided and > > instead other > > > mechanisms should be provided to make cleaning up easier. This > > is the > > > main reason for 'conditionOn' and why ReactFX even had a > > specialized > > > version of it: 'conditionOnShowing(Node)'. > > > > > > > The third part is for collections - things like > > transformation lists > > > > (LiveList) and for other collections. > > > > > > This is indeed best saved for last. The problems there I think > > are less > > > of an issue for now. > > > > > > > Since these share behavior under the hood, we need to look > > ahead, > > > but in > > > > terms of functionality, I think we should take smaller > steps. It > > > will also > > > > be easier to propose these then. > > > > > > I've for this reason kept the PoC small with only the most > basic > > > functionality. I did however add some work for a different > > > subscription > > > model, mainly because the internals of this code benefits > > greatly from > > > it. It is however kept to a minimum. > > > > > > I'd be happy to spend more time and work on this. Perhaps it > > would be > > > possible to collaborate on this? > > > > > > --John > > > > > > > > > > > - Nir > > > > > > > > [1] > > > > > > > > > > https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issue > > > > > > > > On Wed, Mar 24, 2021 at 11:49 PM John Hendrikx > > > > > >> wrote: > > > > > > > >> I just wanted to draw some attention to a recent proof of > > concept > > > I made > > > >> in this pull request: > https://github.com/openjdk/jfx/pull/434 > > > >> > > > >> It is based on the work I did in > > > >> https://github.com/hjohn/hs.jfx.eventstream which is in > > part based on > > > >> work done in ReactFX by Tomas Mikula. The PR itself however > > shares no > > > >> code with ReactFX and is > > > >> completely written by me. > > > >> > > > >> If there is interest, I'm willing to invest more time in > > > smoothing out > > > >> the API and documentation, investigating further how this > would > > > interact > > > >> with the primitive types and adding unit test coverage (I > have > > > extensive > > > >> tests, but thesea are written in JUnit 5, so they would > require > > > >> conversion or JavaFX could move to support JUnit 5). > > > >> > > > >> What follows below is the text of the PR for easy reading. > > > Feedback is > > > >> appreciated. > > > >> > > > >> ================ > > > >> > > > >> This is a proof of concept of how fluent bindings could be > > > introduced to > > > >> JavaFX. The main benefit of fluent bindings are ease of > > use, type > > > safety > > > >> and less surprises. Features: > > > >> > > > >> Flexible Mappings > > > >> Map the contents of a property any way you like with map, > > or map > > > nested > > > >> properties with flatMap. > > > >> > > > >> Lazy > > > >> The bindings created are lazy, which means they are always > > > invalid when > > > >> not themselves observed. This allows for easier garbage > > > collection (once > > > >> the last observer is removed, a chain of bindings will stop > > observing > > > >> their parents) and less listener management when dealing > > with nested > > > >> properties. Furthermore, this allows inclusion of such > > bindings in > > > >> classes such as Node without listeners being created when > > the binding > > > >> itself is not used (this would allow for the inclusion of a > > > >> treeShowingProperty in Node without creating excessive > > listeners, see > > > >> this fix I did in an earlier PR: #185) > > > >> > > > >> Null Safe > > > >> The map and flatMap methods are skipped, similar to > > > java.util.Optional > > > >> when the value they would be mapping is null. This makes > > mapping > > > nested > > > >> properties with flatMap trivial as the null case does not > > need to be > > > >> taken into account in a chain like this: > > > >> > > > > > > node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). > > > >> > > > >> Instead a default can be provided with orElse or orElseGet. > > > >> > > > >> Conditional Bindings > > > >> Bindings can be made conditional using the conditionOn > > method. A > > > >> conditional binding retains its last value when its > > condition is > > > false. > > > >> Conditional bindings donot observe their source when the > > condition is > > > >> false, allowing developers to automatically stop listening > to > > > properties > > > >> when a certain condition is met. A major use of this > feature is > > > to have > > > >> UI components that need to keep models updated which may > > outlive > > > the UI > > > >> conditionally update the long lived model only when the UI > is > > > showing. > > > >> > > > >> Some examples: > > > >> > > > >> void mapProperty() { > > > >> // Standard JavaFX: > > > >> > label.textProperty().bind(Bindings.createStringBinding(() -> > > > >> text.getValueSafe().toUpperCase(), text)); > > > >> > > > >> // Fluent: much more compact, no need to handle null > > > >> label.textProperty().bind(text.map(String::toUpperCase)); > > > >> } > > > >> > > > >> void calculateCharactersLeft() { > > > >> // Standard JavaFX: > > > >> > > > >> > > > > > > label.textProperty().bind(text.length().negate().add(100).asString().concat(" > > > >> > > > >> characters left")); > > > >> > > > >> // Fluent: slightly more compact and more clear (no > > negate needed) > > > >> label.textProperty().bind(text.orElse("").map(v -> 100 - > > > v.length() + > > > >> " characters left")); > > > >> } > > > >> > > > >> void mapNestedValue() { > > > >> // Standard JavaFX: > > > >> label.textProperty().bind(Bindings.createStringBinding( > > > >> () -> employee.get() == null ? "" > > > >> : employee.get().getCompany() == null ? "" > > > >> : employee.get().getCompany().getName(), > > > >> employee > > > >> )); > > > >> > > > >> // Fluent: no need to handle nulls everywhere > > > >> label.textProperty().bind( > > > >> employee.map(Employee::getCompany) > > > >> .map(Company::getName) > > > >> .orElse("") > > > >> ); > > > >> } > > > >> > > > >> void mapNestedProperty() { > > > >> // Standard JavaFX: > > > >> label.textProperty().bind( > > > >> > > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), > > > >> "window", "showing")) > > > >> .then("Visible") > > > >> .otherwise("Not Visible") > > > >> ); > > > >> > > > >> // Fluent: type safe > > > >> label.textProperty().bind(label.sceneProperty() > > > >> .flatMap(Scene::windowProperty) > > > >> .flatMap(Window::showingProperty) > > > >> .orElse(false) > > > >> .map(showing -> showing ? "Visible" : "Not Visible") > > > >> ); > > > >> } > > > >> > > > >> void updateLongLivedModelWhileAvoidingMemoryLeaks() { > > > >> // Standard JavaFX: naive, memory leak; UI won't get > garbage > > > collected > > > >> > > listView.getSelectionModel().selectedItemProperty().addListener( > > > >> (obs, old, current) -> > > > >> longLivedModel.lastSelectedProperty().set(current) > > > >> ); > > > >> > > > >> // Standard JavaFX: no leak, but stops updating after a > > while > > > >> > > listView.getSelectionModel().selectedItemProperty().addListener( > > > >> new WeakChangeListener<>( > > > >> (obs, old, current) -> > > > >> longLivedModel.lastSelectedProperty().set(current) > > > >> ) > > > >> ); > > > >> > > > >> // Standard JavaFX: fixed version > > > >> listenerReference = (obs, old, current) -> > > > >> longLivedModel.lastSelectedProperty().set(current); > > > >> > > > >> > > listView.getSelectionModel().selectedItemProperty().addListener( > > > >> new WeakChangeListener<>(listenerReference) > > > >> ); > > > >> > > > >> // Fluent: naive, memory leak... fluent won't solve > this... > > > >> listView.getSelectionModel().selectedItemProperty() > > > >> > .subscribe(longLivedModel.lastSelectedProperty()::set); > > > >> > > > >> // Fluent: conditional update when control visible > > > >> > > > >> // Create a property which is only true when the UI is > > visible: > > > >> ObservableValue showing = > listView.sceneProperty() > > > >> .flatMap(Scene::windowProperty) > > > >> .flatMap(Window::showingProperty) > > > >> .orElse(false); > > > >> > > > >> // Use showing property to automatically disconnect long > > lived > > > model > > > >> // allowing garbage collection of the UI: > > > >> listView.getSelectionModel().selectedItemProperty() > > > >> .conditionOn(showing) > > > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > > > >> > > > >> // Note that the 'showing' property can be provided in > > > multiple ways: > > > >> // - create manually (can be re-used for multiple > > bindings though) > > > >> // - create with a helper: Nodes.showing(Node node) -> > > > >> ObservableValue > > > >> // - make it part of the Node class; as the fluent > bindings > > > only bind > > > >> themselves > > > >> // to their source when needed (lazy binding), this > > won't create > > > >> overhead > > > >> // for each node in the scene > > > >> } > > > >> Note that this is based on ideas in ReactFX and my own > > experiments in > > > >> https://github.com/hjohn/hs.jfx.eventstream. I've come to > the > > > conclusion > > > >> that this is much better directly integrated into JavaFX, > > and I'm > > > hoping > > > >> this proof of concept will be able to move such an effort > > forward. > > > >> > > > >> --John > > > >> > > > > > > > > > > From hjohn at xs4all.nl Tue Sep 14 05:43:57 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Tue, 14 Sep 2021 07:43:57 +0200 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> Message-ID: <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl> On 14/09/2021 03:14, Nir Lisker wrote: > Sounds good. > > Some points I have (maybe some are premature): > > 1. I still think that adding the Optional methods for orElse and orElseGet > could be useful. Unless I can be convinced otherwise, I suggest that we be > careful with the naming of current methods that return a binding. Sorry, I'm not quite sure what you mean by this. Could you elaborate? The methods orElse and orElseGet are present in the PoC, and I think they're highly useful to have to deal with nulls. > 2. I see that in ReactFX the Val.map will pass to MappedVal the mapping > function as-is, and the null check is done in computeValue(). In your > implementation, the LazyBinding (equivalent of MappedVal) is passed a > composite mapping that deals with null and the computeValue() can just use > that new mapping function. I think that the end behavior is the same, but > does your way use more memory for the extra Function lambda? I think you may have misinterpreted what happens here. I'm ensuring that the mapping function itself isn't null (fail fast) by using Objects.requireNonNull -- it doesn't produce a new lambda. ReactFX doesn't do this check and will throw a NPE when the mapping function is used for the first time. The null check in ReactFX's #computeValue is actually checking the result of the mapping function, not whether the function instance itself was null. > 3. Why does nullableMapping creates an anonymous subtype of LazyBinding, > while flatMapping creates a concrete instance of FlatMapBinding? I suppose I felt it was small enough to inline, but there's no particular reason to write it one way or the other. The nullableMapping can be extracted to a class to make it more consistent. > 4. Why does orElseGet call Bindings.nullableMapping directly, while map > calls Bindings.mapping which in turn calls Bindings.nullableMapping? It's because of the null check. For mapping I could wrap the function parameter in Objects.requireNonNull as it will be evaluated immediately. For orElseGet, I had to put the check on a separate line (as the first use of supplier parameter is inside a lambda). I prefer to do null checks as early as possible (so you get a better stack trace) but I also prefer to write interface default implementations as short as possible. I could write #map to look like #orElseGet but it would become one line longer, or I could write #orElseGet to do a call to a separate Bindings method and move the null check there but then the stack trace for the NPE would no longer point to the #orElseGet interface method as first trace line. I can rewrite this however if you would like, but that's sort of the reasoning I had I think when I wrote this code balancing short default implementations vs delayed null checks. If you would want it more consistent, then I think I'd prefer to write #map like #orElseGet. > 5. I noticed also that subscribeInvalidations in ObservableValue will need > to be hidden. Yes, that should be no problem. We can either fall back to using standard listener management, or create a small helper that works with the subscription model. > Some related JBS issues that I found that we might be able to use (or at > least close at some point): > https://bugs.openjdk.java.net/browse/JDK-8091544 To close "Bindings.select*(): add new type-safe template based API instead of legacy-style set of methods" we'd need the flatMap/select method to be included. I don't think we really need specialized methods for primitives (or at least, not right away). At this point the primitive versions only really differ in what value they'd return if the binding would be null and perhaps they do a little less boxing/unboxing. Since you can select the default value with #orElse which is more flexible I don't see much use to add those variants. > https://bugs.openjdk.java.net/browse/JDK-8091316 "Add a Bindings.map() method". The ticket is a bit unclear as I can't see what type "x" is. So this seems to be for a use case where an Observable "x" should be bound with some transformation to the windowTitleProperty. I'm assuming x is an Observable because it is used in the list of dependencies. If x is only an Observable, then I don't think the PoC will help. If x is more (it is hard to tell from the ticket) you might be able to map it. However, x seems to have a "getY()" method so it doesn't look like it is a Property or ObservableValue... Making some assumptions here and assuming x has an y property itself, you could write this as: windowsTitleProperty.bind(x.flatMap(XClass::yProperty).map(y -> { switch(y) { case ... } }); Or: windowsTitleProperty.bind(x.map(x2 -> { switch(x2.getY()) { case ... } }); Or perhaps x is the correct property already, then it be: windowsTitleProperty.bind(x.map(y -> { switch(y) { case ... } }); --John > On Mon, Sep 13, 2021 at 3:05 AM John Hendrikx wrote: > >> >> >> On 12/09/2021 02:05, Nir Lisker wrote: >>> I've gotten back to look at this. >>> >>> For now I'm dealing only with the nullableMapping method in Bindings so >>> we can limit the amount of new classes to LazyObjectBinding >>> (FlatMapBinding and ConditionalBinding can come later). This method is >>> used by map, orElse and orElseGet in ObservableValue. Of these, map is >>> the only fundamental one since the other 2 can be represented by it. I >>> don't mind keeping them in the discussion, though I will be centered on >>> the map method. >>> >>> The implementation of these methods rely on Bindings, LazyObjectBinding, >>> and Subscription in the current implementation. I think that we can >>> introduce these internally for now. The biggest hurdle left are the >>> public changes to ObjectBinding. If we add protected methods, we need to >>> be sure that by the end of this large task they would have been the >>> right ones to add and at the right place. This is why I recommend adding >>> them at the package visibility level and add LazyObjectBinding (and >>> friends) in its package so they can extend it. I understand that this >>> can look ugly, but moving internal implementation is cheap, and in this >>> case, since the coupling involves about 3 classes, is very cheap. This >>> will lower the initial integration barrier and let the community get >>> used to- and give feedback on the new changes. >> >> I think that's a good idea, there is no direct need to make those >> protected methods part of the public API as the usefulness of those >> methods will be limited and the major use case will basically be >> provided by LazyObjectBinding already. >> >>> This will leave only 1 change that we are committed to, and that's the >>> new API on ObservableValue (which is the map method in this case). The >>> method looks good; the only question, which has arisen in a few places, >>> is how to handle null. As we discussed here, this method works like its >>> ReactFX counterpart, ignoring null. My questions would be: >>> 1. Is there a good reason to allow null? If so, do we add a new method >>> for it, or do we pass some parameter to the current method to indicate >> that? >> >> In JavaFX, null is something we have to deal in some fashion as >> properties can easily be null. For the "primitive" properties, null (if >> encountered) is translated to a default value. For StringProperty it >> could be an empty string although JavaFX doesn't do this. For >> ObjectProperty there is no sensible default possible. >> >> In ReactFX, nulls are indeed skipped when mapping as it considers null >> to be an empty value, and empty values are skipped according to the >> documentation. The code below will not throw an NPE in the mapping >> function and will simply result in null: >> >> Var.newSimpleVar(null).map(x -> x + "2").getValue(); >> >> This is similar to the PoC implementation: >> >> new SimpleStringProperty().map(x -> x + "2").getValue()); >> >> Having worked with ReactFX and also the PoC, I think it would be very >> cumbersome to have to deal with nulls in mapping functions, as many >> simple mappings expressed with a short lambda would need to deal with >> the null case with a ternary or an if/else block. >> >> In the PoC any mapping you could need that requires mapping null >> explicitely can be expressed in another form: >> >> .map(x -> x == null ? "empty!" : x + "2") >> >> becomes: >> >> .map(x -> x + "2").orElse("empty!) >> >> which is not only more concise, but allows to delay dealing with null >> until the very end: >> >> .map(x -> x == null ? "empty!" : fetchDataWhichCouldBeNull(x)) >> .map(x -> x == null ? "empty!" : x + "2") >> >> versus: >> >> .map(Helper::fetchDataThatCouldBeNull) >> .map(x -> x + "2") >> .orElse("empty!") >> >> You don't have to delay it though, if for some reason you would want to >> map the 2nd null case differently, you could use "orElse" after each >> mapping still. >> >> Although for mapping this may seem somewhat contrived, for selecting (or >> flatMapping) where you go through a chain of properties (like >> Node->Scene->Window) being able to delay dealing with nulls leads to >> more concise and IMHO more expressive code. >> >> So in summary, and to answer your first question, I don't think there is >> a good reason to allow null to be passed to mapping functions. We do >> need to deal with nulls though, and that's what "orElse" is for. This >> could also be done with an additional parameter to "map" (a >> "mapOrDefault" similar to "getOrDefault" from the collections API) but I >> think we'd be better served with multiple methods that take a single >> argument as the resulting code is easier to understand especially when >> one of the arguments is a lambda. >> >> >>> 2. If we want to replace the Bindings.select (non-type safe) API, can we >>> do it with our current way of treating null? >> >> In the current Bindings.select API, null is skipped when encountered and >> the resulting value of the chain will be null. This is exactly what >> "flatMap" in the PoC does as well, in other words: >> >> Bindings.select(nodeProperty, "scene", "window", "showing") >> >> is exactly equivalent to: >> >> nodeProperty.flatMap(Node::sceneProperty) >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> >> No null checks are needed, and the binding will be null if any of the >> selected properties contain null. Note that both versions return null >> despite the fact that the last property selected is a primitive boolean >> which normally cannot hold null. >> >> However, Bindings also offers selectBoolean. In this case it does >> indeed return false when any of the properties contains null, but it >> also logs this uncomfortable warning then: >> >> WARNING: Value of select-binding has wrong type, returning default value >> (+ stack trace omitted) >> >> The warning is somewhat deceptive as the binding does refer to a boolean >> so it is not strictly of the wrong type, but an intermediate value >> encountered was null and this cannot be cast to a primitive boolean. It >> should probably just convert to the default value without any warning. >> >> So, to answer your question, I think we can indeed replace >> Bindings.select with the PoC's typesafe equivalent. There is almost no >> need to create specific primitive versions of this mechanism as users >> can use "orElse" to map to a suitable primitive value as the last step >> if null is undesired. >> >>> Do you think that this is a valid approach? >> >> Yes, I think our messages may have crossed paths as I suggested limiting >> the API (based on your earlier recommendations) in a post on the >> "Enhancements for JavaFX 18" thread in a reply to Kevin Rushforth. >> >> Your suggestion takes this a bit further by leaving the new methods in >> ObjectBinding package protected and reducing the new API in >> ObservableValue to its bare essentials. I think that's a fine approach >> as it keeps the API that we're commiting to small and allows the highest >> flexibility for future extensions. >> >> If an agreement can be reached on the initial API, I can rework the PoC >> and also add the unit tests (I'll need to convert the JUnit 5 tests I >> have to JUnit 4). >> >> --John >> >>> >>> - Nir >>> >>> On Wed, Apr 7, 2021 at 11:30 PM John Hendrikx >> > wrote: >>> >>> On 07/04/2021 03:41, Nir Lisker wrote: >>> > In the PoC I made I specifically also disallowed 'null' as an >>> input >>> > >>> > >>> > I like the way ReactFX does it where the property is empty. I >>> think that >>> > this is also what you mean by disallowing `null` (in other >> contexts, >>> > "disallowing null" would mean throwing an exception). >>> >>> Yes, it is the same concept as ReactFX calling a property "empty", >>> but I >>> was hesitant to call this as `null` is a valid value for many JavaFX >>> properties (a Scene can be null, a String can be null, etc.) which I >>> don't think means the same as it being empty (in the Optional sense). >>> But as long as the documentation is clear, I don't mind calling it >>> either. >>> >>> > >>> > Not entirely sure what you mean by this. >>> > >>> > >>> > Basically, what you said. My point was that this is a different API >>> > section. The first deals with expanding the observables/properties >>> > methods. The second with listeners methods. Even if mapping a >> property >>> > requires a new listening model, like subscriptions, this is done >> under >>> > the hood. Exposing this API should be a separate step. At least >> that's >>> > how I see it. >>> >>> Yes, I think it is good to limit new API as much as possible to >> reduce >>> scope and increase the chances of its acceptance. The subscription >>> parts >>> can be designed separately and do not need to be public at this >> point. >>> They can be moved to a helper, or the implementation can take the >> extra >>> effort to use standard listeners. >>> >>> > >>> > I'd be happy to spend more time and work on this. Perhaps it >>> would be >>> > possible to collaborate on this? >>> > >>> > >>> > That would be good. I will need to re-review the ReactFX internals >> and >>> > see how your proposal differs exactly. >>> >>> Yes, I think that would be good to do. >>> >>> I've done some comparisons myself and didn't find a difference in >>> functionality with `Val` (so far). It is a new implementation >> though, I >>> didn't really look at how `Val` was done internally as implementing >> it >>> directly into JavaFX is quite different (I had to make a few minor >>> changes in `ObjectBinding` to allow for the choice of lazy >> binding). I >>> was also initially more focused on Streams only to realize at a later >>> point that having a Stream implement ObservableValue was not going >>> to be >>> pretty (I suspect this also happened when ReactFX was created, which >> is >>> why Val/Var were later introduced in 2.x). >>> >>> Both the PoC and Val do lazy binding and are null safe and provide >>> methods to deal with null/empty. >>> >>> The main thing I didn't do yet is provide a `filter` method. >> Filtering >>> properties that you want to use for bindings seems awkard as a >> binding >>> should always have some kind of value. The `filter` method in ReactFX >>> basically maps the value to `null` when it doesn't match the filter. >>> I've left this out as you can easily achieve this with `map` and >>> `filter` seems to be too easy to misunderstand. >>> >>> Aside from that, ReactFX's Val offers a lot of other methods that >> are I >>> think a bit too specialized to consider at this point, like the >>> `animate`, `pin`, `mapDynamic` and `suspendable` methods. >>> >>> Val also has all the other `Optional` methods (ifPresent, isPresent, >>> isEmpty) but I think they may make the API a bit confusing (an >>> observable value is not the same as an optional). I've also not had a >>> need for these so far in practice and you can easily convert the >>> current >>> value to get this functionality with `Optional.ofNullable`. >>> >>> Finally Val offers a few methods to convert to ReactFX's streams. >> While >>> convenient, I think static methods like `Values.of`, >> `Invalidations.of` >>> or `Changes.of` would make for a less cluttered API to do stream >>> conversions -- this would also make it possible to leave this part of >>> the API up to a 3rd party. >>> >>> > By the way, do you make a distinction between ReactFX's Val and >>> Var in >>> > your proposal (one being read-only)? >>> >>> No, `ObservableValue` is basically the same as `Val`, and the >>> equivalent >>> to `Var` is `ObjectProperty`. Aside from it being a good companion >> to >>> `Val` (and less typing), I don't see a reason to implement `Var`. >>> >>> --John >>> >>> > >>> > On Sun, Apr 4, 2021 at 12:43 PM John Hendrikx >> >>> > >> wrote: >>> > >>> > >>> > >>> > On 02/04/2021 08:47, Nir Lisker wrote: >>> > > Hi John, >>> > > >>> > > I've had my eyes set on ReactFX enhancements for a while too, >>> > especially as >>> > > a replacement for the unsafe "select" mechanism. One of the >>> things >>> > that >>> > > kept me from going forward with this is seeing what Valhalla >>> will >>> > bring. >>> > > Generic specialization might save a lot of duplication work >> on >>> > something >>> > > like this, and Tomas touched another related issue [1], but >>> since >>> > it could >>> > > be a long time before that happens, it's worth planning what >> we >>> > can extract >>> > > from ReactFX currently. >>> > >>> > Agreed, Valhalla is certainly a highly anticipated feature but >> I >>> > fear it >>> > is still a couple of years away. >>> > >>> > Even without any initial support for dealing with "? extends >>> Number" >>> > from the various ObservableValue specializations I think >>> looking into >>> > this can already be tremendous help. >>> > >>> > The proof of concept mainly requires you convert the Number to >> a >>> > suitable type when reading the property but has no problems in >> the >>> > other >>> > direction: >>> > >>> > label.widthProperty().map(Number::doubleValue).map(x -> x >>> + 1); >>> > >>> > Not pretty, but certainly workable. Specific methods could be >>> > introduced >>> > (even at a later time) to make this more streamlined, similar >>> to what >>> > the Stream API offers with 'mapToDouble' etc. >>> > >>> > > I think that we should break the enhancements into parts. >>> > > The first that I would advise to look at are the additions to >>> > > properties/observables. Tomas had to create Val and Var >>> because he >>> > couldn't >>> > > change the core interfaces, but we can. Fitting them with >>> the Optional >>> > > methods like `isPresent`, `isEmpty`, `ifPresent`, `map`. >>> `flatMap` >>> > etc.; >>> > > and `select` and friends, is already a good start that will >>> > address many >>> > > common requirements. >>> > >>> > Yes, Val/Var had to be created for that reason, and also >> because >>> > properties don't quite behave the same as streams -- streams >>> with a >>> > "toBinding" method results in things people didn't quite >> expect. >>> > >>> > As far as the Optional methods go, I'm not entirely sure >>> properties >>> > would benefit from all of them. Properties are not immutable >> like >>> > Optional and it may make less sense to fit them with >> 'isPresent', >>> > 'isEmpty' and 'ifPresent' ('ifPresent' would I think need to >>> behave >>> > similar to 'addListener' or 'subscribe'). >>> > >>> > In the PoC I made I specifically also disallowed 'null' as an >>> input for >>> > functions like 'map' and 'flatMap' (opting to use 'orElse' >>> semantics >>> > for >>> > 'null'), as this for allows much cleaner mapping (and >>> especially flat >>> > mapping when selecting nested properties). If 'null' were to be >>> > allowed, >>> > I think at a minimum we'd need to add another method to allow >>> for easy >>> > selecting of nested properties to avoid: >>> > >>> > obs.flatMap(x -> x == null ? null : x.otherProperty()) >>> > >>> > > The second part is related to listeners. The subscription >> model >>> > and event >>> > > streams try to solve the memory issues with hard and weak >>> > references, and >>> > > allow better composition. >>> > >>> > Not entirely sure what you mean by this. JavaFX's current >>> model uses >>> > weak references which was I think an unfortunate decision as >>> it can >>> > result in huge confusion. For example, a direct binding will >>> work, but >>> > with an indirection step a binding stops working: >>> > >>> > button.textProperty() >>> > .concat("World") // weak binding used here >>> > .addListener((obs, old, cur) -> >> System.out.println(cur)); >>> > >>> > The above stops working, but without the 'concat' it keeps >>> working. >>> > >>> > I think the use of weak listeners should be avoided and >>> instead other >>> > mechanisms should be provided to make cleaning up easier. This >>> is the >>> > main reason for 'conditionOn' and why ReactFX even had a >>> specialized >>> > version of it: 'conditionOnShowing(Node)'. >>> > >>> > > The third part is for collections - things like >>> transformation lists >>> > > (LiveList) and for other collections. >>> > >>> > This is indeed best saved for last. The problems there I think >>> are less >>> > of an issue for now. >>> > >>> > > Since these share behavior under the hood, we need to look >>> ahead, >>> > but in >>> > > terms of functionality, I think we should take smaller >> steps. It >>> > will also >>> > > be easier to propose these then. >>> > >>> > I've for this reason kept the PoC small with only the most >> basic >>> > functionality. I did however add some work for a different >>> > subscription >>> > model, mainly because the internals of this code benefits >>> greatly from >>> > it. It is however kept to a minimum. >>> > >>> > I'd be happy to spend more time and work on this. Perhaps it >>> would be >>> > possible to collaborate on this? >>> > >>> > --John >>> > >>> > > >>> > > - Nir >>> > > >>> > > [1] >>> > > >>> > >>> >> https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issue >>> > > >>> > > On Wed, Mar 24, 2021 at 11:49 PM John Hendrikx >>> >>> > >> wrote: >>> > > >>> > >> I just wanted to draw some attention to a recent proof of >>> concept >>> > I made >>> > >> in this pull request: >> https://github.com/openjdk/jfx/pull/434 >>> > >> >>> > >> It is based on the work I did in >>> > >> https://github.com/hjohn/hs.jfx.eventstream which is in >>> part based on >>> > >> work done in ReactFX by Tomas Mikula. The PR itself however >>> shares no >>> > >> code with ReactFX and is >>> > >> completely written by me. >>> > >> >>> > >> If there is interest, I'm willing to invest more time in >>> > smoothing out >>> > >> the API and documentation, investigating further how this >> would >>> > interact >>> > >> with the primitive types and adding unit test coverage (I >> have >>> > extensive >>> > >> tests, but thesea are written in JUnit 5, so they would >> require >>> > >> conversion or JavaFX could move to support JUnit 5). >>> > >> >>> > >> What follows below is the text of the PR for easy reading. >>> > Feedback is >>> > >> appreciated. >>> > >> >>> > >> ================ >>> > >> >>> > >> This is a proof of concept of how fluent bindings could be >>> > introduced to >>> > >> JavaFX. The main benefit of fluent bindings are ease of >>> use, type >>> > safety >>> > >> and less surprises. Features: >>> > >> >>> > >> Flexible Mappings >>> > >> Map the contents of a property any way you like with map, >>> or map >>> > nested >>> > >> properties with flatMap. >>> > >> >>> > >> Lazy >>> > >> The bindings created are lazy, which means they are always >>> > invalid when >>> > >> not themselves observed. This allows for easier garbage >>> > collection (once >>> > >> the last observer is removed, a chain of bindings will stop >>> observing >>> > >> their parents) and less listener management when dealing >>> with nested >>> > >> properties. Furthermore, this allows inclusion of such >>> bindings in >>> > >> classes such as Node without listeners being created when >>> the binding >>> > >> itself is not used (this would allow for the inclusion of a >>> > >> treeShowingProperty in Node without creating excessive >>> listeners, see >>> > >> this fix I did in an earlier PR: #185) >>> > >> >>> > >> Null Safe >>> > >> The map and flatMap methods are skipped, similar to >>> > java.util.Optional >>> > >> when the value they would be mapping is null. This makes >>> mapping >>> > nested >>> > >> properties with flatMap trivial as the null case does not >>> need to be >>> > >> taken into account in a chain like this: >>> > >> >>> > >>> >> node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). >>> > >> >>> > >> Instead a default can be provided with orElse or orElseGet. >>> > >> >>> > >> Conditional Bindings >>> > >> Bindings can be made conditional using the conditionOn >>> method. A >>> > >> conditional binding retains its last value when its >>> condition is >>> > false. >>> > >> Conditional bindings donot observe their source when the >>> condition is >>> > >> false, allowing developers to automatically stop listening >> to >>> > properties >>> > >> when a certain condition is met. A major use of this >> feature is >>> > to have >>> > >> UI components that need to keep models updated which may >>> outlive >>> > the UI >>> > >> conditionally update the long lived model only when the UI >> is >>> > showing. >>> > >> >>> > >> Some examples: >>> > >> >>> > >> void mapProperty() { >>> > >> // Standard JavaFX: >>> > >> >> label.textProperty().bind(Bindings.createStringBinding(() -> >>> > >> text.getValueSafe().toUpperCase(), text)); >>> > >> >>> > >> // Fluent: much more compact, no need to handle null >>> > >> label.textProperty().bind(text.map(String::toUpperCase)); >>> > >> } >>> > >> >>> > >> void calculateCharactersLeft() { >>> > >> // Standard JavaFX: >>> > >> >>> > >> >>> > >>> >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" >>> > >> >>> > >> characters left")); >>> > >> >>> > >> // Fluent: slightly more compact and more clear (no >>> negate needed) >>> > >> label.textProperty().bind(text.orElse("").map(v -> 100 - >>> > v.length() + >>> > >> " characters left")); >>> > >> } >>> > >> >>> > >> void mapNestedValue() { >>> > >> // Standard JavaFX: >>> > >> label.textProperty().bind(Bindings.createStringBinding( >>> > >> () -> employee.get() == null ? "" >>> > >> : employee.get().getCompany() == null ? "" >>> > >> : employee.get().getCompany().getName(), >>> > >> employee >>> > >> )); >>> > >> >>> > >> // Fluent: no need to handle nulls everywhere >>> > >> label.textProperty().bind( >>> > >> employee.map(Employee::getCompany) >>> > >> .map(Company::getName) >>> > >> .orElse("") >>> > >> ); >>> > >> } >>> > >> >>> > >> void mapNestedProperty() { >>> > >> // Standard JavaFX: >>> > >> label.textProperty().bind( >>> > >> >>> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), >>> > >> "window", "showing")) >>> > >> .then("Visible") >>> > >> .otherwise("Not Visible") >>> > >> ); >>> > >> >>> > >> // Fluent: type safe >>> > >> label.textProperty().bind(label.sceneProperty() >>> > >> .flatMap(Scene::windowProperty) >>> > >> .flatMap(Window::showingProperty) >>> > >> .orElse(false) >>> > >> .map(showing -> showing ? "Visible" : "Not Visible") >>> > >> ); >>> > >> } >>> > >> >>> > >> void updateLongLivedModelWhileAvoidingMemoryLeaks() { >>> > >> // Standard JavaFX: naive, memory leak; UI won't get >> garbage >>> > collected >>> > >> >>> listView.getSelectionModel().selectedItemProperty().addListener( >>> > >> (obs, old, current) -> >>> > >> longLivedModel.lastSelectedProperty().set(current) >>> > >> ); >>> > >> >>> > >> // Standard JavaFX: no leak, but stops updating after a >>> while >>> > >> >>> listView.getSelectionModel().selectedItemProperty().addListener( >>> > >> new WeakChangeListener<>( >>> > >> (obs, old, current) -> >>> > >> longLivedModel.lastSelectedProperty().set(current) >>> > >> ) >>> > >> ); >>> > >> >>> > >> // Standard JavaFX: fixed version >>> > >> listenerReference = (obs, old, current) -> >>> > >> longLivedModel.lastSelectedProperty().set(current); >>> > >> >>> > >> >>> listView.getSelectionModel().selectedItemProperty().addListener( >>> > >> new WeakChangeListener<>(listenerReference) >>> > >> ); >>> > >> >>> > >> // Fluent: naive, memory leak... fluent won't solve >> this... >>> > >> listView.getSelectionModel().selectedItemProperty() >>> > >> >> .subscribe(longLivedModel.lastSelectedProperty()::set); >>> > >> >>> > >> // Fluent: conditional update when control visible >>> > >> >>> > >> // Create a property which is only true when the UI is >>> visible: >>> > >> ObservableValue showing = >> listView.sceneProperty() >>> > >> .flatMap(Scene::windowProperty) >>> > >> .flatMap(Window::showingProperty) >>> > >> .orElse(false); >>> > >> >>> > >> // Use showing property to automatically disconnect long >>> lived >>> > model >>> > >> // allowing garbage collection of the UI: >>> > >> listView.getSelectionModel().selectedItemProperty() >>> > >> .conditionOn(showing) >>> > >> .subscribe(longLivedModel.lastSelectedProperty()::set); >>> > >> >>> > >> // Note that the 'showing' property can be provided in >>> > multiple ways: >>> > >> // - create manually (can be re-used for multiple >>> bindings though) >>> > >> // - create with a helper: Nodes.showing(Node node) -> >>> > >> ObservableValue >>> > >> // - make it part of the Node class; as the fluent >> bindings >>> > only bind >>> > >> themselves >>> > >> // to their source when needed (lazy binding), this >>> won't create >>> > >> overhead >>> > >> // for each node in the scene >>> > >> } >>> > >> Note that this is based on ideas in ReactFX and my own >>> experiments in >>> > >> https://github.com/hjohn/hs.jfx.eventstream. I've come to >> the >>> > conclusion >>> > >> that this is much better directly integrated into JavaFX, >>> and I'm >>> > hoping >>> > >> this proof of concept will be able to move such an effort >>> forward. >>> > >> >>> > >> --John >>> > >> >>> > > >>> > >>> >> > From ajit.ghaisas at oracle.com Tue Sep 14 06:31:49 2021 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 14 Sep 2021 06:31:49 +0000 Subject: CFV: New OpenJFX Committer: Thiago Sayao In-Reply-To: References: Message-ID: <1124E061-AADE-4FC3-8BC5-A6F360BF5939@oracle.com> Vote: YES Regards, Ajit > On 13-Sep-2021, at 8:07 PM, Kevin Rushforth wrote: > > I hereby nominate Thiago Sayao [1] to OpenJFX Committer. > > Thiago is an OpenJFX community member, who has contributed 15 commits [2] to OpenJFX. > > Votes are due by September 27, 2021 at 15:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#tsayao > > [2] https://github.com/openjdk/jfx/search?q=author-name%3A%22Thiago+Sayao%22&s=author-date&type=commits > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer > From jvos at openjdk.java.net Tue Sep 14 12:01:06 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 14 Sep 2021 12:01:06 GMT Subject: [jfx17u] RFR: 8273279: Change JavaFX release version in jfx17u to 17.0.1 In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 13:27:59 GMT, Kevin Rushforth wrote: > Bump release version in `jfx17u` repo to 17.0.1 for the start of a new release. trivial ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx17u/pull/2 From jvos at openjdk.java.net Tue Sep 14 12:01:10 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 14 Sep 2021 12:01:10 GMT Subject: [jfx17u] RFR: 8273280: Update README.md and CONTRIBUTING.md for jfx17u In-Reply-To: References: Message-ID: <3gH8YYI2uU-Jrq-FYcfomRDFB4_98LNjrypRpEJCNhU=.b6758d74-071d-4fbb-9d60-1d61f48f6ce6@github.com> On Sat, 11 Sep 2021 13:25:35 GMT, Kevin Rushforth wrote: > This PR updates [`README.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/README.md) and [`CONTRIBUTING.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/CONTRIBUTING.md) to be suitable for update releases. The two files were copied from jfx11u, with the only changes being to replace "11" with "17" in the two files. CONTRIBUTING.md line 14: > 12: ``` > 13: > 14: where `LONG-COMMIT-HASH` is the long (40 char) commit hash of the fix as found in the main jfx repo. The Skara tooling will then note that it is a backport, and replace the title with the correct issue title. Should the next parts of the process be explained as well (e.g. optional review if no clean patch, merging?) ------------- PR: https://git.openjdk.java.net/jfx17u/pull/1 From kcr at openjdk.java.net Tue Sep 14 12:14:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Sep 2021 12:14:10 GMT Subject: [jfx17u] RFR: 8273280: Update README.md and CONTRIBUTING.md for jfx17u In-Reply-To: <3gH8YYI2uU-Jrq-FYcfomRDFB4_98LNjrypRpEJCNhU=.b6758d74-071d-4fbb-9d60-1d61f48f6ce6@github.com> References: <3gH8YYI2uU-Jrq-FYcfomRDFB4_98LNjrypRpEJCNhU=.b6758d74-071d-4fbb-9d60-1d61f48f6ce6@github.com> Message-ID: On Tue, 14 Sep 2021 11:58:15 GMT, Johan Vos wrote: >> This PR updates [`README.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/README.md) and [`CONTRIBUTING.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/CONTRIBUTING.md) to be suitable for update releases. The two files were copied from jfx11u, with the only changes being to replace "11" with "17" in the two files. > > CONTRIBUTING.md line 14: > >> 12: ``` >> 13: >> 14: where `LONG-COMMIT-HASH` is the long (40 char) commit hash of the fix as found in the main jfx repo. The Skara tooling will then note that it is a backport, and replace the title with the correct issue title. > > Should the next parts of the process be explained as well (e.g. optional review if no clean patch, merging?) Good idea, but I'd prefer to do that as a follow-on fix; that change could then be backported to jfx11u (as a clean backport). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/1 From jvos at openjdk.java.net Tue Sep 14 12:29:10 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 14 Sep 2021 12:29:10 GMT Subject: [jfx17u] RFR: 8273280: Update README.md and CONTRIBUTING.md for jfx17u In-Reply-To: References: <3gH8YYI2uU-Jrq-FYcfomRDFB4_98LNjrypRpEJCNhU=.b6758d74-071d-4fbb-9d60-1d61f48f6ce6@github.com> Message-ID: On Tue, 14 Sep 2021 12:11:00 GMT, Kevin Rushforth wrote: >> CONTRIBUTING.md line 14: >> >>> 12: ``` >>> 13: >>> 14: where `LONG-COMMIT-HASH` is the long (40 char) commit hash of the fix as found in the main jfx repo. The Skara tooling will then note that it is a backport, and replace the title with the correct issue title. >> >> Should the next parts of the process be explained as well (e.g. optional review if no clean patch, merging?) > > Good idea, but I'd prefer to do that as a follow-on fix; that change could then be backported to jfx11u (as a clean backport). makes sense ------------- PR: https://git.openjdk.java.net/jfx17u/pull/1 From jvos at openjdk.java.net Tue Sep 14 12:29:09 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 14 Sep 2021 12:29:09 GMT Subject: [jfx17u] RFR: 8273280: Update README.md and CONTRIBUTING.md for jfx17u In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 13:25:35 GMT, Kevin Rushforth wrote: > This PR updates [`README.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/README.md) and [`CONTRIBUTING.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/CONTRIBUTING.md) to be suitable for update releases. The two files were copied from jfx11u, with the only changes being to replace "11" with "17" in the two files. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/1 From kcr at openjdk.java.net Tue Sep 14 12:46:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Sep 2021 12:46:02 GMT Subject: [jfx17u] RFR: 8273280: Update README.md and CONTRIBUTING.md for jfx17u In-Reply-To: References: <3gH8YYI2uU-Jrq-FYcfomRDFB4_98LNjrypRpEJCNhU=.b6758d74-071d-4fbb-9d60-1d61f48f6ce6@github.com> Message-ID: On Tue, 14 Sep 2021 12:25:55 GMT, Johan Vos wrote: >> Good idea, but I'd prefer to do that as a follow-on fix; that change could then be backported to jfx11u (as a clean backport). > > makes sense I filed https://bugs.openjdk.java.net/browse/JDK-8273732 as a follow-up. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/1 From kcr at openjdk.java.net Tue Sep 14 12:53:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Sep 2021 12:53:19 GMT Subject: [jfx17u] Integrated: 8273280: Update README.md and CONTRIBUTING.md for jfx17u In-Reply-To: References: Message-ID: <6hVDkG4TPlI0kIyNuPOFeu7lTR1vI7CaShFn7QAqo9Q=.dc7aea36-9445-4a72-81cf-4c42725f4361@github.com> On Sat, 11 Sep 2021 13:25:35 GMT, Kevin Rushforth wrote: > This PR updates [`README.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/README.md) and [`CONTRIBUTING.md`](https://github.com/openjdk/jfx17u/blob/3082a845253dd00d46d36500abc42464459e59ed/CONTRIBUTING.md) to be suitable for update releases. The two files were copied from jfx11u, with the only changes being to replace "11" with "17" in the two files. This pull request has now been integrated. Changeset: d0f52c4a Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/d0f52c4a2c92a67a1dde72e7952a1ef9c0b6bb33 Stats: 237 lines in 2 files changed: 0 ins; 227 del; 10 mod 8273280: Update README.md and CONTRIBUTING.md for jfx17u Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx17u/pull/1 From kcr at openjdk.java.net Tue Sep 14 12:58:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Sep 2021 12:58:15 GMT Subject: [jfx17u] Integrated: 8273279: Change JavaFX release version in jfx17u to 17.0.1 In-Reply-To: References: Message-ID: <6psv6ALqmYhqFVEn1OhktYl5FclXW3XhlO_owo9_PRs=.a9e50097-d156-437e-ba7d-8985912bb8da@github.com> On Sat, 11 Sep 2021 13:27:59 GMT, Kevin Rushforth wrote: > Bump release version in `jfx17u` repo to 17.0.1 for the start of a new release. This pull request has now been integrated. Changeset: d7c612f0 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/d7c612f017971f1bbcefa9b5bf8bbd7d42d4a0e3 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8273279: Change JavaFX release version in jfx17u to 17.0.1 Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx17u/pull/2 From thiago.sayao at gmail.com Tue Sep 14 15:18:27 2021 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Tue, 14 Sep 2021 12:18:27 -0300 Subject: Gtk4 and Wayland In-Reply-To: <4b837870-9178-bb16-becc-044dea5a14ec@oracle.com> References: <4b837870-9178-bb16-becc-044dea5a14ec@oracle.com> Message-ID: Hi, It seems it would be very hard to have gtk4 and/or Wayland on JavaFX, unless we stop doing window manager related things. Resizing the window would be possible, but not stacking or moving it around. Wayland simply does not have this functionality and gtk4 removed it as well, as pointed out here https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html#adapt-to-gdkwindow-api-changes and here: https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4 Even on gtk3 it's a hard thing to do (deal with stacking and positioning). So I agree with the Gtk developers position to simply not deal with window management at this level, but it's somehow unfortunate. On the "experimenting with gtk4" side, it seems like I hit a dead end because gtk4 does not provide the needed functionality nor Wayland (to deal with it directly). Sticking with X11 also seems like not optimal for the long term, it will be replaced eventually. Maybe JavaFX should move away from window management as well? -- Thiago. Em qua., 1 de set. de 2021 ?s 08:42, Kevin Rushforth < kevin.rushforth at oracle.com> escreveu: > This seems reasonable to me as well, at least for JavaFX since we > already rely on Gtk for most of the windowing toolkit on Linux. > > -- Kevin > > On 9/1/2021 4:26 AM, Mario Torre wrote: > > On Wed, Sep 1, 2021 at 1:18 PM Johan Vos wrote: > >> Hi Thiago, > >> > >> I was thinking (and experimenting) in the same direction, and so far > that > >> is working good. I don't see disadvantages, but it would be good to find > >> out about it before we move forward. > >> Maybe the main issue to me is that GTK comes with lots of dependencies. > We > >> already have that situation today, so it is not going to be worse. But > if > >> we would use the Wayland protocol on a lower level (with a > Wayland-specific > >> glass platform, instead of GTK), we could probably reduce the > dependencies. > >> However, this comes at the price of creating *and maintaining* more > >> low-level code. > >> > >> I've been running GTK3 on Wayland and that works fine too. However, it > >> might be better to focus Wayland support for GTK4. I think there won't > be > >> many installs that have no X11, but only Wayland, and that have GTK3 > and no > >> GTK4. > > I tend to agree with you, I think we should consider this for Wakefield > too. > > > > Cheers, > > Mario > > > >> - Johan > >> - Johan > >> > >> On Tue, Aug 31, 2021 at 11:03 PM Thiago Milczarek Say?o < > >> thiago.sayao at gmail.com> wrote: > >> > >>> Hi, > >>> > >>> I did some investigation on gtk4 and wayland. > >>> > >>> After some research I ended up with the conclusion that the best way > is to > >>> do a separate gtk4 backend, that would support X11 and Wayland. > >>> > >>> This would be a good start: > >>> https://github.com/openjdk/jfx/pull/77/files > >>> > >>> Why? > >>> > >>> Gtk4 moves the decoration to the client side, which is GREAT since > knowing > >>> the window size with decoration was a real pain. > >>> > >>> We probably won't want to do all the decoration work, Gtk does that, > but on > >>> GtkWindow level, not GdkSurface (which replaces GdkWindow). > >>> > >>> Thus the move to use "more Gtk" (hence "less Gdk") which is exactly > what > >>> the PR does. It also removes Applet code > >>> > >>> This is also a good starting point: > >>> https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html > >>> > >>> --Thiago. > >>> > > > > From github.com+85555697+andreas-heger at openjdk.java.net Tue Sep 14 17:06:06 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Tue, 14 Sep 2021 17:06:06 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v2] In-Reply-To: References: Message-ID: > The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url) Andreas Heger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into fix-8255015 - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/531/files - new: https://git.openjdk.java.net/jfx/pull/531/files/66b361a0..3973a2e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=00-01 Stats: 344178 lines in 6843 files changed: 186475 ins; 110834 del; 46869 mod Patch: https://git.openjdk.java.net/jfx/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531 PR: https://git.openjdk.java.net/jfx/pull/531 From kcr at openjdk.java.net Tue Sep 14 17:29:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Sep 2021 17:29:10 GMT Subject: RFR: 8270107: Open source FXMediaPlayer test app In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds during development. > - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. @aghaisas or @johanvos can one of you be the second reviewer on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/613 From jvos at openjdk.java.net Tue Sep 14 18:09:10 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 14 Sep 2021 18:09:10 GMT Subject: RFR: 8270107: Open source FXMediaPlayer test app In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds during development. > - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. I partially tested it, will do the remainder now. ------------- PR: https://git.openjdk.java.net/jfx/pull/613 From jvos at openjdk.java.net Tue Sep 14 18:33:06 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 14 Sep 2021 18:33:06 GMT Subject: RFR: 8270107: Open source FXMediaPlayer test app In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds during development. > - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. tested on linux and mac, works great. Good addition! ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/613 From github.com+3197675+abhinayagarwal at openjdk.java.net Tue Sep 14 21:05:36 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Tue, 14 Sep 2021 21:05:36 GMT Subject: RFR: 8273754: Re-introduce Automatic-Module-Name in empty jars Message-ID: Re-introduce `Automatic-Module-Name` for empty jars until a better alternative to empty jars has been finalized. ------------- Commit messages: - 8273754: Re-introduce Automatic-Module-Name in empty jars Changes: https://git.openjdk.java.net/jfx/pull/623/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=623&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273754 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/623.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/623/head:pull/623 PR: https://git.openjdk.java.net/jfx/pull/623 From kcr at openjdk.java.net Tue Sep 14 21:22:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Sep 2021 21:22:40 GMT Subject: RFR: 8273754: Re-introduce Automatic-Module-Name in empty jars In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 20:59:47 GMT, Abhinay Agarwal wrote: > Re-introduce `Automatic-Module-Name` for empty jars until a better alternative to empty jars has been finalized. Looks good. I presume that @johanvos will be the second reviewer? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/623 From almatvee at openjdk.java.net Wed Sep 15 00:16:58 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Wed, 15 Sep 2021 00:16:58 GMT Subject: Integrated: 8270107: Open source FXMediaPlayer test app In-Reply-To: References: Message-ID: On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds during development. > - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. This pull request has now been integrated. Changeset: 51265c0b Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/51265c0b8762859ec9926e03965f471287e81213 Stats: 5970 lines in 26 files changed: 5970 ins; 0 del; 0 mod 8270107: Open source FXMediaPlayer test app Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/613 From nlisker at gmail.com Wed Sep 15 00:28:11 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 15 Sep 2021 03:28:11 +0300 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl> References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl> Message-ID: > > Sorry, I'm not quite sure what you mean by this. Could you elaborate? > The methods orElse and orElseGet are present in the PoC, and I think > they're highly useful to have to deal with nulls. The methods that you call orElse and orElseGet return an ObservableValue. The Optional methods with the same names return the wrapped value (of type T). For comparison, ReactFX has: T getOrElse(T defaultValue) T getOrSupply(Supplier defaultSupplier) Val orElseConst(T other) Val orElse(ObservableValue other) So it deals with both getting the wrapped value in null cases and with getting a "dynamic value" in null cases. I find the Optional-like method 'T getOrElse(T defaultValue)' useful (along with others such as ifPresent because Optional is just useful for dealing with wrapped values). What I'm saying is that we should be careful with the names if we include both "constant" and "dynamic" versions of 'orElse'-like methods. The null check in ReactFX's #computeValue is > actually checking the result of the mapping function, not whether the > function instance itself was null. > I didn't mean the null-ness of the map argument. What I meant was that there is this implementation, which is similar to what ReactFX does: public static ObservableValue mapping(ObservableValue source, Function mapper) { return nullableMapping(source, mapper.apply(v)); // don't deal with a null v here } public static ObservableValue nullableMapping(ObservableValue source, Function mapper) { return new LazyObjectBinding<>() { ... @Override protected U computeValue() { T value = source.getValue(); return value == null ? null ? mapper.apply(value); // do it here instead } }; } --- As for my points 3 and 4, I'll have to try and play with the implementation myself, which will be easier to do when there is some PR in the works. To close "Bindings.select*(): add new type-safe template based API > instead of legacy-style set of methods" we'd need the flatMap/select > method to be included. Yes. I think that we can include flatMap in this iteration, perhaps as a separate PR? I don't think we really need specialized methods for primitives (or at > least, not right away). At this point the primitive versions only > really differ in what value they'd return if the binding would be null > and perhaps they do a little less boxing/unboxing. Since you can select > the default value with #orElse which is more flexible. I don't see much > use to add those variants. I agree, I would avoid bloating the primitive specialization classes for now, especially when Valhalla is planned to take care of those. The ticket is a bit unclear as I can't see what type "x" is. > Yes, but I got the impression that either way it can be solved with map (or flatMap). On Tue, Sep 14, 2021 at 8:44 AM John Hendrikx wrote: > > > On 14/09/2021 03:14, Nir Lisker wrote: > > Sounds good. > > > > Some points I have (maybe some are premature): > > > > 1. I still think that adding the Optional methods for orElse and > orElseGet > > could be useful. Unless I can be convinced otherwise, I suggest that we > be > > careful with the naming of current methods that return a binding. > > Sorry, I'm not quite sure what you mean by this. Could you elaborate? > The methods orElse and orElseGet are present in the PoC, and I think > they're highly useful to have to deal with nulls. > > > 2. I see that in ReactFX the Val.map will pass to MappedVal the mapping > > function as-is, and the null check is done in computeValue(). In your > > implementation, the LazyBinding (equivalent of MappedVal) is passed a > > composite mapping that deals with null and the computeValue() can just > use > > that new mapping function. I think that the end behavior is the same, but > > does your way use more memory for the extra Function lambda? > > I think you may have misinterpreted what happens here. I'm ensuring that > the mapping function itself isn't null (fail fast) by using > Objects.requireNonNull -- it doesn't produce a new lambda. ReactFX > doesn't do this check and will throw a NPE when the mapping function is > used for the first time. The null check in ReactFX's #computeValue is > actually checking the result of the mapping function, not whether the > function instance itself was null. > > > 3. Why does nullableMapping creates an anonymous subtype of LazyBinding, > > while flatMapping creates a concrete instance of FlatMapBinding? > > I suppose I felt it was small enough to inline, but there's no > particular reason to write it one way or the other. The nullableMapping > can be extracted to a class to make it more consistent. > > > 4. Why does orElseGet call Bindings.nullableMapping directly, while map > > calls Bindings.mapping which in turn calls Bindings.nullableMapping? > > It's because of the null check. For mapping I could wrap the function > parameter in Objects.requireNonNull as it will be evaluated immediately. > For orElseGet, I had to put the check on a separate line (as the first > use of supplier parameter is inside a lambda). > > I prefer to do null checks as early as possible (so you get a better > stack trace) but I also prefer to write interface default > implementations as short as possible. I could write #map to look like > #orElseGet but it would become one line longer, or I could write > #orElseGet to do a call to a separate Bindings method and move the null > check there but then the stack trace for the NPE would no longer point > to the #orElseGet interface method as first trace line. > > I can rewrite this however if you would like, but that's sort of the > reasoning I had I think when I wrote this code balancing short default > implementations vs delayed null checks. > > If you would want it more consistent, then I think I'd prefer to write > #map like #orElseGet. > > > 5. I noticed also that subscribeInvalidations in ObservableValue will > need > > to be hidden. > > Yes, that should be no problem. We can either fall back to using > standard listener management, or create a small helper that works with > the subscription model. > > > Some related JBS issues that I found that we might be able to use (or at > > least close at some point): > > https://bugs.openjdk.java.net/browse/JDK-8091544 > > To close "Bindings.select*(): add new type-safe template based API > instead of legacy-style set of methods" we'd need the flatMap/select > method to be included. > > I don't think we really need specialized methods for primitives (or at > least, not right away). At this point the primitive versions only > really differ in what value they'd return if the binding would be null > and perhaps they do a little less boxing/unboxing. Since you can select > the default value with #orElse which is more flexible I don't see much > use to add those variants. > > > https://bugs.openjdk.java.net/browse/JDK-8091316 > > "Add a Bindings.map() method". > > The ticket is a bit unclear as I can't see what type "x" is. > > So this seems to be for a use case where an Observable "x" should be > bound with some transformation to the windowTitleProperty. I'm assuming > x is an Observable because it is used in the list of dependencies. > > If x is only an Observable, then I don't think the PoC will help. > > If x is more (it is hard to tell from the ticket) you might be able to > map it. However, x seems to have a "getY()" method so it doesn't look > like it is a Property or ObservableValue... > > Making some assumptions here and assuming x has an y property itself, > you could write this as: > > windowsTitleProperty.bind(x.flatMap(XClass::yProperty).map(y -> { > switch(y) { > case ... > } > }); > > Or: > > windowsTitleProperty.bind(x.map(x2 -> { > switch(x2.getY()) { > case ... > } > }); > > Or perhaps x is the correct property already, then it be: > > windowsTitleProperty.bind(x.map(y -> { > switch(y) { > case ... > } > }); > > --John > > > On Mon, Sep 13, 2021 at 3:05 AM John Hendrikx wrote: > > > >> > >> > >> On 12/09/2021 02:05, Nir Lisker wrote: > >>> I've gotten back to look at this. > >>> > >>> For now I'm dealing only with the nullableMapping method in Bindings so > >>> we can limit the amount of new classes to LazyObjectBinding > >>> (FlatMapBinding and ConditionalBinding can come later). This method is > >>> used by map, orElse and orElseGet in ObservableValue. Of these, map is > >>> the only fundamental one since the other 2 can be represented by it. I > >>> don't mind keeping them in the discussion, though I will be centered on > >>> the map method. > >>> > >>> The implementation of these methods rely on Bindings, > LazyObjectBinding, > >>> and Subscription in the current implementation. I think that we can > >>> introduce these internally for now. The biggest hurdle left are the > >>> public changes to ObjectBinding. If we add protected methods, we need > to > >>> be sure that by the end of this large task they would have been the > >>> right ones to add and at the right place. This is why I recommend > adding > >>> them at the package visibility level and add LazyObjectBinding (and > >>> friends) in its package so they can extend it. I understand that this > >>> can look ugly, but moving internal implementation is cheap, and in this > >>> case, since the coupling involves about 3 classes, is very cheap. This > >>> will lower the initial integration barrier and let the community get > >>> used to- and give feedback on the new changes. > >> > >> I think that's a good idea, there is no direct need to make those > >> protected methods part of the public API as the usefulness of those > >> methods will be limited and the major use case will basically be > >> provided by LazyObjectBinding already. > >> > >>> This will leave only 1 change that we are committed to, and that's the > >>> new API on ObservableValue (which is the map method in this case). The > >>> method looks good; the only question, which has arisen in a few places, > >>> is how to handle null. As we discussed here, this method works like its > >>> ReactFX counterpart, ignoring null. My questions would be: > >>> 1. Is there a good reason to allow null? If so, do we add a new method > >>> for it, or do we pass some parameter to the current method to indicate > >> that? > >> > >> In JavaFX, null is something we have to deal in some fashion as > >> properties can easily be null. For the "primitive" properties, null (if > >> encountered) is translated to a default value. For StringProperty it > >> could be an empty string although JavaFX doesn't do this. For > >> ObjectProperty there is no sensible default possible. > >> > >> In ReactFX, nulls are indeed skipped when mapping as it considers null > >> to be an empty value, and empty values are skipped according to the > >> documentation. The code below will not throw an NPE in the mapping > >> function and will simply result in null: > >> > >> Var.newSimpleVar(null).map(x -> x + "2").getValue(); > >> > >> This is similar to the PoC implementation: > >> > >> new SimpleStringProperty().map(x -> x + "2").getValue()); > >> > >> Having worked with ReactFX and also the PoC, I think it would be very > >> cumbersome to have to deal with nulls in mapping functions, as many > >> simple mappings expressed with a short lambda would need to deal with > >> the null case with a ternary or an if/else block. > >> > >> In the PoC any mapping you could need that requires mapping null > >> explicitely can be expressed in another form: > >> > >> .map(x -> x == null ? "empty!" : x + "2") > >> > >> becomes: > >> > >> .map(x -> x + "2").orElse("empty!) > >> > >> which is not only more concise, but allows to delay dealing with null > >> until the very end: > >> > >> .map(x -> x == null ? "empty!" : fetchDataWhichCouldBeNull(x)) > >> .map(x -> x == null ? "empty!" : x + "2") > >> > >> versus: > >> > >> .map(Helper::fetchDataThatCouldBeNull) > >> .map(x -> x + "2") > >> .orElse("empty!") > >> > >> You don't have to delay it though, if for some reason you would want to > >> map the 2nd null case differently, you could use "orElse" after each > >> mapping still. > >> > >> Although for mapping this may seem somewhat contrived, for selecting (or > >> flatMapping) where you go through a chain of properties (like > >> Node->Scene->Window) being able to delay dealing with nulls leads to > >> more concise and IMHO more expressive code. > >> > >> So in summary, and to answer your first question, I don't think there is > >> a good reason to allow null to be passed to mapping functions. We do > >> need to deal with nulls though, and that's what "orElse" is for. This > >> could also be done with an additional parameter to "map" (a > >> "mapOrDefault" similar to "getOrDefault" from the collections API) but I > >> think we'd be better served with multiple methods that take a single > >> argument as the resulting code is easier to understand especially when > >> one of the arguments is a lambda. > >> > >> > >>> 2. If we want to replace the Bindings.select (non-type safe) API, can > we > >>> do it with our current way of treating null? > >> > >> In the current Bindings.select API, null is skipped when encountered and > >> the resulting value of the chain will be null. This is exactly what > >> "flatMap" in the PoC does as well, in other words: > >> > >> Bindings.select(nodeProperty, "scene", "window", "showing") > >> > >> is exactly equivalent to: > >> > >> nodeProperty.flatMap(Node::sceneProperty) > >> .flatMap(Scene::windowProperty) > >> .flatMap(Window::showingProperty) > >> > >> No null checks are needed, and the binding will be null if any of the > >> selected properties contain null. Note that both versions return null > >> despite the fact that the last property selected is a primitive boolean > >> which normally cannot hold null. > >> > >> However, Bindings also offers selectBoolean. In this case it does > >> indeed return false when any of the properties contains null, but it > >> also logs this uncomfortable warning then: > >> > >> WARNING: Value of select-binding has wrong type, returning default value > >> (+ stack trace omitted) > >> > >> The warning is somewhat deceptive as the binding does refer to a boolean > >> so it is not strictly of the wrong type, but an intermediate value > >> encountered was null and this cannot be cast to a primitive boolean. It > >> should probably just convert to the default value without any warning. > >> > >> So, to answer your question, I think we can indeed replace > >> Bindings.select with the PoC's typesafe equivalent. There is almost no > >> need to create specific primitive versions of this mechanism as users > >> can use "orElse" to map to a suitable primitive value as the last step > >> if null is undesired. > >> > >>> Do you think that this is a valid approach? > >> > >> Yes, I think our messages may have crossed paths as I suggested limiting > >> the API (based on your earlier recommendations) in a post on the > >> "Enhancements for JavaFX 18" thread in a reply to Kevin Rushforth. > >> > >> Your suggestion takes this a bit further by leaving the new methods in > >> ObjectBinding package protected and reducing the new API in > >> ObservableValue to its bare essentials. I think that's a fine approach > >> as it keeps the API that we're commiting to small and allows the highest > >> flexibility for future extensions. > >> > >> If an agreement can be reached on the initial API, I can rework the PoC > >> and also add the unit tests (I'll need to convert the JUnit 5 tests I > >> have to JUnit 4). > >> > >> --John > >> > >>> > >>> - Nir > >>> > >>> On Wed, Apr 7, 2021 at 11:30 PM John Hendrikx >>> > wrote: > >>> > >>> On 07/04/2021 03:41, Nir Lisker wrote: > >>> > In the PoC I made I specifically also disallowed 'null' as an > >>> input > >>> > > >>> > > >>> > I like the way ReactFX does it where the property is empty. I > >>> think that > >>> > this is also what you mean by disallowing `null` (in other > >> contexts, > >>> > "disallowing null" would mean throwing an exception). > >>> > >>> Yes, it is the same concept as ReactFX calling a property "empty", > >>> but I > >>> was hesitant to call this as `null` is a valid value for many > JavaFX > >>> properties (a Scene can be null, a String can be null, etc.) which > I > >>> don't think means the same as it being empty (in the Optional > sense). > >>> But as long as the documentation is clear, I don't mind calling it > >>> either. > >>> > >>> > > >>> > Not entirely sure what you mean by this. > >>> > > >>> > > >>> > Basically, what you said. My point was that this is a different > API > >>> > section. The first deals with expanding the > observables/properties > >>> > methods. The second with listeners methods. Even if mapping a > >> property > >>> > requires a new listening model, like subscriptions, this is done > >> under > >>> > the hood. Exposing this API should be a separate step. At least > >> that's > >>> > how I see it. > >>> > >>> Yes, I think it is good to limit new API as much as possible to > >> reduce > >>> scope and increase the chances of its acceptance. The subscription > >>> parts > >>> can be designed separately and do not need to be public at this > >> point. > >>> They can be moved to a helper, or the implementation can take the > >> extra > >>> effort to use standard listeners. > >>> > >>> > > >>> > I'd be happy to spend more time and work on this. Perhaps it > >>> would be > >>> > possible to collaborate on this? > >>> > > >>> > > >>> > That would be good. I will need to re-review the ReactFX > internals > >> and > >>> > see how your proposal differs exactly. > >>> > >>> Yes, I think that would be good to do. > >>> > >>> I've done some comparisons myself and didn't find a difference in > >>> functionality with `Val` (so far). It is a new implementation > >> though, I > >>> didn't really look at how `Val` was done internally as implementing > >> it > >>> directly into JavaFX is quite different (I had to make a few minor > >>> changes in `ObjectBinding` to allow for the choice of lazy > >> binding). I > >>> was also initially more focused on Streams only to realize at a > later > >>> point that having a Stream implement ObservableValue was not going > >>> to be > >>> pretty (I suspect this also happened when ReactFX was created, > which > >> is > >>> why Val/Var were later introduced in 2.x). > >>> > >>> Both the PoC and Val do lazy binding and are null safe and provide > >>> methods to deal with null/empty. > >>> > >>> The main thing I didn't do yet is provide a `filter` method. > >> Filtering > >>> properties that you want to use for bindings seems awkard as a > >> binding > >>> should always have some kind of value. The `filter` method in > ReactFX > >>> basically maps the value to `null` when it doesn't match the > filter. > >>> I've left this out as you can easily achieve this with `map` and > >>> `filter` seems to be too easy to misunderstand. > >>> > >>> Aside from that, ReactFX's Val offers a lot of other methods that > >> are I > >>> think a bit too specialized to consider at this point, like the > >>> `animate`, `pin`, `mapDynamic` and `suspendable` methods. > >>> > >>> Val also has all the other `Optional` methods (ifPresent, > isPresent, > >>> isEmpty) but I think they may make the API a bit confusing (an > >>> observable value is not the same as an optional). I've also not > had a > >>> need for these so far in practice and you can easily convert the > >>> current > >>> value to get this functionality with `Optional.ofNullable`. > >>> > >>> Finally Val offers a few methods to convert to ReactFX's streams. > >> While > >>> convenient, I think static methods like `Values.of`, > >> `Invalidations.of` > >>> or `Changes.of` would make for a less cluttered API to do stream > >>> conversions -- this would also make it possible to leave this part > of > >>> the API up to a 3rd party. > >>> > >>> > By the way, do you make a distinction between ReactFX's Val and > >>> Var in > >>> > your proposal (one being read-only)? > >>> > >>> No, `ObservableValue` is basically the same as `Val`, and the > >>> equivalent > >>> to `Var` is `ObjectProperty`. Aside from it being a good companion > >> to > >>> `Val` (and less typing), I don't see a reason to implement `Var`. > >>> > >>> --John > >>> > >>> > > >>> > On Sun, Apr 4, 2021 at 12:43 PM John Hendrikx >>> > >>> > >> wrote: > >>> > > >>> > > >>> > > >>> > On 02/04/2021 08:47, Nir Lisker wrote: > >>> > > Hi John, > >>> > > > >>> > > I've had my eyes set on ReactFX enhancements for a while > too, > >>> > especially as > >>> > > a replacement for the unsafe "select" mechanism. One of the > >>> things > >>> > that > >>> > > kept me from going forward with this is seeing what > Valhalla > >>> will > >>> > bring. > >>> > > Generic specialization might save a lot of duplication work > >> on > >>> > something > >>> > > like this, and Tomas touched another related issue [1], but > >>> since > >>> > it could > >>> > > be a long time before that happens, it's worth planning > what > >> we > >>> > can extract > >>> > > from ReactFX currently. > >>> > > >>> > Agreed, Valhalla is certainly a highly anticipated feature > but > >> I > >>> > fear it > >>> > is still a couple of years away. > >>> > > >>> > Even without any initial support for dealing with "? extends > >>> Number" > >>> > from the various ObservableValue specializations I think > >>> looking into > >>> > this can already be tremendous help. > >>> > > >>> > The proof of concept mainly requires you convert the Number > to > >> a > >>> > suitable type when reading the property but has no problems > in > >> the > >>> > other > >>> > direction: > >>> > > >>> > label.widthProperty().map(Number::doubleValue).map(x -> > x > >>> + 1); > >>> > > >>> > Not pretty, but certainly workable. Specific methods could be > >>> > introduced > >>> > (even at a later time) to make this more streamlined, similar > >>> to what > >>> > the Stream API offers with 'mapToDouble' etc. > >>> > > >>> > > I think that we should break the enhancements into parts. > >>> > > The first that I would advise to look at are the additions > to > >>> > > properties/observables. Tomas had to create Val and Var > >>> because he > >>> > couldn't > >>> > > change the core interfaces, but we can. Fitting them with > >>> the Optional > >>> > > methods like `isPresent`, `isEmpty`, `ifPresent`, `map`. > >>> `flatMap` > >>> > etc.; > >>> > > and `select` and friends, is already a good start that will > >>> > address many > >>> > > common requirements. > >>> > > >>> > Yes, Val/Var had to be created for that reason, and also > >> because > >>> > properties don't quite behave the same as streams -- streams > >>> with a > >>> > "toBinding" method results in things people didn't quite > >> expect. > >>> > > >>> > As far as the Optional methods go, I'm not entirely sure > >>> properties > >>> > would benefit from all of them. Properties are not immutable > >> like > >>> > Optional and it may make less sense to fit them with > >> 'isPresent', > >>> > 'isEmpty' and 'ifPresent' ('ifPresent' would I think need to > >>> behave > >>> > similar to 'addListener' or 'subscribe'). > >>> > > >>> > In the PoC I made I specifically also disallowed 'null' as an > >>> input for > >>> > functions like 'map' and 'flatMap' (opting to use 'orElse' > >>> semantics > >>> > for > >>> > 'null'), as this for allows much cleaner mapping (and > >>> especially flat > >>> > mapping when selecting nested properties). If 'null' were to > be > >>> > allowed, > >>> > I think at a minimum we'd need to add another method to allow > >>> for easy > >>> > selecting of nested properties to avoid: > >>> > > >>> > obs.flatMap(x -> x == null ? null : x.otherProperty()) > >>> > > >>> > > The second part is related to listeners. The subscription > >> model > >>> > and event > >>> > > streams try to solve the memory issues with hard and weak > >>> > references, and > >>> > > allow better composition. > >>> > > >>> > Not entirely sure what you mean by this. JavaFX's current > >>> model uses > >>> > weak references which was I think an unfortunate decision as > >>> it can > >>> > result in huge confusion. For example, a direct binding will > >>> work, but > >>> > with an indirection step a binding stops working: > >>> > > >>> > button.textProperty() > >>> > .concat("World") // weak binding used here > >>> > .addListener((obs, old, cur) -> > >> System.out.println(cur)); > >>> > > >>> > The above stops working, but without the 'concat' it keeps > >>> working. > >>> > > >>> > I think the use of weak listeners should be avoided and > >>> instead other > >>> > mechanisms should be provided to make cleaning up easier. > This > >>> is the > >>> > main reason for 'conditionOn' and why ReactFX even had a > >>> specialized > >>> > version of it: 'conditionOnShowing(Node)'. > >>> > > >>> > > The third part is for collections - things like > >>> transformation lists > >>> > > (LiveList) and for other collections. > >>> > > >>> > This is indeed best saved for last. The problems there I > think > >>> are less > >>> > of an issue for now. > >>> > > >>> > > Since these share behavior under the hood, we need to look > >>> ahead, > >>> > but in > >>> > > terms of functionality, I think we should take smaller > >> steps. It > >>> > will also > >>> > > be easier to propose these then. > >>> > > >>> > I've for this reason kept the PoC small with only the most > >> basic > >>> > functionality. I did however add some work for a different > >>> > subscription > >>> > model, mainly because the internals of this code benefits > >>> greatly from > >>> > it. It is however kept to a minimum. > >>> > > >>> > I'd be happy to spend more time and work on this. Perhaps it > >>> would be > >>> > possible to collaborate on this? > >>> > > >>> > --John > >>> > > >>> > > > >>> > > - Nir > >>> > > > >>> > > [1] > >>> > > > >>> > > >>> > >> > https://github.com/TomasMikula/ReactFX/wiki/Creating-a-Val-or-Var-Instance#the-javafx-propertynumber-implementation-issue > >>> > > > >>> > > On Wed, Mar 24, 2021 at 11:49 PM John Hendrikx > >>> > >>> > >> wrote: > >>> > > > >>> > >> I just wanted to draw some attention to a recent proof of > >>> concept > >>> > I made > >>> > >> in this pull request: > >> https://github.com/openjdk/jfx/pull/434 > >>> > >> > >>> > >> It is based on the work I did in > >>> > >> https://github.com/hjohn/hs.jfx.eventstream which is in > >>> part based on > >>> > >> work done in ReactFX by Tomas Mikula. The PR itself > however > >>> shares no > >>> > >> code with ReactFX and is > >>> > >> completely written by me. > >>> > >> > >>> > >> If there is interest, I'm willing to invest more time in > >>> > smoothing out > >>> > >> the API and documentation, investigating further how this > >> would > >>> > interact > >>> > >> with the primitive types and adding unit test coverage (I > >> have > >>> > extensive > >>> > >> tests, but thesea are written in JUnit 5, so they would > >> require > >>> > >> conversion or JavaFX could move to support JUnit 5). > >>> > >> > >>> > >> What follows below is the text of the PR for easy reading. > >>> > Feedback is > >>> > >> appreciated. > >>> > >> > >>> > >> ================ > >>> > >> > >>> > >> This is a proof of concept of how fluent bindings could be > >>> > introduced to > >>> > >> JavaFX. The main benefit of fluent bindings are ease of > >>> use, type > >>> > safety > >>> > >> and less surprises. Features: > >>> > >> > >>> > >> Flexible Mappings > >>> > >> Map the contents of a property any way you like with map, > >>> or map > >>> > nested > >>> > >> properties with flatMap. > >>> > >> > >>> > >> Lazy > >>> > >> The bindings created are lazy, which means they are always > >>> > invalid when > >>> > >> not themselves observed. This allows for easier garbage > >>> > collection (once > >>> > >> the last observer is removed, a chain of bindings will > stop > >>> observing > >>> > >> their parents) and less listener management when dealing > >>> with nested > >>> > >> properties. Furthermore, this allows inclusion of such > >>> bindings in > >>> > >> classes such as Node without listeners being created when > >>> the binding > >>> > >> itself is not used (this would allow for the inclusion of > a > >>> > >> treeShowingProperty in Node without creating excessive > >>> listeners, see > >>> > >> this fix I did in an earlier PR: #185) > >>> > >> > >>> > >> Null Safe > >>> > >> The map and flatMap methods are skipped, similar to > >>> > java.util.Optional > >>> > >> when the value they would be mapping is null. This makes > >>> mapping > >>> > nested > >>> > >> properties with flatMap trivial as the null case does not > >>> need to be > >>> > >> taken into account in a chain like this: > >>> > >> > >>> > > >>> > >> > node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty). > >>> > >> > >>> > >> Instead a default can be provided with orElse or > orElseGet. > >>> > >> > >>> > >> Conditional Bindings > >>> > >> Bindings can be made conditional using the conditionOn > >>> method. A > >>> > >> conditional binding retains its last value when its > >>> condition is > >>> > false. > >>> > >> Conditional bindings donot observe their source when the > >>> condition is > >>> > >> false, allowing developers to automatically stop listening > >> to > >>> > properties > >>> > >> when a certain condition is met. A major use of this > >> feature is > >>> > to have > >>> > >> UI components that need to keep models updated which may > >>> outlive > >>> > the UI > >>> > >> conditionally update the long lived model only when the UI > >> is > >>> > showing. > >>> > >> > >>> > >> Some examples: > >>> > >> > >>> > >> void mapProperty() { > >>> > >> // Standard JavaFX: > >>> > >> > >> label.textProperty().bind(Bindings.createStringBinding(() -> > >>> > >> text.getValueSafe().toUpperCase(), text)); > >>> > >> > >>> > >> // Fluent: much more compact, no need to handle null > >>> > >> > label.textProperty().bind(text.map(String::toUpperCase)); > >>> > >> } > >>> > >> > >>> > >> void calculateCharactersLeft() { > >>> > >> // Standard JavaFX: > >>> > >> > >>> > >> > >>> > > >>> > >> > label.textProperty().bind(text.length().negate().add(100).asString().concat(" > >>> > >> > >>> > >> characters left")); > >>> > >> > >>> > >> // Fluent: slightly more compact and more clear (no > >>> negate needed) > >>> > >> label.textProperty().bind(text.orElse("").map(v -> 100 > - > >>> > v.length() + > >>> > >> " characters left")); > >>> > >> } > >>> > >> > >>> > >> void mapNestedValue() { > >>> > >> // Standard JavaFX: > >>> > >> label.textProperty().bind(Bindings.createStringBinding( > >>> > >> () -> employee.get() == null ? "" > >>> > >> : employee.get().getCompany() == null ? "" > >>> > >> : employee.get().getCompany().getName(), > >>> > >> employee > >>> > >> )); > >>> > >> > >>> > >> // Fluent: no need to handle nulls everywhere > >>> > >> label.textProperty().bind( > >>> > >> employee.map(Employee::getCompany) > >>> > >> .map(Company::getName) > >>> > >> .orElse("") > >>> > >> ); > >>> > >> } > >>> > >> > >>> > >> void mapNestedProperty() { > >>> > >> // Standard JavaFX: > >>> > >> label.textProperty().bind( > >>> > >> > >>> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), > >>> > >> "window", "showing")) > >>> > >> .then("Visible") > >>> > >> .otherwise("Not Visible") > >>> > >> ); > >>> > >> > >>> > >> // Fluent: type safe > >>> > >> label.textProperty().bind(label.sceneProperty() > >>> > >> .flatMap(Scene::windowProperty) > >>> > >> .flatMap(Window::showingProperty) > >>> > >> .orElse(false) > >>> > >> .map(showing -> showing ? "Visible" : "Not Visible") > >>> > >> ); > >>> > >> } > >>> > >> > >>> > >> void updateLongLivedModelWhileAvoidingMemoryLeaks() { > >>> > >> // Standard JavaFX: naive, memory leak; UI won't get > >> garbage > >>> > collected > >>> > >> > >>> listView.getSelectionModel().selectedItemProperty().addListener( > >>> > >> (obs, old, current) -> > >>> > >> longLivedModel.lastSelectedProperty().set(current) > >>> > >> ); > >>> > >> > >>> > >> // Standard JavaFX: no leak, but stops updating after a > >>> while > >>> > >> > >>> listView.getSelectionModel().selectedItemProperty().addListener( > >>> > >> new WeakChangeListener<>( > >>> > >> (obs, old, current) -> > >>> > >> longLivedModel.lastSelectedProperty().set(current) > >>> > >> ) > >>> > >> ); > >>> > >> > >>> > >> // Standard JavaFX: fixed version > >>> > >> listenerReference = (obs, old, current) -> > >>> > >> longLivedModel.lastSelectedProperty().set(current); > >>> > >> > >>> > >> > >>> listView.getSelectionModel().selectedItemProperty().addListener( > >>> > >> new WeakChangeListener<>(listenerReference) > >>> > >> ); > >>> > >> > >>> > >> // Fluent: naive, memory leak... fluent won't solve > >> this... > >>> > >> listView.getSelectionModel().selectedItemProperty() > >>> > >> > >> .subscribe(longLivedModel.lastSelectedProperty()::set); > >>> > >> > >>> > >> // Fluent: conditional update when control visible > >>> > >> > >>> > >> // Create a property which is only true when the UI is > >>> visible: > >>> > >> ObservableValue showing = > >> listView.sceneProperty() > >>> > >> .flatMap(Scene::windowProperty) > >>> > >> .flatMap(Window::showingProperty) > >>> > >> .orElse(false); > >>> > >> > >>> > >> // Use showing property to automatically disconnect > long > >>> lived > >>> > model > >>> > >> // allowing garbage collection of the UI: > >>> > >> listView.getSelectionModel().selectedItemProperty() > >>> > >> .conditionOn(showing) > >>> > >> > .subscribe(longLivedModel.lastSelectedProperty()::set); > >>> > >> > >>> > >> // Note that the 'showing' property can be provided in > >>> > multiple ways: > >>> > >> // - create manually (can be re-used for multiple > >>> bindings though) > >>> > >> // - create with a helper: Nodes.showing(Node node) -> > >>> > >> ObservableValue > >>> > >> // - make it part of the Node class; as the fluent > >> bindings > >>> > only bind > >>> > >> themselves > >>> > >> // to their source when needed (lazy binding), this > >>> won't create > >>> > >> overhead > >>> > >> // for each node in the scene > >>> > >> } > >>> > >> Note that this is based on ideas in ReactFX and my own > >>> experiments in > >>> > >> https://github.com/hjohn/hs.jfx.eventstream. I've come to > >> the > >>> > conclusion > >>> > >> that this is much better directly integrated into JavaFX, > >>> and I'm > >>> > hoping > >>> > >> this proof of concept will be able to move such an effort > >>> forward. > >>> > >> > >>> > >> --John > >>> > >> > >>> > > > >>> > > >>> > >> > > > From jvos at openjdk.java.net Wed Sep 15 06:59:47 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 15 Sep 2021 06:59:47 GMT Subject: RFR: 8273754: Re-introduce Automatic-Module-Name in empty jars In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 20:59:47 GMT, Abhinay Agarwal wrote: > Re-introduce `Automatic-Module-Name` for empty jars until a better alternative to empty jars has been finalized. This is ok. For the long-term solution, we need a clear and consistent view on what the best approach is to deal with modules that contain platform-specific native code and platform-specific java code. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/623 From github.com+3197675+abhinayagarwal at openjdk.java.net Wed Sep 15 09:01:51 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Wed, 15 Sep 2021 09:01:51 GMT Subject: Integrated: 8273754: Re-introduce Automatic-Module-Name in empty jars In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 20:59:47 GMT, Abhinay Agarwal wrote: > Re-introduce `Automatic-Module-Name` for empty jars until a better alternative to empty jars has been finalized. This pull request has now been integrated. Changeset: 7329279e Author: Abhinay Agarwal Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/7329279e504070355ba9aa0517f0279e7e72c2cf Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8273754: Re-introduce Automatic-Module-Name in empty jars Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/623 From hjohn at xs4all.nl Wed Sep 15 10:59:09 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 15 Sep 2021 12:59:09 +0200 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl> Message-ID: On 15/09/2021 02:28, Nir Lisker wrote: > Sorry, I'm not quite sure what you mean by this. Could you elaborate? > The methods orElse and orElseGet are present in the PoC, and I think > they're highly useful to have to deal with nulls. > > > The methods that you call orElse and orElseGet return an > ObservableValue. The Optional methods with the same names return the > wrapped value (of type T). For comparison, ReactFX has: > T getOrElse(T defaultValue) > T getOrSupply(Supplier defaultSupplier) > Val orElseConst(T other) > Val orElse(ObservableValue other) I see what you mean now. The methods from java.util.Optional will return an unwrapped value, while the ones from ObservableValue in the PoC return an ObservableValue, but they have the same name. So java.util.Optional offers: T orElse(T other) T orElseGet(Supplier supplier) And the PoC: ObservableValue orElse(T alternativeValue) ObservableValue orElseGet(Supplier supplier) The main difference is in the returned types. Personally, I think it is rarely useful for a binding to be queried directly and I've never used the #getOrElse or #getOrSupply variants that ReactFX offers. On top of that: x.orElse(5).getValue() === x.getOrElse(5) So it introduces another method in the interface to avoid having to write ".getValue()". The opposite, introducing only the "unwrapped" variants would still require the "wrapped" variants to be present as well. So, what I would suggest is to not add variants for #getOrElse and #getOrSupply at all as they are of questionable value and would just bloat the API for a bit less typing. In that case I think we can still use the signatures as they are. ReactFX also offers: Val orElse(ObservableValue other) This is another rarely used feature IMHO, and I think Optional#or would a better match for this functionality: Optional or(Supplier> supplier) In the POC the signature would be: ObservableValue or( Supplier> supplier ) I didn't implement this one in the PoC to keep it small, but I did implement this in my JavaFX EventStream library before. > So it deals with both getting the wrapped value in null cases and with > getting a "dynamic value" in null cases. I find the Optional-like method > 'T getOrElse(T defaultValue)' useful (along with others such as > ifPresent because Optional is just useful for dealing with wrapped > values). What I'm saying is that we should be careful with the names if > we include both "constant" and "dynamic" versions of 'orElse'-like methods. I think #ifPresent can be added, not so sure about the usefulness of #getOrElse (see above). > The null check in ReactFX's #computeValue is > actually checking the result of the mapping function, not whether the > function instance itself was null. > > I didn't mean the null-ness of the map argument. What I meant was that > there is this implementation, which is similar to what ReactFX does: Sorry, I see it now. You have a good point, the current implementation indeed wraps another Lambda to add the null check which could have been done in #computeValue. I think it would be a good move to avoid the extra lambda simply because the end result would be more readable -- any performance improvement would be a bonus, I don't know if there will be any. > As for my points 3 and 4, I'll have to try and play with the > implementation myself, which will be easier to do when there is some PR > in the works. Perhaps this is useful: https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx When you add this as a maven dependency to your project, you will get the new PoC functionality. It basically uses the Maven shade plugin to replace a few classes in javafx-base -- I use this sometimes to fix bugs I need fixed immediately by patching jfx, but found it also works very nicely to experiment with this PoC. Also, the PoC PR compiles fine, it may need rebasing. > To close "Bindings.select*(): add new type-safe template based API > instead of legacy-style set of methods" we'd need the flatMap/select > method to be included. > > Yes. I think that we can include flatMap in this iteration, perhaps as > a separate PR? That should be no problem, I can split it up. > I don't think we really need specialized methods for primitives (or at > least, not right away). At this point the primitive versions only > really differ in what value they'd return if the binding would be null > and perhaps they do a little less boxing/unboxing. Since you can select > the default value with #orElse which is more flexible. I don't see much > use to add those variants. > > I agree, I would avoid bloating the primitive specialization classes for > now, especially when Valhalla is planned to take care of those. Yes, I think we can easily do without for now. > The ticket is a bit unclear as I can't see what type "x" is. > > Yes, but I got the impression that either way it can be solved with map > (or flatMap). Agreed. --John From arapte at openjdk.java.net Wed Sep 15 11:19:50 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Sep 2021 11:19:50 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 23:43:29 GMT, Nir Lisker wrote: >> Added convenience factory factory methods for Background and Border. > > Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: > > - Removed whitespaces > - Added tests and doc updates Provided few minor comments, overall looks good to me. modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 357: > 355: > 356: /** > 357: * A convenience factory method for creating a background with a single {@code Paint}. Minor: typo: `background` -> `Background` Let's use the `Background` in all places where we refer the class name. Two other places which need similar change are in @param and @return A similar change is needed for Border.stroke method also: border -> Border modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundTest.java line 722: > 720: @Test > 721: public void testSingleFill() { > 722: var background1 = Background.fill(Color.BEIGE); I think we should have a test for null argument too. Similar for the test BorderTest.testSingleStroke() ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/610 From arapte at openjdk.java.net Wed Sep 15 11:19:51 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Sep 2021 11:19:51 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 11:03:20 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: >> >> - Removed whitespaces >> - Added tests and doc updates > > modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java line 357: > >> 355: >> 356: /** >> 357: * A convenience factory method for creating a background with a single {@code Paint}. > > Minor: typo: `background` -> `Background` > Let's use the `Background` in all places where we refer the class name. Two other places which need similar change are in @param and @return > > A similar change is needed for Border.stroke method also: border -> Border Another suggestion for the description, inspired from the constructors of this class: `A convenience factory method to create a new Background by supplying a single {@code Paint}.` I am good with the current statement too. Above one will just be uniform with existing doc. I leave it to your choice. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From kcr at openjdk.java.net Wed Sep 15 13:08:23 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 13:08:23 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 23:43:29 GMT, Nir Lisker wrote: >> Added convenience factory factory methods for Background and Border. > > Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: > > - Removed whitespaces > - Added tests and doc updates > Let's use the `Background` in all places where we refer the class name. As a clarifying point, if it is capitalized, indicating an object of that type, it should use `{@code ... }`. I don't think all uses of `background` need to be `{@code Background}` (although that would be OK), so another possibility is to just capitalize the first occurrence and leave the others as lower-case? ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From nlisker at openjdk.java.net Wed Sep 15 13:36:29 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 15 Sep 2021 13:36:29 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 11:08:04 GMT, Ambarish Rapte wrote: >> Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: >> >> - Removed whitespaces >> - Added tests and doc updates > > modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BackgroundTest.java line 722: > >> 720: @Test >> 721: public void testSingleFill() { >> 722: var background1 = Background.fill(Color.BEIGE); > > I think we should have a test for null argument too. > Similar for the test BorderTest.testSingleStroke() Yes, I wanted to add these but forgot. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From jvos at openjdk.java.net Wed Sep 15 15:12:59 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 15 Sep 2021 15:12:59 GMT Subject: [jfx17] RFR: 8273824: Update JavaFX release version to 17.0.0.1 in jfx/jfx17 branch Message-ID: <3cXyv557Ho_Ho2acWaseQKC5koxha5mdeu3Eu6hoRc8=.a2d82779-f690-4363-b274-da61358f4619@github.com> This release is needed with a backport of JDK-8273754 ------------- Commit messages: - Increase patch version to build 17.0.0.1 Changes: https://git.openjdk.java.net/jfx/pull/624/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=624&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273824 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/624.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/624/head:pull/624 PR: https://git.openjdk.java.net/jfx/pull/624 From kcr at openjdk.java.net Wed Sep 15 15:12:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 15:12:59 GMT Subject: [jfx17] RFR: 8273824: Update JavaFX release version to 17.0.0.1 in jfx/jfx17 branch In-Reply-To: <3cXyv557Ho_Ho2acWaseQKC5koxha5mdeu3Eu6hoRc8=.a2d82779-f690-4363-b274-da61358f4619@github.com> References: <3cXyv557Ho_Ho2acWaseQKC5koxha5mdeu3Eu6hoRc8=.a2d82779-f690-4363-b274-da61358f4619@github.com> Message-ID: On Wed, 15 Sep 2021 14:50:03 GMT, Johan Vos wrote: > This release is needed with a backport of JDK-8273754 Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/624 From kevin.rushforth at oracle.com Wed Sep 15 15:36:12 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 15 Sep 2021 08:36:12 -0700 Subject: JavaFX metal rendering pipeline for macOS Message-ID: <3cb4d3e7-5c2e-7916-3c91-327a58079282@oracle.com> We just pushed an early prototype of a new JavaFX Metal rendering pipeline for macOS to a new "metal" branch of jfx-sandbox. We called it "metal" with no bug ID or username prefix, to highlight that it is more than an experiment: It is intended to be the branch where we will develop the metal port. Future experimental work can be done in other branches and those would have a username prefix. We're not necessarily looking for contributions at this point, but if anyone has early feedback about the approach, or wants to "kick the tires" by building it themselves, that would be fine. Several things are hard-coded at the moment (such as a hack to force uploading painter since the needed glass changes haven't been done, and a hard coded background color), and by no means does everything work yet (e.g., no text, no decora shaders, no 3D), but basic primitive work. -- Kevin From jvos at openjdk.java.net Wed Sep 15 15:55:57 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 15 Sep 2021 15:55:57 GMT Subject: [jfx17] Integrated: 8273824: Update JavaFX release version to 17.0.0.1 in jfx/jfx17 branch In-Reply-To: <3cXyv557Ho_Ho2acWaseQKC5koxha5mdeu3Eu6hoRc8=.a2d82779-f690-4363-b274-da61358f4619@github.com> References: <3cXyv557Ho_Ho2acWaseQKC5koxha5mdeu3Eu6hoRc8=.a2d82779-f690-4363-b274-da61358f4619@github.com> Message-ID: <68Xs4zycBWbPfs-UjA92zmJbiSBzuD-K5yQZPQu1nQ8=.4fc58ca7-f6aa-4cae-9843-e2c85a9554f5@github.com> On Wed, 15 Sep 2021 14:50:03 GMT, Johan Vos wrote: > This release is needed with a backport of JDK-8273754 This pull request has now been integrated. Changeset: bd872404 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/bd87240425f5eb89b14c01dc71bc0342233c1140 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8273824: Update JavaFX release version to 17.0.0.1 in jfx/jfx17 branch Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/624 From arapte at openjdk.java.net Wed Sep 15 15:56:51 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Sep 2021 15:56:51 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: <2iUv8XIID7fMxC5u8zdKnn6LJ8-0fQkeyAzMva7SotY=.5f7a7266-13ab-4091-84ad-fcaeb842d08d@github.com> On Wed, 15 Sep 2021 13:04:52 GMT, Kevin Rushforth wrote: > another possibility is to just capitalize the first occurrence and leave the others as lower-case? That sounds good too, so only the first occurrence would be changed. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From jvos at openjdk.java.net Wed Sep 15 16:04:23 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 15 Sep 2021 16:04:23 GMT Subject: [jfx17] RFR: 8273754: Re-introduce Automatic-Module-Name in empty jars Message-ID: Reviewed-by: kcr, jvos ------------- Commit messages: - 8273754: Re-introduce Automatic-Module-Name in empty jars Changes: https://git.openjdk.java.net/jfx/pull/625/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=625&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273754 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/625.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/625/head:pull/625 PR: https://git.openjdk.java.net/jfx/pull/625 From jvos at openjdk.java.net Wed Sep 15 16:20:06 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 15 Sep 2021 16:20:06 GMT Subject: [jfx17] Integrated: 8273754: Re-introduce Automatic-Module-Name in empty jars In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 15:57:24 GMT, Johan Vos wrote: > Reviewed-by: kcr, jvos This pull request has now been integrated. Changeset: 3a677c41 Author: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/3a677c418b517a4868ae44bd66209aab83c29588 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8273754: Re-introduce Automatic-Module-Name in empty jars Backport-of: 7329279e504070355ba9aa0517f0279e7e72c2cf ------------- PR: https://git.openjdk.java.net/jfx/pull/625 From kcr at openjdk.java.net Wed Sep 15 17:19:02 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 17:19:02 GMT Subject: [jfx17u] RFR: 8268849: Update to 612.1 version of WebKit In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 19:53:47 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. For some reason, Skara didn't mark this as clean, so it needs a (sanity) review. @arapte Can you review? ------------- PR: https://git.openjdk.java.net/jfx17u/pull/3 From kcr at openjdk.java.net Wed Sep 15 19:03:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 19:03:07 GMT Subject: [jfx17u] RFR: 8273138: BidirectionalBinding fails to observe changes of invalid properties Message-ID: Clean backport to `jfx17u`. This has been tested along with other pending fixes in the `test-kcr-17.0.1` branch. ------------- Commit messages: - 8273138: BidirectionalBinding fails to observe changes of invalid properties Changes: https://git.openjdk.java.net/jfx17u/pull/5/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=5&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273138 Stats: 54 lines in 2 files changed: 54 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/5/head:pull/5 PR: https://git.openjdk.java.net/jfx17u/pull/5 From kcr at openjdk.java.net Wed Sep 15 19:04:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 19:04:34 GMT Subject: [jfx17u] RFR: 8268718: [macos] Video stops, but audio continues to play when stopTime is reached Message-ID: Clean backport to `jfx17u`. This has been tested along with other pending fixes in the `test-kcr-17.0.1` branch. ------------- Commit messages: - 8268718: [macos] Video stops, but audio continues to play when stopTime is reached Changes: https://git.openjdk.java.net/jfx17u/pull/4/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=4&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268718 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/4.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/4/head:pull/4 PR: https://git.openjdk.java.net/jfx17u/pull/4 From kcr at openjdk.java.net Wed Sep 15 19:04:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 19:04:37 GMT Subject: [jfx17u] RFR: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell Message-ID: Clean backport to `jfx17u`. This has been tested along with other pending fixes in the `test-kcr-17.0.1` branch. ------------- Commit messages: - 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell Changes: https://git.openjdk.java.net/jfx17u/pull/6/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=6&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273324 Stats: 53 lines in 2 files changed: 50 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx17u/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/6/head:pull/6 PR: https://git.openjdk.java.net/jfx17u/pull/6 From kcr at openjdk.java.net Wed Sep 15 20:53:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 20:53:49 GMT Subject: [jfx17u] Integrated: 8268718: [macos] Video stops, but audio continues to play when stopTime is reached In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 18:55:23 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested along with other pending fixes in the `test-kcr-17.0.1` branch. This pull request has now been integrated. Changeset: 3c6596b3 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/3c6596b31cde6c95a3ab1caa2657c0bb498523bf Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8268718: [macos] Video stops, but audio continues to play when stopTime is reached Backport-of: 0c98d9608611aa2378b38604e2528935c94e84ae ------------- PR: https://git.openjdk.java.net/jfx17u/pull/4 From kcr at openjdk.java.net Wed Sep 15 20:59:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 20:59:33 GMT Subject: [jfx17u] Integrated: 8273138: BidirectionalBinding fails to observe changes of invalid properties In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 18:56:07 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested along with other pending fixes in the `test-kcr-17.0.1` branch. This pull request has now been integrated. Changeset: ff4a6259 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/ff4a6259a877d2cac67b8833c7d297c887bd1fbc Stats: 54 lines in 2 files changed: 54 ins; 0 del; 0 mod 8273138: BidirectionalBinding fails to observe changes of invalid properties Backport-of: 26d6438ea267d703039facac7dab67175b863b46 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/5 From kcr at openjdk.java.net Wed Sep 15 20:59:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 20:59:49 GMT Subject: [jfx17u] Integrated: 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell In-Reply-To: References: Message-ID: <8Yf3V0nL8ZxUAKbtaLmdfNFvVMNYQS2_2jtQYEGEPrQ=.49728e47-1278-4368-ae8a-4421a5cbda5d@github.com> On Wed, 15 Sep 2021 18:56:37 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested along with other pending fixes in the `test-kcr-17.0.1` branch. This pull request has now been integrated. Changeset: 62355c90 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/62355c9011b21ea8db4c8e511bda3dd47f1fc84c Stats: 53 lines in 2 files changed: 50 ins; 0 del; 3 mod 8273324: IllegalArgumentException: fromIndex(0) > toIndex(-1) after clear and select TableCell Backport-of: a272c4f6bd08fee8928c78e17428574aec485cfd ------------- PR: https://git.openjdk.java.net/jfx17u/pull/6 From arapte at openjdk.java.net Wed Sep 15 21:02:49 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 15 Sep 2021 21:02:49 GMT Subject: [jfx17u] RFR: 8268849: Update to 612.1 version of WebKit In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 19:53:47 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. Marked as reviewed by arapte (Reviewer). If we compare modules/javafx.web/src/main/native/Source of this repo with that of mainline webkit update [revision](https://github.com/openjdk/jfx/commit/948df32448b71c4d6c10ccc4c125170dc68b0786). There are only differences of copyright year. jfx17 files have 2021 in copyright year. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/3 From kcr at openjdk.java.net Wed Sep 15 21:11:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 21:11:51 GMT Subject: [jfx17u] RFR: 8268849: Update to 612.1 version of WebKit In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 19:53:47 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. Thanks for the review and the sanity check. > There are only differences of copyright year. jfx17 files have 2021 in copyright year. Right. The copyright updates in the `jfx:master` branch were done subsequent to this. Once I have backported the remaining two webkit fixes, the HEAD of jfx17u:master and jfx:master should be identical for the native webkit sources. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/3 From kcr at openjdk.java.net Wed Sep 15 21:11:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 21:11:54 GMT Subject: [jfx17u] Integrated: 8268849: Update to 612.1 version of WebKit In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 19:53:47 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. This pull request has now been integrated. Changeset: 092c20b0 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/092c20b01988fd34251ca6f607768e109c273151 Stats: 286061 lines in 5711 files changed: 175196 ins; 68118 del; 42747 mod 8268849: Update to 612.1 version of WebKit Reviewed-by: arapte Backport-of: 948df32448b71c4d6c10ccc4c125170dc68b0786 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/3 From kcr at openjdk.java.net Wed Sep 15 21:30:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 21:30:43 GMT Subject: [jfx17u] RFR: 8270479: WebKit 612.1 build fails with Visual Studio 2017 Message-ID: Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. ------------- Commit messages: - 8270479: WebKit 612.1 build fails with Visual Studio 2017 Changes: https://git.openjdk.java.net/jfx17u/pull/7/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=7&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270479 Stats: 21 lines in 3 files changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/7.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/7/head:pull/7 PR: https://git.openjdk.java.net/jfx17u/pull/7 From kcr at openjdk.java.net Wed Sep 15 21:30:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 21:30:43 GMT Subject: [jfx17u] RFR: 8270479: WebKit 612.1 build fails with Visual Studio 2017 In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 21:22:49 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. NOTE: I verified that after this PR and PR #8 are applied, `modules/javafx.web/src/main/native` is identical to the mainline `jfx` repo. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/7 From kcr at openjdk.java.net Wed Sep 15 21:33:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 21:33:58 GMT Subject: [jfx17u] RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes Message-ID: <96wGaQJxwikhp01NJ3Zr4VXMGyT3bxVhkNQ9V0TXk58=.6ff62e1f-f808-4c29-8911-ed7d61df9542@github.com> Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. ------------- Commit messages: - 8272329: Cherry pick GTK WebKit 2.32.3 changes Changes: https://git.openjdk.java.net/jfx17u/pull/8/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=8&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272329 Stats: 341 lines in 61 files changed: 193 ins; 9 del; 139 mod Patch: https://git.openjdk.java.net/jfx17u/pull/8.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/8/head:pull/8 PR: https://git.openjdk.java.net/jfx17u/pull/8 From kcr at openjdk.java.net Wed Sep 15 21:33:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 21:33:58 GMT Subject: [jfx17u] RFR: 8272329: Cherry pick GTK WebKit 2.32.3 changes In-Reply-To: <96wGaQJxwikhp01NJ3Zr4VXMGyT3bxVhkNQ9V0TXk58=.6ff62e1f-f808-4c29-8911-ed7d61df9542@github.com> References: <96wGaQJxwikhp01NJ3Zr4VXMGyT3bxVhkNQ9V0TXk58=.6ff62e1f-f808-4c29-8911-ed7d61df9542@github.com> Message-ID: On Wed, 15 Sep 2021 21:23:17 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. NOTE: I verified that after this PR and PR #7 are applied, `modules/javafx.web/src/main/native` is identical to the mainline `jfx` repo. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/8 From kcr at openjdk.java.net Wed Sep 15 21:45:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 21:45:51 GMT Subject: [jfx17u] Integrated: 8270479: WebKit 612.1 build fails with Visual Studio 2017 In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 21:22:49 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. This pull request has now been integrated. Changeset: 5397290f Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/5397290ff5bfa0f5f650d09269eabab7c3ae04d8 Stats: 21 lines in 3 files changed: 21 ins; 0 del; 0 mod 8270479: WebKit 612.1 build fails with Visual Studio 2017 Backport-of: 8aaacb5bd5368d544c4c468f85ce9ed4dbf26d07 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/7 From kcr at openjdk.java.net Wed Sep 15 22:18:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 22:18:07 GMT Subject: [jfx17u] RFR: 8273732: Clarify review policies for clean backports in JavaFX update releases Message-ID: Added a paragraph indicating that a review of a clean backport to an update release is optional, if the bug in question has been approved for inclusion into the release. ------------- Commit messages: - 8273732: Clarify review policies for clean backports in JavaFX update releases Changes: https://git.openjdk.java.net/jfx17u/pull/9/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=9&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273732 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/9/head:pull/9 PR: https://git.openjdk.java.net/jfx17u/pull/9 From kcr at openjdk.java.net Wed Sep 15 22:22:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 22:22:00 GMT Subject: [jfx17u] Integrated: 8272329: Cherry pick GTK WebKit 2.32.3 changes In-Reply-To: <96wGaQJxwikhp01NJ3Zr4VXMGyT3bxVhkNQ9V0TXk58=.6ff62e1f-f808-4c29-8911-ed7d61df9542@github.com> References: <96wGaQJxwikhp01NJ3Zr4VXMGyT3bxVhkNQ9V0TXk58=.6ff62e1f-f808-4c29-8911-ed7d61df9542@github.com> Message-ID: On Wed, 15 Sep 2021 21:23:17 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This has been tested on all platforms along with other pending fixes in the `test-kcr-17.0.1` branch. This pull request has now been integrated. Changeset: 2947986a Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/2947986a17f8c123b3d4946677bde59d82440c9d Stats: 341 lines in 61 files changed: 193 ins; 9 del; 139 mod 8272329: Cherry pick GTK WebKit 2.32.3 changes Backport-of: ee442e516a20e979dc228ab63c6b795b74d49e41 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/8 From kcr at openjdk.java.net Wed Sep 15 23:06:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Sep 2021 23:06:39 GMT Subject: [jfx17u] RFR: 8273732: Clarify review policies for clean backports in JavaFX update releases [v2] In-Reply-To: References: Message-ID: <8H7mofWCscogIQida2AkjbDl-rjvTv1Hd5--q2ghjU4=.478a87b0-2b27-4c59-9f42-b29972258702@github.com> > Added a paragraph indicating that a review of a clean backport to an update release is optional, if the bug in question has been approved for inclusion into the release. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Minor wording update ------------- Changes: - all: https://git.openjdk.java.net/jfx17u/pull/9/files - new: https://git.openjdk.java.net/jfx17u/pull/9/files/8bc1bc69..af930d70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=9&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=9&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/9/head:pull/9 PR: https://git.openjdk.java.net/jfx17u/pull/9 From prr at openjdk.java.net Wed Sep 15 23:18:47 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 15 Sep 2021 23:18:47 GMT Subject: [jfx17u] RFR: 8273732: Clarify review policies for clean backports in JavaFX update releases [v2] In-Reply-To: <8H7mofWCscogIQida2AkjbDl-rjvTv1Hd5--q2ghjU4=.478a87b0-2b27-4c59-9f42-b29972258702@github.com> References: <8H7mofWCscogIQida2AkjbDl-rjvTv1Hd5--q2ghjU4=.478a87b0-2b27-4c59-9f42-b29972258702@github.com> Message-ID: On Wed, 15 Sep 2021 23:06:39 GMT, Kevin Rushforth wrote: >> Added a paragraph indicating that a review of a clean backport to an update release is optional, if the bug in question has been approved for inclusion into the release. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor wording update Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/9 From pbansal at openjdk.java.net Thu Sep 16 05:40:46 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 16 Sep 2021 05:40:46 GMT Subject: [jfx17u] RFR: 8273732: Clarify review policies for clean backports in JavaFX update releases [v2] In-Reply-To: <8H7mofWCscogIQida2AkjbDl-rjvTv1Hd5--q2ghjU4=.478a87b0-2b27-4c59-9f42-b29972258702@github.com> References: <8H7mofWCscogIQida2AkjbDl-rjvTv1Hd5--q2ghjU4=.478a87b0-2b27-4c59-9f42-b29972258702@github.com> Message-ID: <_idZS5P1-qww1Bw23J22R_Rqz43TPOpruOQbzpAKSro=.f23aed51-63c2-4f6a-bcd6-a3c99a239c4f@github.com> On Wed, 15 Sep 2021 23:06:39 GMT, Kevin Rushforth wrote: >> Added a paragraph indicating that a review of a clean backport to an update release is optional, if the bug in question has been approved for inclusion into the release. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor wording update Marked as reviewed by pbansal (Committer). ------------- PR: https://git.openjdk.java.net/jfx17u/pull/9 From mhanl at openjdk.java.net Thu Sep 16 08:39:55 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 16 Sep 2021 08:39:55 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 23:43:29 GMT, Nir Lisker wrote: >> Added convenience factory factory methods for Background and Border. > > Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: > > - Removed whitespaces > - Added tests and doc updates One comment from my side: I would find it quite useful if we have another border factory method with a double as the second parameter which let us specify the border width. So e.g. public static Border stroke(Paint stroke, double width) { return new Border(new BorderStroke(stroke, BorderStrokeStyle.SOLID, null, new BorderWidths(width))); } But I really want to hear other opinions. This can also be a follow up. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From jvos at openjdk.java.net Thu Sep 16 09:11:58 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 16 Sep 2021 09:11:58 GMT Subject: [jfx17u] RFR: 8273732: Clarify review policies for clean backports in JavaFX update releases [v2] In-Reply-To: <8H7mofWCscogIQida2AkjbDl-rjvTv1Hd5--q2ghjU4=.478a87b0-2b27-4c59-9f42-b29972258702@github.com> References: <8H7mofWCscogIQida2AkjbDl-rjvTv1Hd5--q2ghjU4=.478a87b0-2b27-4c59-9f42-b29972258702@github.com> Message-ID: On Wed, 15 Sep 2021 23:06:39 GMT, Kevin Rushforth wrote: >> Added a paragraph indicating that a review of a clean backport to an update release is optional, if the bug in question has been approved for inclusion into the release. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Minor wording update This clarifies it indeed. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx17u/pull/9 From kcr at openjdk.java.net Thu Sep 16 12:03:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Sep 2021 12:03:52 GMT Subject: [jfx17u] Integrated: 8273732: Clarify review policies for clean backports in JavaFX update releases In-Reply-To: References: Message-ID: On Wed, 15 Sep 2021 22:05:26 GMT, Kevin Rushforth wrote: > Added a paragraph indicating that a review of a clean backport to an update release is optional, if the bug in question has been approved for inclusion into the release. This pull request has now been integrated. Changeset: 549bfef9 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/549bfef95e4c2e690eb83523a3bf5a8344c072f6 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8273732: Clarify review policies for clean backports in JavaFX update releases Reviewed-by: prr, pbansal, jvos ------------- PR: https://git.openjdk.java.net/jfx17u/pull/9 From kcr at openjdk.java.net Thu Sep 16 12:35:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Sep 2021 12:35:06 GMT Subject: [jfx11u] Integrated: 8273732: Clarify review policies for clean backports in JavaFX update releases Message-ID: <3CTVTBXLvJBSpeFjnz6oO5lWwKH4fQNzVyljjaPmXHs=.bbbd09f8-0477-4431-9849-7d5bf57169e6@github.com> Clean backport of update to `CONTRIBUTING.md` to clarify that clean backports of approved fixes can be integrated without further review. ------------- Commit messages: - 8273732: Clarify review policies for clean backports in JavaFX update releases Changes: https://git.openjdk.java.net/jfx11u/pull/53/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=53&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273732 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/53/head:pull/53 PR: https://git.openjdk.java.net/jfx11u/pull/53 From kcr at openjdk.java.net Thu Sep 16 12:35:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Sep 2021 12:35:06 GMT Subject: [jfx11u] Integrated: 8273732: Clarify review policies for clean backports in JavaFX update releases In-Reply-To: <3CTVTBXLvJBSpeFjnz6oO5lWwKH4fQNzVyljjaPmXHs=.bbbd09f8-0477-4431-9849-7d5bf57169e6@github.com> References: <3CTVTBXLvJBSpeFjnz6oO5lWwKH4fQNzVyljjaPmXHs=.bbbd09f8-0477-4431-9849-7d5bf57169e6@github.com> Message-ID: <8Tq9zcyLdAUt497dXus4ORKulTEKio1GPUt8d-WReJM=.1c9714f9-027d-4e82-b817-a96aba1035d1@github.com> On Thu, 16 Sep 2021 12:27:00 GMT, Kevin Rushforth wrote: > Clean backport of update to `CONTRIBUTING.md` to clarify that clean backports of approved fixes can be integrated without further review. This pull request has now been integrated. Changeset: 896089eb Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/896089ebe7764d0b9503c394b5d4ed2a639e9b4a Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8273732: Clarify review policies for clean backports in JavaFX update releases Backport-of: 549bfef95e4c2e690eb83523a3bf5a8344c072f6 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/53 From fkirmaier at openjdk.java.net Thu Sep 16 13:22:32 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 16 Sep 2021 13:22:32 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v4] In-Reply-To: References: Message-ID: <_qrnVf27DezSXoUj2DOc3PxhzNXFyJyspVlI0L2qEqw=.82287feb-4c82-4ee2-aaf7-e0fecd356e7f@github.com> > When using Swing it's possible to generate a Deadlock. > It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. > Sample Programm and Threaddump are added to the ticket. > > Removing the nested loop fixes the Problem. > I hope this doesn't have any side effect - so far i don't know of any. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8273485 small cleanup of the changes. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/622/files - new: https://git.openjdk.java.net/jfx/pull/622/files/417ac2fe..8bee7a41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/622.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/622/head:pull/622 PR: https://git.openjdk.java.net/jfx/pull/622 From github.com+85555697+andreas-heger at openjdk.java.net Thu Sep 16 15:34:16 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Thu, 16 Sep 2021 15:34:16 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v3] In-Reply-To: References: Message-ID: > The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url) Andreas Heger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into fix-8255015 - Merge branch 'openjdk:master' into fix-8255015 - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/531/files - new: https://git.openjdk.java.net/jfx/pull/531/files/3973a2e2..fdb1ddbe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=01-02 Stats: 5975 lines in 27 files changed: 5975 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531 PR: https://git.openjdk.java.net/jfx/pull/531 From kcr at openjdk.java.net Thu Sep 16 17:19:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Sep 2021 17:19:00 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v9] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 18:15:21 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Fix test to pass all 3 platforms > Somehow by accident I've found out that doing in `WebPage::paint2GC`: > > ``` > + gc.clearRect(0, 0, 0, 0); // extra call to clear rect > ``` > > fixes the issue for the Group test (same for no container case). Interesting. > After some testing, I modified this method to get it working with the expected single call with just this change: > > ``` > - // set the blend mode to CLEAR > - context.updateCompositeMode(CompositeMode.CLEAR); > Paint oldPaint = getPaint(); > setPaint(Color.BLACK); // any color will do... > fillQuad(x1, y1, x2, y2); > + // set the blend mode to CLEAR > + context.updateCompositeMode(CompositeMode.CLEAR); > context.flushVertexBuffer(); > ``` > > which seems to indicate that `fillQuad` requires SRC_OVER and we can use the original black color, and only before flushing we set the CLEAR mode. Even more interesting. > Does this make sense? No, it doesn't make sense, since setting the mode to CLEAR before drawing the quad is the right order. The fact that it matters indicates that something very odd is happening with state management. Your experiment was the clue that allowed me to figure out the problem. The problem is that the call to `context.updateCompositeMode` is simply the wrong thing to do. The right call, which is what the D3D pipeline is doing, is `setCompositeMode`. The former does not update the state so any other method that validates the state will use the wrong composite mode. It's amazing to me that this went undetected for this long, and that it hasn't caused other problems. Here is the proposed change: CompositeMode mode = getCompositeMode(); // set the blend mode to CLEAR - context.updateCompositeMode(CompositeMode.CLEAR); + setCompositeMode(CompositeMode.CLEAR); Paint oldPaint = getPaint(); setPaint(Color.BLACK); // any color will do... fillQuad(x1, y1, x2, y2); context.flushVertexBuffer(); setPaint(oldPaint); // restore default blend mode - context.updateCompositeMode(mode); + setCompositeMode(mode); This will need to be well tested on Linux and Mac (a full set of Robot tests). ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Thu Sep 16 20:22:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Sep 2021 20:22:34 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v9] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 18:15:21 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Fix test to pass all 3 platforms I verified that the above change works, and doesn't cause any regressions that I can see. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Thu Sep 16 20:49:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Sep 2021 20:49:52 GMT Subject: RFR: 8172095: Let Node.managed become CSS-styleable [v2] In-Reply-To: References: Message-ID: On Sat, 4 Sep 2021 15:44:17 GMT, Abhinay Agarwal wrote: >> 8172095: Let Node.managed become CSS-styleable > > Abhinay Agarwal has updated the pull request incrementally with two additional commits since the last revision: > > - Add default value tests for setting / getting the managed property > - Replace with HTML equivalent code Looks good. This is ready to be integrated once the CSR is approved. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/602 From nlisker at openjdk.java.net Thu Sep 16 20:53:48 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 16 Sep 2021 20:53:48 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 08:36:49 GMT, Marius Hanl wrote: > One comment from my side: I would find it quite useful if we have another border factory method with a double as the second parameter which let us specify the border width. So e.g. > > ``` > public static Border stroke(Paint stroke, double width) { > return new Border(new BorderStroke(stroke, BorderStrokeStyle.SOLID, null, new BorderWidths(width))); > } > ``` > > But I really want to hear other opinions. This can also be a follow up. :) I don't mind adding this variant, but it needs consensus. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From kcr at openjdk.java.net Thu Sep 16 21:18:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Sep 2021 21:18:47 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 23:43:29 GMT, Nir Lisker wrote: >> Added convenience factory factory methods for Background and Border. > > Nir Lisker has updated the pull request incrementally with two additional commits since the last revision: > > - Removed whitespaces > - Added tests and doc updates > > ``` > > public static Border stroke(Paint stroke, double width) { > > ``` > > ... > > But I really want to hear other opinions. This can also be a follow up. :) > > I don't mind adding this variant, but it needs consensus. I agree that it needs consensus, so the question is how many apps would use it from code (as opposed to CSS), and be satisfied with the other defaults. I don't object to adding a 2nd variant that takes a stroke width as long as we stop there. I don't want variants that take style, or corner radii, or insets, etc. (at that point, just use the existing API). ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From nlisker at openjdk.java.net Thu Sep 16 21:35:53 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 16 Sep 2021 21:35:53 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: <5FHhErUWy0GF-jZHED4HHt1KEQVf23roR-7lUatA4Cc=.3592fe76-5a94-4782-b371-1e68d6b3b258@github.com> On Thu, 16 Sep 2021 21:15:20 GMT, Kevin Rushforth wrote: > I agree that it needs consensus, so the question is how many apps would use it from code (as opposed to CSS), and be satisfied with the other defaults. I don't object to adding a 2nd variant that takes a stroke width as long as we stop there. I don't want variants that take style, or corner radii, or insets, etc. (at that point, just use the existing API). My thoughts as well, though if people care about all sorts of combinations, a builder pattern would be the way in my opinion. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From jpereda at openjdk.java.net Thu Sep 16 21:55:55 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 16 Sep 2021 21:55:55 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v9] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 18:15:21 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Fix test to pass all 3 platforms Great finding, thanks for clarifying it. I've tested it successfully too. I'll commit it then. ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Thu Sep 16 22:09:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Sep 2021 22:09:57 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v4] In-Reply-To: <9sJVqEm2IPygp3TVG-Nx3xdnqCd4VkDSrJHTwaM2FPM=.fe4a6fa6-5bae-449a-ad04-a17ccb14ae8f@github.com> References: <9sJVqEm2IPygp3TVG-Nx3xdnqCd4VkDSrJHTwaM2FPM=.fe4a6fa6-5bae-449a-ad04-a17ccb14ae8f@github.com> Message-ID: On Fri, 20 Aug 2021 22:22:51 GMT, Thiago Milczarek Sayao wrote: >> It seems raw images need to be converted BRGA -> RGBA. >> >> It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. >> >> I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. >> >> Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. >> >> To test: >> >> `./gradlew apps` >> >> >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor >> >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Review requests. This fix introduces a memory leak, but otherwise looks correct. I verified that with gtk3 the new manual test passes with the fix and fails without the fix (with gtk2 is passes before and after the fix). modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp line 916: > 914: > 915: if (is_raw_image) { > 916: data = (guchar*) convert_BGRA_to_RGBA((const int*) data, w * 4, h); This will leak memory, since the original buffer allocated by the call to `g_try_malloc0` on line 911 is never freed. I recommend something like this: guchar* origdata = data; data = (guchar*) convert_BGRA_to_RGBA((const int*) origdata, w * 4, h); g_free(origdata); ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From jpereda at openjdk.java.net Thu Sep 16 22:25:27 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 16 Sep 2021 22:25:27 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v10] In-Reply-To: References: Message-ID: > Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. > > In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. > > The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. > > Unit tests and a system test are provided. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Use correct call to set composite mode when clearing quads and restore color ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/563/files - new: https://git.openjdk.java.net/jfx/pull/563/files/40302d8c..b5088556 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=563&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/563.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/563/head:pull/563 PR: https://git.openjdk.java.net/jfx/pull/563 From dlemmermann at gmail.com Fri Sep 17 10:23:17 2021 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Fri, 17 Sep 2021 12:23:17 +0200 Subject: RFE: Style class for prompt text in text input controls Message-ID: <250ADAAD-831C-47F9-84EF-D9EE3A8E9DD9@gmail.com> I noticed that the ?Text? node used to display the prompt text of a text input control could definitely use its own style class. At least if you want to use a different font for it than for the normal text. Currently the prompt text node is bound to the same font property of the control as the regular ?Text? nodes. I had a customer request today to style them differently in a TextArea: the prompt text with a light font, the regular text with a bold font. The only way to implement this was to listen to the text property of the TextArea and add / remove the class ?blank? to it. Then I could use this class in the CSS file. Dirk From hjohn at xs4all.nl Fri Sep 17 10:33:41 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 17 Sep 2021 12:33:41 +0200 Subject: Running nested JUnit tests Message-ID: <2d7a18fd-0e92-dd78-66ef-fbd9e0026f68@xs4all.nl> I would like to provide some junit tests in a PR. These are written in a nested style for easy readability. For example: private StringProperty property = new SimpleStringProperty("A"); @Nested class When_map_Called { @Nested class WithNull { @Test void shouldThrowNullPointerException() { assertThrows(NullPointerException.class, () -> property.map(null)); } } @Nested class WithNotNullReturns_ObservableValue_Which { private ObservableValue observableValue = property.map(v -> v + "Z"); @Test void shouldNotBeNull() { assertNotNull(observableValue); } // etc... } // etc.. } Can this PR either: 1) Add JUnit 5 as a dependency 2) Use a custom JUnit 4 runner as a dependency that provides nested functionality 3) Add our own Nested runner based on an Apache 2.0 licensed one (about 200 lines of test code). For point 2 and 3, there is a good one here: https://github.com/NitorCreations/CoreComponents/tree/master/junit-runners) Please let me know, I think tests are very important and having to tools to write them as readable as possible would be great. --John From kcr at openjdk.java.net Fri Sep 17 11:24:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Sep 2021 11:24:41 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao wrote: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. I just tested this on my Ubuntu 20.04 VM and the problem still reproduces for me with or without this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From kcr at openjdk.java.net Fri Sep 17 12:26:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Sep 2021 12:26:55 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v10] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 22:25:27 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Use correct call to set composite mode when clearing quads and restore color Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Fri Sep 17 12:47:48 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Sep 2021 12:47:48 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v4] In-Reply-To: <_qrnVf27DezSXoUj2DOc3PxhzNXFyJyspVlI0L2qEqw=.82287feb-4c82-4ee2-aaf7-e0fecd356e7f@github.com> References: <_qrnVf27DezSXoUj2DOc3PxhzNXFyJyspVlI0L2qEqw=.82287feb-4c82-4ee2-aaf7-e0fecd356e7f@github.com> Message-ID: On Thu, 16 Sep 2021 13:22:32 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273485 > small cleanup of the changes. > I've adapted the solution to entirely remove the nested event loop, for the fullscreen. So far everything seems to work. > I've tested it with a simple application to check how the fullscreen behaves. > The logic seems to be added before the beginning of the VCS / 2013 > Is there away to look into the history before 2013? Maybe there is a hint, why this was added. I tracked down the bug fix that added the nested event loop (looking at the history of the closed-source changes, since this fix was done prior to open-sourcing glass). It was added to fix [JDK-8126842](https://bugs.openjdk.java.net/browse/JDK-8126842). As I suspected, the nested even loop is still necessary. If you run the test program attached to JDK-8126842 with your patch applied, make the window full-screen using the green button, then click the close button, the program will terminate with an exception. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/622 From kcr at openjdk.java.net Fri Sep 17 12:54:53 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Sep 2021 12:54:53 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v4] In-Reply-To: <_qrnVf27DezSXoUj2DOc3PxhzNXFyJyspVlI0L2qEqw=.82287feb-4c82-4ee2-aaf7-e0fecd356e7f@github.com> References: <_qrnVf27DezSXoUj2DOc3PxhzNXFyJyspVlI0L2qEqw=.82287feb-4c82-4ee2-aaf7-e0fecd356e7f@github.com> Message-ID: On Thu, 16 Sep 2021 13:22:32 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273485 > small cleanup of the changes. You can also see the exception with _any_ JavaFX program: enter full-screen with the green button, move the mouse to the upper-left corner to reveal the window decorations, and press the red button to exit the program. I think you need to look for a different solution to your deadlock, one that preserves the existing nested event loop. ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From tsayao at openjdk.java.net Fri Sep 17 13:00:20 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 17 Sep 2021 13:00:20 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v5] In-Reply-To: References: Message-ID: > It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Fix leak ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/599/files - new: https://git.openjdk.java.net/jfx/pull/599/files/29c6148e..ccbe4708 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=599&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=599&range=03-04 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599 From tsayao at openjdk.java.net Fri Sep 17 13:00:24 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 17 Sep 2021 13:00:24 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v4] In-Reply-To: References: <9sJVqEm2IPygp3TVG-Nx3xdnqCd4VkDSrJHTwaM2FPM=.fe4a6fa6-5bae-449a-ad04-a17ccb14ae8f@github.com> Message-ID: On Thu, 16 Sep 2021 21:57:08 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Review requests. > > modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp line 916: > >> 914: >> 915: if (is_raw_image) { >> 916: data = (guchar*) convert_BGRA_to_RGBA((const int*) data, w * 4, h); > > This will leak memory, since the original buffer allocated by the call to `g_try_malloc0` on line 911 is never freed. I recommend something like this: > > > guchar* origdata = data; > data = (guchar*) convert_BGRA_to_RGBA((const int*) origdata, w * 4, h); > g_free(origdata); Fixed. I really felt something was missing :) ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From kcr at openjdk.java.net Fri Sep 17 13:43:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Sep 2021 13:43:44 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v5] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 13:00:20 GMT, Thiago Milczarek Sayao wrote: >> It seems raw images need to be converted BRGA -> RGBA. >> >> It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. >> >> I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. >> >> Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. >> >> To test: >> >> `./gradlew apps` >> >> >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor >> >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > - Fix leak Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From kcr at openjdk.java.net Fri Sep 17 13:43:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Sep 2021 13:43:44 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v3] In-Reply-To: References: Message-ID: On Tue, 17 Aug 2021 13:12:41 GMT, Pankaj Bansal wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Change test to manual > > The fix works fine and the test passes on all platforms. I have given minor comments about the test. @pankaj-bansal can you re-review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From pbansal at openjdk.java.net Fri Sep 17 14:15:48 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Fri, 17 Sep 2021 14:15:48 GMT Subject: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v5] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 13:00:20 GMT, Thiago Milczarek Sayao wrote: >> It seems raw images need to be converted BRGA -> RGBA. >> >> It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. >> >> I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. >> >> Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. >> >> To test: >> >> `./gradlew apps` >> >> >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor >> >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > - Fix leak Looks good to me. I re-tested the test with both gtk2 and gtk3 and it the issue is fixed. ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/599 From tsayao at openjdk.java.net Fri Sep 17 15:05:49 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Fri, 17 Sep 2021 15:05:49 GMT Subject: Integrated: 8271398: GTK3 drag view image swaps red and blue color channels In-Reply-To: References: Message-ID: <9ekV1ab-We466t4S2s90pZax4mSBvHaow8nn0G8qoqk=.3b6cd7ce-9efb-49dc-a075-710ef8e0f5a3@github.com> On Fri, 6 Aug 2021 02:18:38 GMT, Thiago Milczarek Sayao wrote: > It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor This pull request has now been integrated. Changeset: b2ecfacf Author: Thiago Milczarek Sayao Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/b2ecfacf0d8c9512d0b4cc13c1ac6c104a20f396 Stats: 112 lines in 2 files changed: 93 ins; 18 del; 1 mod 8271398: GTK3 drag view image swaps red and blue color channels Reviewed-by: pbansal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/599 From kevin.rushforth at oracle.com Fri Sep 17 16:55:52 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 17 Sep 2021 09:55:52 -0700 Subject: Gtk4 and Wayland In-Reply-To: References: <4b837870-9178-bb16-becc-044dea5a14ec@oracle.com> Message-ID: <505e0e46-2452-9773-518c-91da158dddcc@oracle.com> I don't want to give up on the functionality of being able to move a window or control the stacking order for those platforms that can support it. So when running on an X11 server, which a gtk4 pipeline ought to be able to do, I think we need to continue to allow applications to move windows or change the stacking order. On a pure Wayland server, this might not be possible. One thing I will note is that the setting of a window's position (or size or stacking order) isn't just under the control of the application. The window system can move windows around (e.g., in response to a user dragging the window or as an operation of a tiled window manager), or it can override or ignore the attempt to set the position. This isn't described very well in the spec, so I will file a bug to clarify the spec to match this intention. On a related topic, the window decoration has moved into the client code, so we may need to give some thought to that as well in order to implement decorated windows on Wayland. -- Kevin On 9/14/2021 8:18 AM, Thiago Milczarek Say?o wrote: > Hi, > > It seems it would be very hard to have gtk4 and/or Wayland on JavaFX, > unless we stop doing window manager related things. > Resizing the window would be possible, but not stacking or moving it around. > > Wayland simply does not have this functionality and gtk4 removed it as > well, as pointed out here > > https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html#adapt-to-gdkwindow-api-changes > > and here: > > https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/4 > > Even on gtk3 it's a hard thing to do (deal with stacking and positioning). > > So I agree with the Gtk developers position to simply not deal with window > management at this level, but it's somehow unfortunate. > > On the "experimenting with gtk4" side, it seems like I hit a dead end > because gtk4 does not provide the needed functionality nor Wayland (to deal > with it directly). > > Sticking with X11 also seems like not optimal for the long term, it will be > replaced eventually. > > Maybe JavaFX should move away from window management as well? > > -- Thiago. > > > > Em qua., 1 de set. de 2021 ?s 08:42, Kevin Rushforth < > kevin.rushforth at oracle.com> escreveu: > >> This seems reasonable to me as well, at least for JavaFX since we >> already rely on Gtk for most of the windowing toolkit on Linux. >> >> -- Kevin >> >> On 9/1/2021 4:26 AM, Mario Torre wrote: >>> On Wed, Sep 1, 2021 at 1:18 PM Johan Vos wrote: >>>> Hi Thiago, >>>> >>>> I was thinking (and experimenting) in the same direction, and so far >> that >>>> is working good. I don't see disadvantages, but it would be good to find >>>> out about it before we move forward. >>>> Maybe the main issue to me is that GTK comes with lots of dependencies. >> We >>>> already have that situation today, so it is not going to be worse. But >> if >>>> we would use the Wayland protocol on a lower level (with a >> Wayland-specific >>>> glass platform, instead of GTK), we could probably reduce the >> dependencies. >>>> However, this comes at the price of creating *and maintaining* more >>>> low-level code. >>>> >>>> I've been running GTK3 on Wayland and that works fine too. However, it >>>> might be better to focus Wayland support for GTK4. I think there won't >> be >>>> many installs that have no X11, but only Wayland, and that have GTK3 >> and no >>>> GTK4. >>> I tend to agree with you, I think we should consider this for Wakefield >> too. >>> Cheers, >>> Mario >>> >>>> - Johan >>>> - Johan >>>> >>>> On Tue, Aug 31, 2021 at 11:03 PM Thiago Milczarek Say?o < >>>> thiago.sayao at gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I did some investigation on gtk4 and wayland. >>>>> >>>>> After some research I ended up with the conclusion that the best way >> is to >>>>> do a separate gtk4 backend, that would support X11 and Wayland. >>>>> >>>>> This would be a good start: >>>>> https://github.com/openjdk/jfx/pull/77/files >>>>> >>>>> Why? >>>>> >>>>> Gtk4 moves the decoration to the client side, which is GREAT since >> knowing >>>>> the window size with decoration was a real pain. >>>>> >>>>> We probably won't want to do all the decoration work, Gtk does that, >> but on >>>>> GtkWindow level, not GdkSurface (which replaces GdkWindow). >>>>> >>>>> Thus the move to use "more Gtk" (hence "less Gdk") which is exactly >> what >>>>> the PR does. It also removes Applet code >>>>> >>>>> This is also a good starting point: >>>>> https://gnome.pages.gitlab.gnome.org/gtk/gtk4/migrating-3to4.html >>>>> >>>>> --Thiago. >>>>> >> From kcr at openjdk.java.net Fri Sep 17 23:28:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Sep 2021 23:28:03 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Include WebKit shared library for Windows > > Enable reproducible builds of the native WebKit shared library for > Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. > - Include media shared libraries for Windows > > Enable reproducible builds of the native media shared libraries for > Windows when SOURCE_DATE_EPOCH is defined. The libraries are: > > fxplugins.dll > glib-lite.dll > gstreamer-lite.dll > jfxmedia.dll > - Enable reproducible builds with SOURCE_DATE_EPOCH > - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH I did a set of full builds on all three platforms today, and can verify that the builds are reproducible, when run on the same system and build dir, for all artifacts except the jmods, which you point out as a known issue. There is one caveat related to time zones listed below. All but two of the changes only affect reproducible builds, meaning that they only take effect when `SOURCE_DATE_EPOCH` is set. The following two changes affect all builds unconditionally, even when not using SOURCE_DATE_EPOCH: * removal of the (obsolete) jar indexing for javafx-swt.jar * sorting the list of files to be linked I think it's OK to not qualify the above with a check for `SOURCE_DATE_EPOCH`. When `SOURCE_DATE_EPOCH` is set, I see the following problems: * The timestamps for all files in the zip archives are set to a hard-coded "1980-02-01", rather than the date and time specified by `SOURCE_DATE_EPOCH`. This is both annoying, and a potential for bugs (e.g., a program looking at the time stamps of the various files in the archive could get confused). If no good solution can be found now, I want to see a follow-up bug for this. I would be reluctant to recommend the use of SOURCE_DATE_EPOCH until this can be fixed. * The conversion of `SOURCE_DATE_EPOCH` into `buildTimeStamp` depends on the time zone of the build machine. This means that you won't be able to compare two builds using the same time stamp on two different builds machines with different time zones. One solution would be to do the conversion such that the buildTimeStamp was always shown in UTC. This can be done as a follow-up issue, if you like. I'm doing a CI build and will verify the results (and probably do a bit more testing) when I get a chance, but I wanted to pass on this feedback today. build.gradle line 559: > 557: buildDate = new java.util.Date(ms) > 558: } > 559: def buildTimestamp = new java.text.SimpleDateFormat("yyyy-MM-dd-HHmmss").format(buildDate) I think it would be useful to format `buildDate` using UTC as the time zone when `SOURCE_DATE_EPOCH` is set. build.gradle line 3518: > 3516: def lFlags = webkitProperties.linkFlags?.join(' ') ?: '' > 3517: cmakeArgs = "$cmakeArgs -DCMAKE_C_FLAGS='${cFlags}' -DCMAKE_CXX_FLAGS='${cFlags}'" > 3518: cmakeArgs = "$cmakeArgs -DCMAKE_SHARED_LINKER_FLAGS='${lFlags}'" I presume you've tested this both with and without `SOURCE_DATE_EPOCH`? build.gradle line 3914: > 3912: tasks.withType(AbstractArchiveTask) { > 3913: if (sourceDateEpoch != null) { > 3914: preserveFileTimestamps = false This is a problem given how gradle generates a zip archive when this is set. How hard would it be to force all time stamps to be `SOURCE_DATE_EPOCH`? build.gradle line 4238: > 4236: def sdkTask = task("sdk$t.capital") { > 4237: group = "Basic" > 4238: dependsOn(javafxSwtTask) As mentioned in the general comments, this change affects builds even when not using `SOURCE_DATE_EPOCH`. I think this is fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From github.com+3197675+abhinayagarwal at openjdk.java.net Sat Sep 18 12:51:59 2021 From: github.com+3197675+abhinayagarwal at openjdk.java.net (Abhinay Agarwal) Date: Sat, 18 Sep 2021 12:51:59 GMT Subject: Integrated: 8172095: Let Node.managed become CSS-styleable In-Reply-To: References: Message-ID: On Thu, 12 Aug 2021 17:09:46 GMT, Abhinay Agarwal wrote: > 8172095: Let Node.managed become CSS-styleable This pull request has now been integrated. Changeset: d356340b Author: Abhinay Agarwal Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/d356340bd8b1fb85eefee6303a12063db9ede2e5 Stats: 67 lines in 4 files changed: 63 ins; 0 del; 4 mod 8172095: Let Node.managed become CSS-styleable Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/602 From kcr at openjdk.java.net Sat Sep 18 15:17:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 18 Sep 2021 15:17:55 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Include WebKit shared library for Windows > > Enable reproducible builds of the native WebKit shared library for > Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. > - Include media shared libraries for Windows > > Enable reproducible builds of the native media shared libraries for > Windows when SOURCE_DATE_EPOCH is defined. The libraries are: > > fxplugins.dll > glib-lite.dll > gstreamer-lite.dll > jfxmedia.dll > - Enable reproducible builds with SOURCE_DATE_EPOCH > - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Here are couple more observations, and then I'll need to put this on the back burner for a bit: 1. I did a CI build yesterday and again today on all three platforms and compared the sdk between the two builds for each platform. On all three platforms the results are the same: All files were identical except the native jfxwebkit library. So there is something in the WebKit build that is affected by an external input (perhaps the system date or similar). 2. On Mac, at least, there are several differences in the dylib files between a build on my local system and on our CI system. I was using the same devkit and boot JDK on both, and both were the same version of macOS (10.15.7). Likely some difference in the software installed on the two systems matters. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jgneff at openjdk.java.net Sat Sep 18 15:48:49 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Sat, 18 Sep 2021 15:48:49 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Include WebKit shared library for Windows > > Enable reproducible builds of the native WebKit shared library for > Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. > - Include media shared libraries for Windows > > Enable reproducible builds of the native media shared libraries for > Windows when SOURCE_DATE_EPOCH is defined. The libraries are: > > fxplugins.dll > glib-lite.dll > gstreamer-lite.dll > jfxmedia.dll > - Enable reproducible builds with SOURCE_DATE_EPOCH > - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH Thanks for the great comments, Kevin. I'm looking into the issues you raised. Would it be possible to coordinate the reviews of this pull request? My previous [set of tests in June][1] required 28 builds on three platforms and took me over four days to run and test. I would prefer to do that just one more time. So my plan is to address each of the review comments from @kevinrushforth, @johanvos, and @tiainen, but merge the master branch and do a final round of testing only after all three reviews are done and I have addressed each of the reviewers' comments. Would that work? Should I also wait for @arun-Joseph and @sashamatveev to re-review the parts they looked at before? [1]: https://github.com/openjdk/jfx/pull/446#issuecomment-861000786 ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jgneff at openjdk.java.net Sat Sep 18 16:19:45 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Sat, 18 Sep 2021 16:19:45 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Include WebKit shared library for Windows > > Enable reproducible builds of the native WebKit shared library for > Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. > - Include media shared libraries for Windows > > Enable reproducible builds of the native media shared libraries for > Windows when SOURCE_DATE_EPOCH is defined. The libraries are: > > fxplugins.dll > glib-lite.dll > gstreamer-lite.dll > jfxmedia.dll > - Enable reproducible builds with SOURCE_DATE_EPOCH > - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH > 1. On all three platforms the results are the same: All files were identical except the native jfxwebkit library. The [diffoscope][1] tool can show you the difference between the two files. You don't even need to install it. If the files aren't too big, you can upload them to the [online version][2]. > 2. On Mac, at least, there are several differences in the dylib files between a build on my local system and on our CI system. I would like to enable reproducible builds on ephemeral systems that create a clean and isolated build environment, like those created by GitHub Actions or the Launchpad build farm. To compare across developer systems, we would need a full system software bill of materials (SBOM) beyond what's listed in the Gradle dependency verification file. The SBOM is the next step in allowing for reproducible builds in any environment, but it's not a part of this pull request. [1]: https://diffoscope.org/ [2]: https://try.diffoscope.org/ ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jgneff at openjdk.java.net Sat Sep 18 17:17:05 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Sat, 18 Sep 2021 17:17:05 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 23:24:45 GMT, Kevin Rushforth wrote: > * The timestamps for all files in the zip archives are set to a hard-coded "1980-02-01", rather than the date and time specified by `SOURCE_DATE_EPOCH`. That date was chosen by the Gradle project five years ago in the commit ["Add sortedFileOrder and preserveFileTimestamps for archive tasks,"][1] and not changed five months later in the follow-up commit ["Move constants to classes using them."][2] This year, they confirmed the choice by closing the issue ["allow to configure timestamp used for preserveFileTimestamps."][3]. Also see [my comment][4] on the closed issue for more background information. At this point, it might be safest to go with the five-year-old Gradle default when compared to the alternatives: 1. Invoke the `find` and `touch` command-line tools from Gradle as described on the Reproducible Builds website under the "File modification times" section of the [Archive metadata][5] page. 2. Figure out how to do the equivalent thing in Gradle, perhaps using the `eachFile(closure)` or `eachFile(action)` method of the [`Zip` task][6]. 3. Add a post-processing step outside of the Gradle build that runs [`strip-nondeterminism`][7] to normalize the JAR and ZIP archives and then repackages the SDK, JMOD, and Javadoc bundles. Gradle is our build system. In for a penny, in for a pound? [1]: https://github.com/gradle/gradle/commit/0209b5dd [2]: https://github.com/gradle/gradle/commit/8b8daf34 [3]: https://github.com/gradle/gradle/issues/14819 [4]: https://github.com/gradle/gradle/issues/14819#issuecomment-922181921 [5]: https://reproducible-builds.org/docs/archives/ [6]: https://docs.gradle.org/current/dsl/org.gradle.api.tasks.bundling.Zip.html [7]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From nlisker at gmail.com Sun Sep 19 00:12:33 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 19 Sep 2021 03:12:33 +0300 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl> Message-ID: I've played around with the implementation and pushed a modified prototype to the sandbox [1]. I ended up with something similar to ReactFX: the orElse and orElseGet methods have their own binding classes that extend LazyObjectBinding, just like MapBinding and FlatMapBinding. The reason being that both their compute value and their subscription models are slightly different. While they can be matched to MapBinding like you did, it entails a bit of a roundabout way in my opinion. Creating a supplier for the constant value of orElse somewhat defeats the purpose I think. In addition, I think that it's fine to move the arguments' null checks to the binding classes themselves, even if it's a couple of levels deeper on the stack, while adding a message in the 2nd argument of Objects.requireNonNull for clarity. These classes are "self-contained" so it makes sense for them to check their arguments. They might be used in other places, perhaps in the public Bindings class. I also moved the subscription-related methods from ObservableValue to static methods in Subscription, at least for now, to defer the API related to Subscription. The branch doesn't compile because I didn't finish working on the visibility issue, but it's close enough to what I envision it like for the first PR. As for the java,util.Optional methods, I indeed did something like `x.orElse(5).getValue()` in the past in other cases, but this approach creates a new binding just to get the wrapped value out, which is very inefficient. (In one case I did booleanValue.isNull().get(), which creates a boolean binding, because isPresent() does not exist). I would like to see what others think about the Optional methods, The binding method variants are much more important, but I want to avoid a name clash if the Optional ones will have support. [1] https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx wrote: > > > On 15/09/2021 02:28, Nir Lisker wrote: > > Sorry, I'm not quite sure what you mean by this. Could you elaborate? > > The methods orElse and orElseGet are present in the PoC, and I think > > they're highly useful to have to deal with nulls. > > > > > > The methods that you call orElse and orElseGet return an > > ObservableValue. The Optional methods with the same names return the > > wrapped value (of type T). For comparison, ReactFX has: > > T getOrElse(T defaultValue) > > T getOrSupply(Supplier defaultSupplier) > > Val orElseConst(T other) > > Val orElse(ObservableValue other) > > I see what you mean now. The methods from java.util.Optional will return > an unwrapped value, while the ones from ObservableValue in the PoC > return an ObservableValue, but they have the same name. > > So java.util.Optional offers: > > T orElse(T other) > T orElseGet(Supplier supplier) > > And the PoC: > > ObservableValue orElse(T alternativeValue) > ObservableValue orElseGet(Supplier supplier) > > The main difference is in the returned types. Personally, I think it is > rarely useful for a binding to be queried directly and I've never used > the #getOrElse or #getOrSupply variants that ReactFX offers. On top of > that: > > x.orElse(5).getValue() === x.getOrElse(5) > > So it introduces another method in the interface to avoid having to > write ".getValue()". The opposite, introducing only the "unwrapped" > variants would still require the "wrapped" variants to be present as well. > > So, what I would suggest is to not add variants for #getOrElse and > #getOrSupply at all as they are of questionable value and would just > bloat the API for a bit less typing. In that case I think we can still > use the signatures as they are. > > ReactFX also offers: > > Val orElse(ObservableValue other) > > This is another rarely used feature IMHO, and I think Optional#or would > a better match for this functionality: > > Optional or(Supplier> supplier) > > In the POC the signature would be: > > ObservableValue or( > Supplier> supplier > ) > > I didn't implement this one in the PoC to keep it small, but I did > implement this in my JavaFX EventStream library before. > > > So it deals with both getting the wrapped value in null cases and with > > getting a "dynamic value" in null cases. I find the Optional-like method > > 'T getOrElse(T defaultValue)' useful (along with others such as > > ifPresent because Optional is just useful for dealing with wrapped > > values). What I'm saying is that we should be careful with the names if > > we include both "constant" and "dynamic" versions of 'orElse'-like > methods. > > I think #ifPresent can be added, not so sure about the usefulness of > #getOrElse (see above). > > > The null check in ReactFX's #computeValue is > > actually checking the result of the mapping function, not whether the > > function instance itself was null. > > > > I didn't mean the null-ness of the map argument. What I meant was that > > there is this implementation, which is similar to what ReactFX does: > > Sorry, I see it now. You have a good point, the current implementation > indeed wraps another Lambda to add the null check which could have been > done in #computeValue. I think it would be a good move to avoid the > extra lambda simply because the end result would be more readable -- any > performance improvement would be a bonus, I don't know if there will be > any. > > > As for my points 3 and 4, I'll have to try and play with the > > implementation myself, which will be easier to do when there is some PR > > in the works. > > Perhaps this is useful: > https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx > > When you add this as a maven dependency to your project, you will get > the new PoC functionality. It basically uses the Maven shade plugin to > replace a few classes in javafx-base -- I use this sometimes to fix bugs > I need fixed immediately by patching jfx, but found it also works very > nicely to experiment with this PoC. > > Also, the PoC PR compiles fine, it may need rebasing. > > > To close "Bindings.select*(): add new type-safe template based API > > instead of legacy-style set of methods" we'd need the flatMap/select > > method to be included. > > > > Yes. I think that we can include flatMap in this iteration, perhaps as > > a separate PR? > > That should be no problem, I can split it up. > > > I don't think we really need specialized methods for primitives (or > at > > least, not right away). At this point the primitive versions only > > really differ in what value they'd return if the binding would be > null > > and perhaps they do a little less boxing/unboxing. Since you can > select > > the default value with #orElse which is more flexible. I don't see > much > > use to add those variants. > > > > I agree, I would avoid bloating the primitive specialization classes for > > now, especially when Valhalla is planned to take care of those. > > Yes, I think we can easily do without for now. > > > The ticket is a bit unclear as I can't see what type "x" is. > > > > Yes, but I got the impression that either way it can be solved with map > > (or flatMap). > > Agreed. > > --John > From nlisker at openjdk.java.net Sun Sep 19 01:36:40 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 19 Sep 2021 01:36:40 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: <5kPyxLaYabWvuk6GjVZLl1G74WRnl8J0jh00O_E_OeE=.40362677-4a25-4297-a0c2-5c015e9e6e97@github.com> On Wed, 15 Sep 2021 11:16:39 GMT, Ambarish Rapte wrote: > Above one will just be uniform with existing doc. In this case it doesn't matter much, but in general I don't like many places of the `Background` and `Border` docs as they stand :) I already looked at them as a starting point when creating the initial commit. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From nlisker at openjdk.java.net Sun Sep 19 01:40:11 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Sun, 19 Sep 2021 01:40:11 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v4] In-Reply-To: References: Message-ID: > Added convenience factory factory methods for Background and Border. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Added null tests and changed doc as per comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/610/files - new: https://git.openjdk.java.net/jfx/pull/610/files/345d759f..a550ff85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=610&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=610&range=02-03 Stats: 16 lines in 4 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/610.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/610/head:pull/610 PR: https://git.openjdk.java.net/jfx/pull/610 From mhanl at openjdk.java.net Sun Sep 19 10:56:42 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sun, 19 Sep 2021 10:56:42 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: References: Message-ID: <5a8Uu_mM0tRskx5yUSww5fbQGkQnSDJeF1DbaDHriT0=.1801fe13-fdc7-4870-bf9b-55582ba99752@github.com> On Thu, 16 Sep 2021 21:15:20 GMT, Kevin Rushforth wrote: > > > ``` > > > public static Border stroke(Paint stroke, double width) { > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ... > > > But I really want to hear other opinions. This can also be a follow up. :) > > > > > > I don't mind adding this variant, but it needs consensus. > > I agree that it needs consensus, so the question is how many apps would use it from code (as opposed to CSS), and be satisfied with the other defaults. I don't object to adding a 2nd variant that takes a stroke width as long as we stop there. I don't want variants that take style, or corner radii, or insets, etc. (at that point, just use the existing API). I agree. For me this would be the last useful variant I often needed in daily programming. Everything else should use the normal constructor as it is there for very specialized background/border. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From mhanl at openjdk.java.net Sun Sep 19 11:27:47 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sun, 19 Sep 2021 11:27:47 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v4] In-Reply-To: References: Message-ID: <01yFJX73YIxKwYhlnmhAqiWnwdPdMvXCepGGTFsjKsU=.f57e3740-fedb-470b-a0ae-262d16980c60@github.com> On Thu, 19 Aug 2021 12:16:28 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> Separated test and made the cell a supplier instead > > modules/javafx.controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java line 301: > >> 299: return; >> 300: } >> 301: > > (darn, can't add the important lines - which is backing out if treeItem is null) > > The re-ordering leads to change of behavior, here's a test that's passing/failing before/after: > > /** > * change of behavior: cell must not be editing if treeItem == null. > * fails with fix, passes without > */ > @Test > public void testChoiceBoxTreeCellEditing() { > TreeView treeView = new TreeView<>(); > treeView.setEditable(true); > ChoiceBoxTreeCell cell = new ChoiceBoxTreeCell<>(); > cell.updateTreeView(treeView); > cell.updateItem("TEST", false); > > cell.startEdit(); > assertFalse(cell.isEditing()); > assertNull(cell.getGraphic()); > } > > same for ComboBoxTreeCell Hm.. weird that the super class is firing an edit event even with `treeItem = null`. Maybe this should be investigated in a follow-up. Good catch though. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/569 From mhanl at openjdk.java.net Sun Sep 19 11:52:55 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sun, 19 Sep 2021 11:52:55 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v5] In-Reply-To: References: Message-ID: > This PR sets an unified logic to every **startEdit()** method of all Cell implementations. > So startEdit() is always doing the same now: > > `super.startEdit();` > `if (!isEditing()) { > return; > }` > > This will prevent a NPE while also being cleaner (no more double checks) > The commits are splitted into 4 base commits: > - First commit changes the startEdit() for TableCell implementations (8 files) > - Second commit changes the startEdit() for TreeTableCell implementations (7 files) > - Third commit changes the startEdit() for ListCell implementations (7 files) > - Fourth commit changes the startEdit() for TreeCell implementations (7 files) > > While writing tests, I found out that the CheckBoxListCell and the CheckBoxTreeCell don't disable their CheckBox, which is wrong. > In CheckBoxTableCell and CheckBoxTreeTableCell the CheckBox is disabled, but they don't check their dependencies e.g. TableColumn for null, leading to a NPE if not set. > > I wrote a follow-up and assigned it to myself: https://bugs.openjdk.java.net/browse/JDK-8270042 > The aim of this should be, that all 4 CheckBox...Cells have a proper CheckBox disablement while also being nullsafe. > > ~Note 1: I removed the tests in TableCellTest added in https://github.com/openjdk/jfx/pull/529 in favor of the new parameterized TableCellStartEditTest~ > Note 2: This also fixes https://bugs.openjdk.java.net/browse/JDK-8268295 Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments - cell is supplied in setup() method - treeItem = null guard is done before calling startEdit() - Added checks for the cell graphic ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/569/files - new: https://git.openjdk.java.net/jfx/pull/569/files/fa89fccd..bf9190b0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=569&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=569&range=03-04 Stats: 1186 lines in 11 files changed: 602 ins; 574 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/569.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/569/head:pull/569 PR: https://git.openjdk.java.net/jfx/pull/569 From mhanl at openjdk.java.net Sun Sep 19 11:52:56 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sun, 19 Sep 2021 11:52:56 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v4] In-Reply-To: References: Message-ID: On Thu, 19 Aug 2021 12:25:16 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> Separated test and made the cell a supplier instead > > modules/javafx.controls/src/main/java/javafx/scene/control/cell/TextFieldTreeCell.java line 195: > >> 193: if (!isEditing()) { >> 194: return; >> 195: } > > similar to ChoiceBox/ComboBoxTreeCell, except that a similar test fails both before/after the fix hm interesting enough this tree cell has no `treeItem = null` guard (unlike the others). TreeCells are very weird ?? ------------- PR: https://git.openjdk.java.net/jfx/pull/569 From hjohn at xs4all.nl Sun Sep 19 15:11:29 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sun, 19 Sep 2021 17:11:29 +0200 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl> Message-ID: I need to get you the tests I wrote, unfortunately, they're JUnit 5, please see the tests here: https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value The OrElseBinding is incorrect, the compute value should read: protected T computeValue() { T value = source.getValue(); return value == null ? constant : value; } Similar for OrElseGetBinding. I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I think the tests would become pretty unreadable and less useful / thourough otherwise). What are the options? - Integrate a nested runner (there is an Apache 2.0 licensed one available) - Create our own nested runner (about 200 lines of code) - Can we introduce JUnit 5? - Rewrite to plain JUnit 4? Let me know, and I can integrate them. --John On 19/09/2021 02:12, Nir Lisker wrote: > I've played around with the implementation and pushed a modified > prototype to the sandbox [1]. I ended up with something similar to ReactFX: > the orElse and orElseGet methods have their own binding classes that > extend LazyObjectBinding, just like MapBinding and FlatMapBinding. The > reason being that both their compute value and their subscription models > are slightly different. While they can be matched to MapBinding like you > did, it entails a bit of a roundabout way in my opinion. Creating a > supplier for the constant value of orElse somewhat defeats the purpose I > think. I have no strong opinion here, just wanted to keep the MR small. The supplier should be an inline candidate, but creating a separate class is fine too. As for the subscription model: flat map has a more complicated one, but orElse, orElseGet and map all have the same one. > In addition, I think that it's fine to move the arguments' null checks to > the binding classes themselves, even if it's a couple of levels deeper on > the stack, while adding a message in the 2nd argument of > Objects.requireNonNull for clarity. These classes are "self-contained" so > it makes sense for them to check their arguments. They might be used in > other places, perhaps in the public Bindings class. The messages will need to be written from the perspective of the Binding class then IMHO. > I also moved the subscription-related methods from ObservableValue to > static methods in Subscription, at least for now, to defer the API related > to Subscription. Sounds good. > The branch doesn't compile because I didn't finish working on the > visibility issue, but it's close enough to what I envision it like for the > first PR. I've ported the changes over to my branch and ran the tests on it, they all pass apart from the above mentioned problem in the OrElse bindings. > As for the java,util.Optional methods, I indeed did something like > `x.orElse(5).getValue()` in the past in other cases, but this approach > creates a new binding just to get the wrapped value out, which is very > inefficient. (In one case I did booleanValue.isNull().get(), which creates > a boolean binding, because isPresent() does not exist). I would like to see > what others think about the Optional methods, The binding method variants > are much more important, but I want to avoid a name clash if the Optional > ones will have support. Okay, some more things to consider: ObservableValue is not an Optional, their get methods respond differently with Optional#get throwing an exception when null -- the #orElse is a necessity; this is not the case for ObservableValue#getValue. When creating mapping chains, you are going to do this because you want to bind this to another property or to listen on it (with subscribe). You don't want to do this as a one time thing. If you are creating a chain just to calculate a value you can just do this directly. Instead of: widthProperty().map(x -> x * 2).getValue() You'd do: getWidth() * 2; With flat mapping however this is not as easy: [1] node.sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse(false); You could try: node.getScene().getWindow().isShowing(); But that will not work when Scene or Window is null. You'd have to write it as: [2] Optional.ofNullable(node.getScene()) .map(Scene::getWindow) .map(Window::isShowing) .orElse(false); If you only offer a "specialized" orElse, you'd still need to create several bindings: [3] node.sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse2(false); // orElse which returns a value not a binding If you compare [2] (which is possible now) with [3] the difference is minimal. A bit more ceremony at the start for [2] but a shorter, cleaner and faster mapping (no bindings and no need to use the property methods). Now, if you already HAVE the binding for some other purpose, then it is highly likely it also already has an #orElse that is needed as part of the binding. In that case calling #getValue is fine without much need for another #orElse variant. --John > > [1] > https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings > > On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx wrote: > >> >> >> On 15/09/2021 02:28, Nir Lisker wrote: >>> Sorry, I'm not quite sure what you mean by this. Could you elaborate? >>> The methods orElse and orElseGet are present in the PoC, and I think >>> they're highly useful to have to deal with nulls. >>> >>> >>> The methods that you call orElse and orElseGet return an >>> ObservableValue. The Optional methods with the same names return the >>> wrapped value (of type T). For comparison, ReactFX has: >>> T getOrElse(T defaultValue) >>> T getOrSupply(Supplier defaultSupplier) >>> Val orElseConst(T other) >>> Val orElse(ObservableValue other) >> >> I see what you mean now. The methods from java.util.Optional will return >> an unwrapped value, while the ones from ObservableValue in the PoC >> return an ObservableValue, but they have the same name. >> >> So java.util.Optional offers: >> >> T orElse(T other) >> T orElseGet(Supplier supplier) >> >> And the PoC: >> >> ObservableValue orElse(T alternativeValue) >> ObservableValue orElseGet(Supplier supplier) >> >> The main difference is in the returned types. Personally, I think it is >> rarely useful for a binding to be queried directly and I've never used >> the #getOrElse or #getOrSupply variants that ReactFX offers. On top of >> that: >> >> x.orElse(5).getValue() === x.getOrElse(5) >> >> So it introduces another method in the interface to avoid having to >> write ".getValue()". The opposite, introducing only the "unwrapped" >> variants would still require the "wrapped" variants to be present as well. >> >> So, what I would suggest is to not add variants for #getOrElse and >> #getOrSupply at all as they are of questionable value and would just >> bloat the API for a bit less typing. In that case I think we can still >> use the signatures as they are. >> >> ReactFX also offers: >> >> Val orElse(ObservableValue other) >> >> This is another rarely used feature IMHO, and I think Optional#or would >> a better match for this functionality: >> >> Optional or(Supplier> supplier) >> >> In the POC the signature would be: >> >> ObservableValue or( >> Supplier> supplier >> ) >> >> I didn't implement this one in the PoC to keep it small, but I did >> implement this in my JavaFX EventStream library before. >> >>> So it deals with both getting the wrapped value in null cases and with >>> getting a "dynamic value" in null cases. I find the Optional-like method >>> 'T getOrElse(T defaultValue)' useful (along with others such as >>> ifPresent because Optional is just useful for dealing with wrapped >>> values). What I'm saying is that we should be careful with the names if >>> we include both "constant" and "dynamic" versions of 'orElse'-like >> methods. >> >> I think #ifPresent can be added, not so sure about the usefulness of >> #getOrElse (see above). >> >>> The null check in ReactFX's #computeValue is >>> actually checking the result of the mapping function, not whether the >>> function instance itself was null. >>> >>> I didn't mean the null-ness of the map argument. What I meant was that >>> there is this implementation, which is similar to what ReactFX does: >> >> Sorry, I see it now. You have a good point, the current implementation >> indeed wraps another Lambda to add the null check which could have been >> done in #computeValue. I think it would be a good move to avoid the >> extra lambda simply because the end result would be more readable -- any >> performance improvement would be a bonus, I don't know if there will be >> any. >> >>> As for my points 3 and 4, I'll have to try and play with the >>> implementation myself, which will be easier to do when there is some PR >>> in the works. >> >> Perhaps this is useful: >> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx >> >> When you add this as a maven dependency to your project, you will get >> the new PoC functionality. It basically uses the Maven shade plugin to >> replace a few classes in javafx-base -- I use this sometimes to fix bugs >> I need fixed immediately by patching jfx, but found it also works very >> nicely to experiment with this PoC. >> >> Also, the PoC PR compiles fine, it may need rebasing. >> >>> To close "Bindings.select*(): add new type-safe template based API >>> instead of legacy-style set of methods" we'd need the flatMap/select >>> method to be included. >>> >>> Yes. I think that we can include flatMap in this iteration, perhaps as >>> a separate PR? >> >> That should be no problem, I can split it up. >> >>> I don't think we really need specialized methods for primitives (or >> at >>> least, not right away). At this point the primitive versions only >>> really differ in what value they'd return if the binding would be >> null >>> and perhaps they do a little less boxing/unboxing. Since you can >> select >>> the default value with #orElse which is more flexible. I don't see >> much >>> use to add those variants. >>> >>> I agree, I would avoid bloating the primitive specialization classes for >>> now, especially when Valhalla is planned to take care of those. >> >> Yes, I think we can easily do without for now. >> >>> The ticket is a bit unclear as I can't see what type "x" is. >>> >>> Yes, but I got the impression that either way it can be solved with map >>> (or flatMap). >> >> Agreed. >> >> --John >> > From fkirmaier at openjdk.java.net Sun Sep 19 22:04:13 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 19 Sep 2021 22:04:13 GMT Subject: RFR: 8273969: Memory Leak on the Lambda provided to Platform.startup In-Reply-To: References: Message-ID: On Sun, 19 Sep 2021 15:33:46 GMT, Florian Kirmaier wrote: > Probably my most boring PR. ;) > Setting the lambda to null, after it has been used, fixes the leak. For the strange reason, why i haven't used a lambda for the test, I've created another ticket: https://bugs.openjdk.java.net/browse/JDK-8273970 ------------- PR: https://git.openjdk.java.net/jfx/pull/626 From fkirmaier at openjdk.java.net Sun Sep 19 22:04:12 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Sun, 19 Sep 2021 22:04:12 GMT Subject: RFR: 8273969: Memory Leak on the Lambda provided to Platform.startup Message-ID: Probably my most boring PR. ;) Setting the lambda to null, after it has been used, fixes the leak. ------------- Commit messages: - JDK-8273969 Changes: https://git.openjdk.java.net/jfx/pull/626/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=626&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273969 Stats: 49 lines in 2 files changed: 49 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/626.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/626/head:pull/626 PR: https://git.openjdk.java.net/jfx/pull/626 From tschindl at openjdk.java.net Mon Sep 20 07:43:48 2021 From: tschindl at openjdk.java.net (Tom Schindl) Date: Mon, 20 Sep 2021 07:43:48 GMT Subject: RFR: 8273969: Memory Leak on the Lambda provided to Platform.startup In-Reply-To: References: Message-ID: On Sun, 19 Sep 2021 15:58:24 GMT, Florian Kirmaier wrote: > For the strange reason, why i haven't used a lambda for the test, I've created another ticket: https://bugs.openjdk.java.net/browse/JDK-8273970 I dpn't think this is a bug - none capturing lambdas are instantiated once and you reuse that instance for all time - the JLS allows this https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.27.4 ------------- PR: https://git.openjdk.java.net/jfx/pull/626 From fkirmaier at openjdk.java.net Mon Sep 20 08:24:44 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 20 Sep 2021 08:24:44 GMT Subject: RFR: 8273969: Memory Leak on the Lambda provided to Platform.startup In-Reply-To: References: Message-ID: <0SvQG6L7gEgmlhscAJX7FzHL8USaM_X0gWxgwbTwnHI=.4d5cd528-7b2f-4c43-b095-3aa65fb32315@github.com> On Sun, 19 Sep 2021 15:33:46 GMT, Florian Kirmaier wrote: > Probably my most boring PR. ;) > Setting the lambda to null, after it has been used, fixes the leak. I guess that makes sense - but I can think of a million ways to create nearly unsolvable problems with it. ------------- PR: https://git.openjdk.java.net/jfx/pull/626 From nlisker at openjdk.java.net Mon Sep 20 11:51:47 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 20 Sep 2021 11:51:47 GMT Subject: RFR: 8272870: Add convenience factory methods for border and background [v3] In-Reply-To: <5a8Uu_mM0tRskx5yUSww5fbQGkQnSDJeF1DbaDHriT0=.1801fe13-fdc7-4870-bf9b-55582ba99752@github.com> References: <5a8Uu_mM0tRskx5yUSww5fbQGkQnSDJeF1DbaDHriT0=.1801fe13-fdc7-4870-bf9b-55582ba99752@github.com> Message-ID: On Sun, 19 Sep 2021 10:53:02 GMT, Marius Hanl wrote: >>> > ``` >>> > public static Border stroke(Paint stroke, double width) { >>> > ``` >>> > ... >>> > But I really want to hear other opinions. This can also be a follow up. :) >>> >>> I don't mind adding this variant, but it needs consensus. >> >> I agree that it needs consensus, so the question is how many apps would use it from code (as opposed to CSS), and be satisfied with the other defaults. I don't object to adding a 2nd variant that takes a stroke width as long as we stop there. I don't want variants that take style, or corner radii, or insets, etc. (at that point, just use the existing API). > >> > > ``` >> > > public static Border stroke(Paint stroke, double width) { >> > > ``` >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > ... >> > > But I really want to hear other opinions. This can also be a follow up. :) >> > >> > >> > I don't mind adding this variant, but it needs consensus. >> >> I agree that it needs consensus, so the question is how many apps would use it from code (as opposed to CSS), and be satisfied with the other defaults. I don't object to adding a 2nd variant that takes a stroke width as long as we stop there. I don't want variants that take style, or corner radii, or insets, etc. (at that point, just use the existing API). > > I agree. For me this would be the last useful variant I often needed in daily programming. Everything else should use the normal constructor as it is there for very specialized background/border. @Maran23 I think that you should ask on the mailing list if others want that variant. I didn't see any discussion on this when I proposed these methods. ------------- PR: https://git.openjdk.java.net/jfx/pull/610 From kcr at openjdk.java.net Mon Sep 20 13:43:24 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 20 Sep 2021 13:43:24 GMT Subject: RFR: 8273969: Memory Leak on the Lambda provided to Platform.startup In-Reply-To: References: Message-ID: On Sun, 19 Sep 2021 15:33:46 GMT, Florian Kirmaier wrote: > Probably my most boring PR. ;) > Setting the lambda to null, after it has been used, fixes the leak. The fix looks obviously correct. I verified that the test catches the bug (fails without the fix and passes with the fix). I left a few cleanup comments on the test. Btw, I almost left an additional test comment about needing to wait for the `Runnable` to be called (e.g., by waiting for a latch that is triggered in the `Runnable`), but I realized that this is unnecessary given that the test waits for the `Runnable` to be garbage-collected, which can't happen until after the `run` method of the `Runnable` has been called. One last suggestion is that I recommend to change "Lambda" to "Runnable" in the title of the bug (and thus the PR). tests/system/src/test/java/test/javafx/scene/PlatformStartupMemoryLeakTest.java line 26: > 24: */ > 25: > 26: package test.javafx.scene; Similar tests are in the `test.com.sun.javafx.application` package, so I recommend putting this test there. tests/system/src/test/java/test/javafx/scene/PlatformStartupMemoryLeakTest.java line 34: > 32: public class PlatformStartupMemoryLeakTest { > 33: > 34: @Test Since this test calls `Platform::startup`, this class must only have a single `@Test` method. I recommend adding a comment to that effect, so that someone doesn't try to add a second test method later. tests/system/src/test/java/test/javafx/scene/PlatformStartupMemoryLeakTest.java line 37: > 35: public void testStartupLeak() { > 36: JMemoryBuddy.memoryTest((checker) -> { > 37: // Doesn't work as lambda for some reason, due to "BoundMethodHandle$Species_L" Based on Tom's comment, and also my reading of the spec, this is expected (if somewhat counter-intuitive), so please modify this comment to indicate that the `Runnable` must not be turned into a lambda. tests/system/src/test/java/test/javafx/scene/PlatformStartupMemoryLeakTest.java line 47: > 45: checker.assertCollectable(r); > 46: }); > 47: } I recommend adding an `@After` (or `@AfterClass`) cleanup method that calls `Platform::exit`. ------------- PR: https://git.openjdk.java.net/jfx/pull/626 From github.com+85555697+andreas-heger at openjdk.java.net Mon Sep 20 13:46:16 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Mon, 20 Sep 2021 13:46:16 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v4] In-Reply-To: References: Message-ID: > The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url) Andreas Heger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'openjdk:master' into fix-8255015 - Merge branch 'openjdk:master' into fix-8255015 - Merge branch 'openjdk:master' into fix-8255015 - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/531/files - new: https://git.openjdk.java.net/jfx/pull/531/files/fdb1ddbe..c7e58901 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=02-03 Stats: 179 lines in 6 files changed: 156 ins; 18 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531 PR: https://git.openjdk.java.net/jfx/pull/531 From kcr at openjdk.java.net Mon Sep 20 14:14:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 20 Sep 2021 14:14:52 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 11:05:25 GMT, Andreas Heger wrote: >> @andreas-heger Welcome to the `jfx` project. At a quick glance, the fix looks promising. Have you tested this on Windows with Hi-DPI to make sure there is no impact? Would you be able add an automated test case that fails (only on Mac retina) without the fix and passes (on all platforms) with your fix? Hi-DPI fixes are often tricky to test in an automated test, so if not, we can use the existing manual test. >> >> @nlisker this is the same problem I noted while testing PR #334. Clearly I had forgotten that it was not only a preexisting bug, but a known bug that was already filed. I intend to test this alone and in connection with your PR. > > @kevinrushforth >> The fix looks good. I tested it both in isolation and with PR #334 and it works on both a retina and non-retina display. >> >> If you have time to write an automated test, that would be useful, but if not then a manual test would be OK. > > Ok, I will try to write an automated test case which draws a sphere in a SubScene and then calculates the average color of the generated image. The test will be passed if the calculated average does not differ from the excepted average color by a certain tolerance value. I'm not sure if I will manage to do this... but I will give it a try. @andreas-heger are you able to come up with an automated test for this bug? ------------- PR: https://git.openjdk.java.net/jfx/pull/531 From shadzic at openjdk.java.net Tue Sep 21 08:53:07 2021 From: shadzic at openjdk.java.net (Hadzic Samir) Date: Tue, 21 Sep 2021 08:53:07 GMT Subject: RFR: 8090158: Wrong implementation of adjustValue in scrollBars [v2] In-Reply-To: References: Message-ID: > JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158) > > The javadoc of the ScrollBar#adjustValue specifically says that it will adjust the value based on the block increment value. Therefore, there is no reason to stop at the given value when reaching an end. Hadzic Samir has updated the pull request incrementally with one additional commit since the last revision: Fix upon review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/582/files - new: https://git.openjdk.java.net/jfx/pull/582/files/748b9242..06680e30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=582&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=582&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/582.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/582/head:pull/582 PR: https://git.openjdk.java.net/jfx/pull/582 From shadzic at openjdk.java.net Tue Sep 21 08:53:07 2021 From: shadzic at openjdk.java.net (Hadzic Samir) Date: Tue, 21 Sep 2021 08:53:07 GMT Subject: RFR: 8090158: Wrong implementation of adjustValue in scrollBars In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 09:12:05 GMT, Hadzic Samir wrote: > JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158) > > The javadoc of the ScrollBar#adjustValue specifically says that it will adjust the value based on the block increment value. Therefore, there is no reason to stop at the given value when reaching an end. Sorry for the delay, I have missed the notifications somehow. I've noticed that the order of the `assertEquals` are also in the wrong order to the other tests of this file. Should I correct them also or leave it like that to avoid a large diff? ------------- PR: https://git.openjdk.java.net/jfx/pull/582 From aghaisas at openjdk.java.net Tue Sep 21 09:15:50 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 21 Sep 2021 09:15:50 GMT Subject: RFR: 8090158: Wrong implementation of adjustValue in scrollBars [v2] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 08:53:07 GMT, Hadzic Samir wrote: >> JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158) >> >> The javadoc of the ScrollBar#adjustValue specifically says that it will adjust the value based on the block increment value. Therefore, there is no reason to stop at the given value when reaching an end. > > Hadzic Samir has updated the pull request incrementally with one additional commit since the last revision: > > Fix upon review Marked as reviewed by aghaisas (Reviewer). I prefer small targeted bug fixes. The assert order in other tests in this file can be fixed separately. ------------- PR: https://git.openjdk.java.net/jfx/pull/582 From mariushanl at web.de Tue Sep 21 09:43:45 2021 From: mariushanl at web.de (Marius Hanl) Date: Tue, 21 Sep 2021 11:43:45 +0200 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: As also written in a comment here: https://github.com/openjdk/jfx/pull/610 I would like to propose one more convenience method which should be added to JavaFX: public static Border stroke(Paint stroke, double width) { return new Border(new BorderStroke(stroke, BorderStrokeStyle.SOLID, null, ne w BorderWidths(width))); } I think it's quite common that you want to create a solid border with another width then the default of 1 (for every side). Note: This is also the last use case I think makes sense to add as a convenience method. Any other use case is likely to be so complex that it makes sense to use the normal existing constructors. Feel free to share you opinion. - Marius Gesendet: Dienstag, 08. Juni 2021 um 03:19 Uhr Von: "Nir Lisker" An: "Kevin Rushforth" Cc: "openjfx-dev at openjdk.java.net Mailing" Betreff: Re: [External] : Re: Convenience factories for Border and Background The new API: 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` that does `new Border(new BorderStroke(Paint stroke , BorderStrokeStyle.SOLID, null, null));` 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` that does `new Background(new BackgroundFill(Paint fill, null, null));` I don't mind either name choice. On Tue, Jun 8, 2021 at 2:50 AM Kevin Rushforth wrote: > If I recall, there were a few developers that chimed in. It's a simple > enough addition -- at least your original proposal (not the suggestion of > mirroring the Color API, which I don't like) -- that it seems OK to me. > > Can you repost your currently proposed API and see if those who might like > to use it are satisfied with it? > > -- Kevin > > > On 6/7/2021 4:41 PM, Nir Lisker wrote: > > Does this constitute sufficient interest in the enhancement? > > On Thu, May 13, 2021 at 6:41 PM Michael Strau? > wrote: > >> Another option could be to mirror the `Color` API in both `Border` and >> `Background`, like in the following examples: >> >> Color.rgb(125, 100, 75) >> Border.rgb(125, 100, 75) >> Background.rgb(125, 100, 75) >> >> Color.gray(127) >> Border.gray(127) >> Background.gray(127) >> >> Color.web("orange", 0.5) >> Border.web("orange", 0.5) >> Background.web("orange", 0.5) >> >> We could also mirror the named color constants, which would enable a >> very compact syntax: >> >> StackPane pane = new StackPane(); >> pane.setBorder(Border.RED); >> pane.setBackground(Background.BLUE); >> >> This is very similar to how "red" or "blue" are valid values for >> "-fx-border" or "-fx-background" in CSS. >> > > From nlisker at gmail.com Tue Sep 21 10:36:13 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 21 Sep 2021 13:36:13 +0300 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl> <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl> <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl> <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl> Message-ID: > > The OrElseBinding is incorrect > Yes, that was a typo with the order of the arguments in the ternary statement. I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I > think the tests would become pretty unreadable and less useful / > thourough otherwise). > > What are the options? > This is a bigger question. Kevin will have to answer that. As for the subscription model: flat map has a more complicated one, but > orElse, orElseGet and map all have the same one. > >From what I saw, ReactFX uses a different subscription model for these. I could have misread it. The messages will need to be written from the perspective of the Binding > class then IMHO. > That's fine. As for the Optional methods, I'll have a look in my code base and see if the places I would like to use them at will become irrelevant anyway with the fluent bindings. I'm fine with proceeding with the current names of the proposed methods. On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx wrote: > I need to get you the tests I wrote, unfortunately, they're JUnit 5, > please see the tests here: > > > https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value > > The OrElseBinding is incorrect, the compute value should read: > > protected T computeValue() { > T value = source.getValue(); > return value == null ? constant : value; > } > > Similar for OrElseGetBinding. > > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I > think the tests would become pretty unreadable and less useful / > thourough otherwise). > > What are the options? > > - Integrate a nested runner (there is an Apache 2.0 licensed one available) > - Create our own nested runner (about 200 lines of code) > - Can we introduce JUnit 5? > - Rewrite to plain JUnit 4? > > Let me know, and I can integrate them. > > --John > > On 19/09/2021 02:12, Nir Lisker wrote: > > I've played around with the implementation and pushed a modified > > prototype to the sandbox [1]. I ended up with something similar to > ReactFX: > > the orElse and orElseGet methods have their own binding classes that > > extend LazyObjectBinding, just like MapBinding and FlatMapBinding. The > > reason being that both their compute value and their subscription models > > are slightly different. While they can be matched to MapBinding like you > > did, it entails a bit of a roundabout way in my opinion. Creating a > > supplier for the constant value of orElse somewhat defeats the purpose I > > think. > > I have no strong opinion here, just wanted to keep the MR small. The > supplier should be an inline candidate, but creating a separate class is > fine too. > > As for the subscription model: flat map has a more complicated one, but > orElse, orElseGet and map all have the same one. > > > In addition, I think that it's fine to move the arguments' null checks to > > the binding classes themselves, even if it's a couple of levels deeper on > > the stack, while adding a message in the 2nd argument of > > Objects.requireNonNull for clarity. These classes are "self-contained" so > > it makes sense for them to check their arguments. They might be used in > > other places, perhaps in the public Bindings class. > > The messages will need to be written from the perspective of the Binding > class then IMHO. > > > I also moved the subscription-related methods from ObservableValue to > > static methods in Subscription, at least for now, to defer the API > related > > to Subscription. > > Sounds good. > > > The branch doesn't compile because I didn't finish working on the > > visibility issue, but it's close enough to what I envision it like for > the > > first PR. > > I've ported the changes over to my branch and ran the tests on it, they > all pass apart from the above mentioned problem in the OrElse bindings. > > > As for the java,util.Optional methods, I indeed did something like > > `x.orElse(5).getValue()` in the past in other cases, but this approach > > creates a new binding just to get the wrapped value out, which is very > > inefficient. (In one case I did booleanValue.isNull().get(), which > creates > > a boolean binding, because isPresent() does not exist). I would like to > see > > what others think about the Optional methods, The binding method variants > > are much more important, but I want to avoid a name clash if the Optional > > ones will have support. > > Okay, some more things to consider: > > ObservableValue is not an Optional, their get methods respond > differently with Optional#get throwing an exception when null -- the > #orElse is a necessity; this is not the case for ObservableValue#getValue. > > When creating mapping chains, you are going to do this because you want > to bind this to another property or to listen on it (with subscribe). > You don't want to do this as a one time thing. If you are creating a > chain just to calculate a value you can just do this directly. Instead of: > > widthProperty().map(x -> x * 2).getValue() > > You'd do: > > getWidth() * 2; > > With flat mapping however this is not as easy: > > [1] > node.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false); > > You could try: > > node.getScene().getWindow().isShowing(); > > But that will not work when Scene or Window is null. You'd have to > write it as: > > [2] > Optional.ofNullable(node.getScene()) > .map(Scene::getWindow) > .map(Window::isShowing) > .orElse(false); > > If you only offer a "specialized" orElse, you'd still need to create > several bindings: > > [3] > node.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse2(false); // orElse which returns a value not a binding > > If you compare [2] (which is possible now) with [3] the difference is > minimal. A bit more ceremony at the start for [2] but a shorter, cleaner > and faster mapping (no bindings and no need to use the property methods). > > Now, if you already HAVE the binding for some other purpose, then it is > highly likely it also already has an #orElse that is needed as part of > the binding. In that case calling #getValue is fine without much need > for another #orElse variant. > > --John > > > > > [1] > > > https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings > > > > On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx wrote: > > > >> > >> > >> On 15/09/2021 02:28, Nir Lisker wrote: > >>> Sorry, I'm not quite sure what you mean by this. Could you > elaborate? > >>> The methods orElse and orElseGet are present in the PoC, and I > think > >>> they're highly useful to have to deal with nulls. > >>> > >>> > >>> The methods that you call orElse and orElseGet return an > >>> ObservableValue. The Optional methods with the same names return the > >>> wrapped value (of type T). For comparison, ReactFX has: > >>> T getOrElse(T defaultValue) > >>> T getOrSupply(Supplier defaultSupplier) > >>> Val orElseConst(T other) > >>> Val orElse(ObservableValue other) > >> > >> I see what you mean now. The methods from java.util.Optional will return > >> an unwrapped value, while the ones from ObservableValue in the PoC > >> return an ObservableValue, but they have the same name. > >> > >> So java.util.Optional offers: > >> > >> T orElse(T other) > >> T orElseGet(Supplier supplier) > >> > >> And the PoC: > >> > >> ObservableValue orElse(T alternativeValue) > >> ObservableValue orElseGet(Supplier supplier) > >> > >> The main difference is in the returned types. Personally, I think it is > >> rarely useful for a binding to be queried directly and I've never used > >> the #getOrElse or #getOrSupply variants that ReactFX offers. On top of > >> that: > >> > >> x.orElse(5).getValue() === x.getOrElse(5) > >> > >> So it introduces another method in the interface to avoid having to > >> write ".getValue()". The opposite, introducing only the "unwrapped" > >> variants would still require the "wrapped" variants to be present as > well. > >> > >> So, what I would suggest is to not add variants for #getOrElse and > >> #getOrSupply at all as they are of questionable value and would just > >> bloat the API for a bit less typing. In that case I think we can still > >> use the signatures as they are. > >> > >> ReactFX also offers: > >> > >> Val orElse(ObservableValue other) > >> > >> This is another rarely used feature IMHO, and I think Optional#or would > >> a better match for this functionality: > >> > >> Optional or(Supplier> supplier) > >> > >> In the POC the signature would be: > >> > >> ObservableValue or( > >> Supplier> supplier > >> ) > >> > >> I didn't implement this one in the PoC to keep it small, but I did > >> implement this in my JavaFX EventStream library before. > >> > >>> So it deals with both getting the wrapped value in null cases and with > >>> getting a "dynamic value" in null cases. I find the Optional-like > method > >>> 'T getOrElse(T defaultValue)' useful (along with others such as > >>> ifPresent because Optional is just useful for dealing with wrapped > >>> values). What I'm saying is that we should be careful with the names if > >>> we include both "constant" and "dynamic" versions of 'orElse'-like > >> methods. > >> > >> I think #ifPresent can be added, not so sure about the usefulness of > >> #getOrElse (see above). > >> > >>> The null check in ReactFX's #computeValue is > >>> actually checking the result of the mapping function, not whether > the > >>> function instance itself was null. > >>> > >>> I didn't mean the null-ness of the map argument. What I meant was that > >>> there is this implementation, which is similar to what ReactFX does: > >> > >> Sorry, I see it now. You have a good point, the current implementation > >> indeed wraps another Lambda to add the null check which could have been > >> done in #computeValue. I think it would be a good move to avoid the > >> extra lambda simply because the end result would be more readable -- any > >> performance improvement would be a bonus, I don't know if there will be > >> any. > >> > >>> As for my points 3 and 4, I'll have to try and play with the > >>> implementation myself, which will be easier to do when there is some PR > >>> in the works. > >> > >> Perhaps this is useful: > >> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx > >> > >> When you add this as a maven dependency to your project, you will get > >> the new PoC functionality. It basically uses the Maven shade plugin to > >> replace a few classes in javafx-base -- I use this sometimes to fix bugs > >> I need fixed immediately by patching jfx, but found it also works very > >> nicely to experiment with this PoC. > >> > >> Also, the PoC PR compiles fine, it may need rebasing. > >> > >>> To close "Bindings.select*(): add new type-safe template based API > >>> instead of legacy-style set of methods" we'd need the > flatMap/select > >>> method to be included. > >>> > >>> Yes. I think that we can include flatMap in this iteration, perhaps as > >>> a separate PR? > >> > >> That should be no problem, I can split it up. > >> > >>> I don't think we really need specialized methods for primitives (or > >> at > >>> least, not right away). At this point the primitive versions only > >>> really differ in what value they'd return if the binding would be > >> null > >>> and perhaps they do a little less boxing/unboxing. Since you can > >> select > >>> the default value with #orElse which is more flexible. I don't see > >> much > >>> use to add those variants. > >>> > >>> I agree, I would avoid bloating the primitive specialization classes > for > >>> now, especially when Valhalla is planned to take care of those. > >> > >> Yes, I think we can easily do without for now. > >> > >>> The ticket is a bit unclear as I can't see what type "x" is. > >>> > >>> Yes, but I got the impression that either way it can be solved with map > >>> (or flatMap). > >> > >> Agreed. > >> > >> --John > >> > > > From arapte at openjdk.java.net Tue Sep 21 11:06:53 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 21 Sep 2021 11:06:53 GMT Subject: RFR: 8090547: Allow for transparent backgrounds in WebView [v10] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 22:25:27 GMT, Jose Pereda wrote: >> Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. >> >> In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. >> >> The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. >> >> Unit tests and a system test are provided. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Use correct call to set composite mode when clearing quads and restore color looks good to me too. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/563 From fkirmaier at openjdk.java.net Tue Sep 21 11:25:46 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 21 Sep 2021 11:25:46 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v4] In-Reply-To: <_qrnVf27DezSXoUj2DOc3PxhzNXFyJyspVlI0L2qEqw=.82287feb-4c82-4ee2-aaf7-e0fecd356e7f@github.com> References: <_qrnVf27DezSXoUj2DOc3PxhzNXFyJyspVlI0L2qEqw=.82287feb-4c82-4ee2-aaf7-e0fecd356e7f@github.com> Message-ID: On Thu, 16 Sep 2021 13:22:32 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273485 > small cleanup of the changes. Thank you for searching the original reason for the nested event loop! I've now tested the class from the ticket, and for mit it works. The only strange thing is, that i get a "beep" sound when closing. Which isn't optimal but not the reported crash. Which is kinda unfortunate, because otherwise it might be easy to write a unit test. Did you test the latest version of the PR? I guess now i have to think of another fix, or on how do adapt this one. ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From kcr at openjdk.java.net Tue Sep 21 12:16:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Sep 2021 12:16:43 GMT Subject: RFR: 8090158: Wrong implementation of adjustValue in scrollBars [v2] In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 08:53:07 GMT, Hadzic Samir wrote: >> JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158) >> >> The javadoc of the ScrollBar#adjustValue specifically says that it will adjust the value based on the block increment value. Therefore, there is no reason to stop at the given value when reaching an end. > > Hadzic Samir has updated the pull request incrementally with one additional commit since the last revision: > > Fix upon review Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/582 From jpereda at openjdk.java.net Tue Sep 21 12:17:47 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 21 Sep 2021 12:17:47 GMT Subject: Integrated: 8090547: Allow for transparent backgrounds in WebView In-Reply-To: References: Message-ID: <7g9SyUi1GQQ-xDvAC2XEnVQn2OHzwkZjy0Go2n7TwwM=.19cdec98-9481-4f3d-ab55-bce74e62b7dd@github.com> On Fri, 2 Jul 2021 11:01:56 GMT, Jose Pereda wrote: > Currently, `WebPage` has already a public `setBackgroundColor()` method, but the class is not public. Therefore, public API is needed in `WebView` to allow developers access to it. > > In line with the `fontSmoothingType` property, this PR provides public support for setting the background color of a WebPage, by adding a `pageFill` property, and a CSR is required. > > The color for the background, that can be opaque, transparent or with any level of opacity, can be set via code or via CSS using `-fx-page-fill`. > > Unit tests and a system test are provided. This pull request has now been integrated. Changeset: f59a0573 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/f59a0573ca329e4ded0eab79a9e1d84967f5ccc4 Stats: 483 lines in 6 files changed: 465 ins; 2 del; 16 mod 8090547: Allow for transparent backgrounds in WebView Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/563 From kcr at openjdk.java.net Tue Sep 21 12:49:59 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 21 Sep 2021 12:49:59 GMT Subject: RFR: 8273946: Move clearQuad method to BaseShaderGraphics superclass Message-ID: As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and `ES2Graphics` are now identical, which should have been the case all along. The fact that they weren't identical was the source of a bug that was only discovered during the testing of [JDK-8090547](https://bugs.openjdk.java.net/browse/JDK-8090547) on the es2 pipeline. This PR moves the `clearQuad` method to the `BaseShaderGraphics` superclass to get rid of the unnecessary code duplication. This will be helpful when implementing the metal pipeline as well. As a note, I made the `context` field in the `D3DGraphics` final, which it should have been. This is necessary to ensure that moving the method to the super-class is equivalent. No new tests are needed, since this is just refactoring. ------------- Commit messages: - 8273946: Move clearQuad method to BaseShaderGraphics superclass Changes: https://git.openjdk.java.net/jfx/pull/628/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=628&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273946 Stats: 59 lines in 3 files changed: 18 ins; 40 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/628.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/628/head:pull/628 PR: https://git.openjdk.java.net/jfx/pull/628 From jpereda at openjdk.java.net Tue Sep 21 13:15:45 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 21 Sep 2021 13:15:45 GMT Subject: RFR: 8273946: Move clearQuad method to BaseShaderGraphics superclass In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 12:45:20 GMT, Kevin Rushforth wrote: > As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and `ES2Graphics` are now identical, which should have been the case all along. The fact that they weren't identical was the source of a bug that was only discovered during the testing of [JDK-8090547](https://bugs.openjdk.java.net/browse/JDK-8090547) on the es2 pipeline. > > This PR moves the `clearQuad` method to the `BaseShaderGraphics` superclass to get rid of the unnecessary code duplication. This will be helpful when implementing the metal pipeline as well. As a note, I made the `context` field in the `D3DGraphics` final, which it should have been. This is necessary to ensure that moving the method to the super-class is equivalent. > > No new tests are needed, since this is just refactoring. Looks good to me ------------- Marked as reviewed by jpereda (Committer). PR: https://git.openjdk.java.net/jfx/pull/628 From nlisker at openjdk.java.net Tue Sep 21 13:50:34 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Tue, 21 Sep 2021 13:50:34 GMT Subject: RFR: 8273946: Move clearQuad method to BaseShaderGraphics superclass In-Reply-To: References: Message-ID: <0XdK1goA6HCwkaEHRPVbsOyfVvXnqMgBGyRNqeL4FIk=.1d62b036-90b3-4375-9928-adab4bfc14ff@github.com> On Tue, 21 Sep 2021 12:45:20 GMT, Kevin Rushforth wrote: > As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and `ES2Graphics` are now identical, which should have been the case all along. The fact that they weren't identical was the source of a bug that was only discovered during the testing of [JDK-8090547](https://bugs.openjdk.java.net/browse/JDK-8090547) on the es2 pipeline. > > This PR moves the `clearQuad` method to the `BaseShaderGraphics` superclass to get rid of the unnecessary code duplication. This will be helpful when implementing the metal pipeline as well. As a note, I made the `context` field in the `D3DGraphics` final, which it should have been. This is necessary to ensure that moving the method to the super-class is equivalent. > > No new tests are needed, since this is just refactoring. Looks good. The tests pass. Two unrelated comments that I have observed during the review: 1. `java.security.AccessController` is deprecated for removal since 17. We need to do something about this. It's used in `BaseShaderGraphics`, which is where I saw the warning, but it's used in other places too. 2. Eclipse graciously informs me that "The method `D3DGraphics.getContext()` does not override the inherited method from `BaseShaderGraphics` since it is private to a different package". It detected the `@Override` annotation there and noted that the superclass method is not visible to this class since they are in different packages, so it is not actually overriding. This could lead to another subtle bug. Maybe that method should be protected. I didn't investigate much further. ------------- Marked as reviewed by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/628 From ebresie at gmail.com Tue Sep 21 17:02:05 2021 From: ebresie at gmail.com (Eric Bresie) Date: Tue, 21 Sep 2021 12:02:05 -0500 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: CA+0ynh9oja_NjW5__jYymWy51iAxO1SHUwT+w_LrqW2QjzyfUA@mail.gmail.com References: 19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl CA+0ynh8Zsw5B6tBQKxG7VzzrQEMj1-YLs1BaLxXyCRFOhY=LPw@mail.gmail.com 4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl CA+0ynh-fggF+JouWQ0X6HiJkqko2rcvHwfD0SD4ZYdKfNB=Yvg@mail.gmail.com 7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl CA+0ynh_jQ4COjtEyO8gr++E7mQD5Vakw9OabNe+QvnEDqFM66Q@mail.gmail.com a72fc186-7d16-1051-f0c2-cd742dcf2638@xs4all.nl CA+0ynh85m1GXePxmBZiK2Osfjyq+EF7dc3dRkg1aTK-AE18LLQ@mail.gmail.com 186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl CA+0ynh_b_Y76QR+5=2YLKq_9uEttC71C+dw2g34D6URnHw-k5Q@mail.gmail.com ca54edd4-fa6c-ac18-1151-c61a2ba2fdda@xs4all.nl CA+0ynh-wxTOhMx+=CNHM01kui3CHMzyGrfLOACYcNsXZpOc+Cw@mail.gmail.com a7614cfc-e828-0f7e-c6c9-21a05cea2b63@xs4all.nl a7614cfc-e828-0f7e-c6c9-21a05cea2b63@xs4all.nl Message-ID: <5c820017-f55d-4737-adce-6c2bc96c8399@Erics-iPhone-12-Pro-Max> I?m very much an Observer here ;-) but Given the comparisons with FX and React implementations, is there value in moving some of this out of here and into the JDK proper context making it potentially usable outside of fx or react circles? I?m reminded of old JDK workings when someone might be working a headless application needing a Swing dependency. Eric Bresie Ebresie at gmail.com (mailto:Ebresie at gmail.com) > On September 21, 2021 at 5:36:13 AM CDT, Nir Lisker wrote: > > > > The OrElseBinding is incorrect > > > > Yes, that was a typo with the order of the arguments in the ternary > statement. > > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I > > think the tests would become pretty unreadable and less useful / > > thourough otherwise). > > > > What are the options? > > > > This is a bigger question. Kevin will have to answer that. > > As for the subscription model: flat map has a more complicated one, but > > orElse, orElseGet and map all have the same one. > > > > From what I saw, ReactFX uses a different subscription model for these. I > could have misread it. > > The messages will need to be written from the perspective of the Binding > > class then IMHO. > > > > That's fine. > > As for the Optional methods, I'll have a look in my code base and see if > the places I would like to use them at will become irrelevant anyway with > the fluent bindings. I'm fine with proceeding with the current names of the > proposed methods. > > On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx wrote: > > > I need to get you the tests I wrote, unfortunately, they're JUnit 5, > > please see the tests here: > > > > > > https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value > > > > The OrElseBinding is incorrect, the compute value should read: > > > > protected T computeValue() { > > T value = source.getValue(); > > return value == null ? constant : value; > > } > > > > Similar for OrElseGetBinding. > > > > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I > > think the tests would become pretty unreadable and less useful / > > thourough otherwise). > > > > What are the options? > > > > - Integrate a nested runner (there is an Apache 2.0 licensed one available) > > - Create our own nested runner (about 200 lines of code) > > - Can we introduce JUnit 5? > > - Rewrite to plain JUnit 4? > > > > Let me know, and I can integrate them. > > > > --John > > > > On 19/09/2021 02:12, Nir Lisker wrote: > > > I've played around with the implementation and pushed a modified > > > prototype to the sandbox [1]. I ended up with something similar to > > ReactFX: > > > the orElse and orElseGet methods have their own binding classes that > > > extend LazyObjectBinding, just like MapBinding and FlatMapBinding. The > > > reason being that both their compute value and their subscription models > > > are slightly different. While they can be matched to MapBinding like you > > > did, it entails a bit of a roundabout way in my opinion. Creating a > > > supplier for the constant value of orElse somewhat defeats the purpose I > > > think. > > > > I have no strong opinion here, just wanted to keep the MR small. The > > supplier should be an inline candidate, but creating a separate class is > > fine too. > > > > As for the subscription model: flat map has a more complicated one, but > > orElse, orElseGet and map all have the same one. > > > > > In addition, I think that it's fine to move the arguments' null checks to > > > the binding classes themselves, even if it's a couple of levels deeper on > > > the stack, while adding a message in the 2nd argument of > > > Objects.requireNonNull for clarity. These classes are "self-contained" so > > > it makes sense for them to check their arguments. They might be used in > > > other places, perhaps in the public Bindings class. > > > > The messages will need to be written from the perspective of the Binding > > class then IMHO. > > > > > I also moved the subscription-related methods from ObservableValue to > > > static methods in Subscription, at least for now, to defer the API > > related > > > to Subscription. > > > > Sounds good. > > > > > The branch doesn't compile because I didn't finish working on the > > > visibility issue, but it's close enough to what I envision it like for > > the > > > first PR. > > > > I've ported the changes over to my branch and ran the tests on it, they > > all pass apart from the above mentioned problem in the OrElse bindings. > > > > > As for the java,util.Optional methods, I indeed did something like > > > `x.orElse(5).getValue()` in the past in other cases, but this approach > > > creates a new binding just to get the wrapped value out, which is very > > > inefficient. (In one case I did booleanValue.isNull().get(), which > > creates > > > a boolean binding, because isPresent() does not exist). I would like to > > see > > > what others think about the Optional methods, The binding method variants > > > are much more important, but I want to avoid a name clash if the Optional > > > ones will have support. > > > > Okay, some more things to consider: > > > > ObservableValue is not an Optional, their get methods respond > > differently with Optional#get throwing an exception when null -- the > > #orElse is a necessity; this is not the case for ObservableValue#getValue. > > > > When creating mapping chains, you are going to do this because you want > > to bind this to another property or to listen on it (with subscribe). > > You don't want to do this as a one time thing. If you are creating a > > chain just to calculate a value you can just do this directly. Instead of: > > > > widthProperty().map(x -> x * 2).getValue() > > > > You'd do: > > > > getWidth() * 2; > > > > With flat mapping however this is not as easy: > > > > [1] > > node.sceneProperty() > > .flatMap(Scene::windowProperty) > > .flatMap(Window::showingProperty) > > .orElse(false); > > > > You could try: > > > > node.getScene().getWindow().isShowing(); > > > > But that will not work when Scene or Window is null. You'd have to > > write it as: > > > > [2] > > Optional.ofNullable(node.getScene()) > > .map(Scene::getWindow) > > .map(Window::isShowing) > > .orElse(false); > > > > If you only offer a "specialized" orElse, you'd still need to create > > several bindings: > > > > [3] > > node.sceneProperty() > > .flatMap(Scene::windowProperty) > > .flatMap(Window::showingProperty) > > .orElse2(false); // orElse which returns a value not a binding > > > > If you compare [2] (which is possible now) with [3] the difference is > > minimal. A bit more ceremony at the start for [2] but a shorter, cleaner > > and faster mapping (no bindings and no need to use the property methods). > > > > Now, if you already HAVE the binding for some other purpose, then it is > > highly likely it also already has an #orElse that is needed as part of > > the binding. In that case calling #getValue is fine without much need > > for another #orElse variant. > > > > --John > > > > > > > > [1] > > > > > https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings > > > > > > On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx wrote: > > > > > > > > > > > > > > > On 15/09/2021 02:28, Nir Lisker wrote: > > > > > Sorry, I'm not quite sure what you mean by this. Could you > > elaborate? > > > > > The methods orElse and orElseGet are present in the PoC, and I > > think > > > > > they're highly useful to have to deal with nulls. > > > > > > > > > > > > > > > The methods that you call orElse and orElseGet return an > > > > > ObservableValue. The Optional methods with the same names return the > > > > > wrapped value (of type T). For comparison, ReactFX has: > > > > > T getOrElse(T defaultValue) > > > > > T getOrSupply(Supplier defaultSupplier) > > > > > Val orElseConst(T other) > > > > > Val orElse(ObservableValue other) > > > > > > > > I see what you mean now. The methods from java.util.Optional will return > > > > an unwrapped value, while the ones from ObservableValue in the PoC > > > > return an ObservableValue, but they have the same name. > > > > > > > > So java.util.Optional offers: > > > > > > > > T orElse(T other) > > > > T orElseGet(Supplier supplier) > > > > > > > > And the PoC: > > > > > > > > ObservableValue orElse(T alternativeValue) > > > > ObservableValue orElseGet(Supplier supplier) > > > > > > > > The main difference is in the returned types. Personally, I think it is > > > > rarely useful for a binding to be queried directly and I've never used > > > > the #getOrElse or #getOrSupply variants that ReactFX offers. On top of > > > > that: > > > > > > > > x.orElse(5).getValue() === x.getOrElse(5) > > > > > > > > So it introduces another method in the interface to avoid having to > > > > write ".getValue()". The opposite, introducing only the "unwrapped" > > > > variants would still require the "wrapped" variants to be present as > > well. > > > > > > > > So, what I would suggest is to not add variants for #getOrElse and > > > > #getOrSupply at all as they are of questionable value and would just > > > > bloat the API for a bit less typing. In that case I think we can still > > > > use the signatures as they are. > > > > > > > > ReactFX also offers: > > > > > > > > Val orElse(ObservableValue other) > > > > > > > > This is another rarely used feature IMHO, and I think Optional#or would > > > > a better match for this functionality: > > > > > > > > Optional or(Supplier> supplier) > > > > > > > > In the POC the signature would be: > > > > > > > > ObservableValue or( > > > > Supplier> supplier > > > > ) > > > > > > > > I didn't implement this one in the PoC to keep it small, but I did > > > > implement this in my JavaFX EventStream library before. > > > > > > > > > So it deals with both getting the wrapped value in null cases and with > > > > > getting a "dynamic value" in null cases. I find the Optional-like > > method > > > > > 'T getOrElse(T defaultValue)' useful (along with others such as > > > > > ifPresent because Optional is just useful for dealing with wrapped > > > > > values). What I'm saying is that we should be careful with the names if > > > > > we include both "constant" and "dynamic" versions of 'orElse'-like > > > > methods. > > > > > > > > I think #ifPresent can be added, not so sure about the usefulness of > > > > #getOrElse (see above). > > > > > > > > > The null check in ReactFX's #computeValue is > > > > > actually checking the result of the mapping function, not whether > > the > > > > > function instance itself was null. > > > > > > > > > > I didn't mean the null-ness of the map argument. What I meant was that > > > > > there is this implementation, which is similar to what ReactFX does: > > > > > > > > Sorry, I see it now. You have a good point, the current implementation > > > > indeed wraps another Lambda to add the null check which could have been > > > > done in #computeValue. I think it would be a good move to avoid the > > > > extra lambda simply because the end result would be more readable -- any > > > > performance improvement would be a bonus, I don't know if there will be > > > > any. > > > > > > > > > As for my points 3 and 4, I'll have to try and play with the > > > > > implementation myself, which will be easier to do when there is some PR > > > > > in the works. > > > > > > > > Perhaps this is useful: > > > > https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx > > > > > > > > When you add this as a maven dependency to your project, you will get > > > > the new PoC functionality. It basically uses the Maven shade plugin to > > > > replace a few classes in javafx-base -- I use this sometimes to fix bugs > > > > I need fixed immediately by patching jfx, but found it also works very > > > > nicely to experiment with this PoC. > > > > > > > > Also, the PoC PR compiles fine, it may need rebasing. > > > > > > > > > To close "Bindings.select*(): add new type-safe template based API > > > > > instead of legacy-style set of methods" we'd need the > > flatMap/select > > > > > method to be included. > > > > > > > > > > Yes. I think that we can include flatMap in this iteration, perhaps as > > > > > a separate PR? > > > > > > > > That should be no problem, I can split it up. > > > > > > > > > I don't think we really need specialized methods for primitives (or > > > > at > > > > > least, not right away). At this point the primitive versions only > > > > > really differ in what value they'd return if the binding would be > > > > null > > > > > and perhaps they do a little less boxing/unboxing. Since you can > > > > select > > > > > the default value with #orElse which is more flexible. I don't see > > > > much > > > > > use to add those variants. > > > > > > > > > > I agree, I would avoid bloating the primitive specialization classes > > for > > > > > now, especially when Valhalla is planned to take care of those. > > > > > > > > Yes, I think we can easily do without for now. > > > > > > > > > The ticket is a bit unclear as I can't see what type "x" is. > > > > > > > > > > Yes, but I got the impression that either way it can be solved with map > > > > > (or flatMap). > > > > > > > > Agreed. > > > > > > > > --John > > > > > > > > > From nlisker at gmail.com Tue Sep 21 17:27:00 2021 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 21 Sep 2021 20:27:00 +0300 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: <5c820017-f55d-4737-adce-6c2bc96c8399@Erics-iPhone-12-Pro-Max> References: <5c820017-f55d-4737-adce-6c2bc96c8399@Erics-iPhone-12-Pro-Max> Message-ID: I'm not sure what you're proposing. Move what, to where, and for what use? On Tue, Sep 21, 2021 at 8:02 PM Eric Bresie wrote: > I?m very much an Observer here ;-) but > > Given the comparisons with FX and React implementations, is there value in > moving some of this out of here and into the JDK proper context making it > potentially usable outside of fx or react circles? > > I?m reminded of old JDK workings when someone might be working a headless > application needing a Swing dependency. > > Eric Bresie > Ebresie at gmail.com (mailto:Ebresie at gmail.com) > > > On September 21, 2021 at 5:36:13 AM CDT, Nir Lisker (mailto:nlisker at gmail.com)> wrote: > > > > > > The OrElseBinding is incorrect > > > > > > > Yes, that was a typo with the order of the arguments in the ternary > > statement. > > > > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I > > > think the tests would become pretty unreadable and less useful / > > > thourough otherwise). > > > > > > What are the options? > > > > > > > This is a bigger question. Kevin will have to answer that. > > > > As for the subscription model: flat map has a more complicated one, but > > > orElse, orElseGet and map all have the same one. > > > > > > > From what I saw, ReactFX uses a different subscription model for these. I > > could have misread it. > > > > The messages will need to be written from the perspective of the Binding > > > class then IMHO. > > > > > > > That's fine. > > > > As for the Optional methods, I'll have a look in my code base and see if > > the places I would like to use them at will become irrelevant anyway with > > the fluent bindings. I'm fine with proceeding with the current names of > the > > proposed methods. > > > > On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx hjohn at xs4all.nl)> wrote: > > > > > I need to get you the tests I wrote, unfortunately, they're JUnit 5, > > > please see the tests here: > > > > > > > > > > https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value > > > > > > The OrElseBinding is incorrect, the compute value should read: > > > > > > protected T computeValue() { > > > T value = source.getValue(); > > > return value == null ? constant : value; > > > } > > > > > > Similar for OrElseGetBinding. > > > > > > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I > > > think the tests would become pretty unreadable and less useful / > > > thourough otherwise). > > > > > > What are the options? > > > > > > - Integrate a nested runner (there is an Apache 2.0 licensed one > available) > > > - Create our own nested runner (about 200 lines of code) > > > - Can we introduce JUnit 5? > > > - Rewrite to plain JUnit 4? > > > > > > Let me know, and I can integrate them. > > > > > > --John > > > > > > On 19/09/2021 02:12, Nir Lisker wrote: > > > > I've played around with the implementation and pushed a modified > > > > prototype to the sandbox [1]. I ended up with something similar to > > > ReactFX: > > > > the orElse and orElseGet methods have their own binding classes that > > > > extend LazyObjectBinding, just like MapBinding and FlatMapBinding. > The > > > > reason being that both their compute value and their subscription > models > > > > are slightly different. While they can be matched to MapBinding like > you > > > > did, it entails a bit of a roundabout way in my opinion. Creating a > > > > supplier for the constant value of orElse somewhat defeats the > purpose I > > > > think. > > > > > > I have no strong opinion here, just wanted to keep the MR small. The > > > supplier should be an inline candidate, but creating a separate class > is > > > fine too. > > > > > > As for the subscription model: flat map has a more complicated one, but > > > orElse, orElseGet and map all have the same one. > > > > > > > In addition, I think that it's fine to move the arguments' null > checks to > > > > the binding classes themselves, even if it's a couple of levels > deeper on > > > > the stack, while adding a message in the 2nd argument of > > > > Objects.requireNonNull for clarity. These classes are > "self-contained" so > > > > it makes sense for them to check their arguments. They might be used > in > > > > other places, perhaps in the public Bindings class. > > > > > > The messages will need to be written from the perspective of the > Binding > > > class then IMHO. > > > > > > > I also moved the subscription-related methods from ObservableValue to > > > > static methods in Subscription, at least for now, to defer the API > > > related > > > > to Subscription. > > > > > > Sounds good. > > > > > > > The branch doesn't compile because I didn't finish working on the > > > > visibility issue, but it's close enough to what I envision it like > for > > > the > > > > first PR. > > > > > > I've ported the changes over to my branch and ran the tests on it, they > > > all pass apart from the above mentioned problem in the OrElse bindings. > > > > > > > As for the java,util.Optional methods, I indeed did something like > > > > `x.orElse(5).getValue()` in the past in other cases, but this > approach > > > > creates a new binding just to get the wrapped value out, which is > very > > > > inefficient. (In one case I did booleanValue.isNull().get(), which > > > creates > > > > a boolean binding, because isPresent() does not exist). I would like > to > > > see > > > > what others think about the Optional methods, The binding method > variants > > > > are much more important, but I want to avoid a name clash if the > Optional > > > > ones will have support. > > > > > > Okay, some more things to consider: > > > > > > ObservableValue is not an Optional, their get methods respond > > > differently with Optional#get throwing an exception when null -- the > > > #orElse is a necessity; this is not the case for > ObservableValue#getValue. > > > > > > When creating mapping chains, you are going to do this because you want > > > to bind this to another property or to listen on it (with subscribe). > > > You don't want to do this as a one time thing. If you are creating a > > > chain just to calculate a value you can just do this directly. Instead > of: > > > > > > widthProperty().map(x -> x * 2).getValue() > > > > > > You'd do: > > > > > > getWidth() * 2; > > > > > > With flat mapping however this is not as easy: > > > > > > [1] > > > node.sceneProperty() > > > .flatMap(Scene::windowProperty) > > > .flatMap(Window::showingProperty) > > > .orElse(false); > > > > > > You could try: > > > > > > node.getScene().getWindow().isShowing(); > > > > > > But that will not work when Scene or Window is null. You'd have to > > > write it as: > > > > > > [2] > > > Optional.ofNullable(node.getScene()) > > > .map(Scene::getWindow) > > > .map(Window::isShowing) > > > .orElse(false); > > > > > > If you only offer a "specialized" orElse, you'd still need to create > > > several bindings: > > > > > > [3] > > > node.sceneProperty() > > > .flatMap(Scene::windowProperty) > > > .flatMap(Window::showingProperty) > > > .orElse2(false); // orElse which returns a value not a binding > > > > > > If you compare [2] (which is possible now) with [3] the difference is > > > minimal. A bit more ceremony at the start for [2] but a shorter, > cleaner > > > and faster mapping (no bindings and no need to use the property > methods). > > > > > > Now, if you already HAVE the binding for some other purpose, then it is > > > highly likely it also already has an #orElse that is needed as part of > > > the binding. In that case calling #getValue is fine without much need > > > for another #orElse variant. > > > > > > --John > > > > > > > > > > > [1] > > > > > > > > https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings > > > > > > > > On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx (mailto:hjohn at xs4all.nl)> wrote: > > > > > > > > > > > > > > > > > > > On 15/09/2021 02:28, Nir Lisker wrote: > > > > > > Sorry, I'm not quite sure what you mean by this. Could you > > > elaborate? > > > > > > The methods orElse and orElseGet are present in the PoC, and I > > > think > > > > > > they're highly useful to have to deal with nulls. > > > > > > > > > > > > > > > > > > The methods that you call orElse and orElseGet return an > > > > > > ObservableValue. The Optional methods with the same names > return the > > > > > > wrapped value (of type T). For comparison, ReactFX has: > > > > > > T getOrElse(T defaultValue) > > > > > > T getOrSupply(Supplier defaultSupplier) > > > > > > Val orElseConst(T other) > > > > > > Val orElse(ObservableValue other) > > > > > > > > > > I see what you mean now. The methods from java.util.Optional will > return > > > > > an unwrapped value, while the ones from ObservableValue in the PoC > > > > > return an ObservableValue, but they have the same name. > > > > > > > > > > So java.util.Optional offers: > > > > > > > > > > T orElse(T other) > > > > > T orElseGet(Supplier supplier) > > > > > > > > > > And the PoC: > > > > > > > > > > ObservableValue orElse(T alternativeValue) > > > > > ObservableValue orElseGet(Supplier supplier) > > > > > > > > > > The main difference is in the returned types. Personally, I think > it is > > > > > rarely useful for a binding to be queried directly and I've never > used > > > > > the #getOrElse or #getOrSupply variants that ReactFX offers. On > top of > > > > > that: > > > > > > > > > > x.orElse(5).getValue() === x.getOrElse(5) > > > > > > > > > > So it introduces another method in the interface to avoid having to > > > > > write ".getValue()". The opposite, introducing only the "unwrapped" > > > > > variants would still require the "wrapped" variants to be present > as > > > well. > > > > > > > > > > So, what I would suggest is to not add variants for #getOrElse and > > > > > #getOrSupply at all as they are of questionable value and would > just > > > > > bloat the API for a bit less typing. In that case I think we can > still > > > > > use the signatures as they are. > > > > > > > > > > ReactFX also offers: > > > > > > > > > > Val orElse(ObservableValue other) > > > > > > > > > > This is another rarely used feature IMHO, and I think Optional#or > would > > > > > a better match for this functionality: > > > > > > > > > > Optional or(Supplier> supplier) > > > > > > > > > > In the POC the signature would be: > > > > > > > > > > ObservableValue or( > > > > > Supplier> supplier > > > > > ) > > > > > > > > > > I didn't implement this one in the PoC to keep it small, but I did > > > > > implement this in my JavaFX EventStream library before. > > > > > > > > > > > So it deals with both getting the wrapped value in null cases > and with > > > > > > getting a "dynamic value" in null cases. I find the Optional-like > > > method > > > > > > 'T getOrElse(T defaultValue)' useful (along with others such as > > > > > > ifPresent because Optional is just useful for dealing with > wrapped > > > > > > values). What I'm saying is that we should be careful with the > names if > > > > > > we include both "constant" and "dynamic" versions of > 'orElse'-like > > > > > methods. > > > > > > > > > > I think #ifPresent can be added, not so sure about the usefulness > of > > > > > #getOrElse (see above). > > > > > > > > > > > The null check in ReactFX's #computeValue is > > > > > > actually checking the result of the mapping function, not whether > > > the > > > > > > function instance itself was null. > > > > > > > > > > > > I didn't mean the null-ness of the map argument. What I meant > was that > > > > > > there is this implementation, which is similar to what ReactFX > does: > > > > > > > > > > Sorry, I see it now. You have a good point, the current > implementation > > > > > indeed wraps another Lambda to add the null check which could have > been > > > > > done in #computeValue. I think it would be a good move to avoid the > > > > > extra lambda simply because the end result would be more readable > -- any > > > > > performance improvement would be a bonus, I don't know if there > will be > > > > > any. > > > > > > > > > > > As for my points 3 and 4, I'll have to try and play with the > > > > > > implementation myself, which will be easier to do when there is > some PR > > > > > > in the works. > > > > > > > > > > Perhaps this is useful: > > > > > > https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx > > > > > > > > > > When you add this as a maven dependency to your project, you will > get > > > > > the new PoC functionality. It basically uses the Maven shade > plugin to > > > > > replace a few classes in javafx-base -- I use this sometimes to > fix bugs > > > > > I need fixed immediately by patching jfx, but found it also works > very > > > > > nicely to experiment with this PoC. > > > > > > > > > > Also, the PoC PR compiles fine, it may need rebasing. > > > > > > > > > > > To close "Bindings.select*(): add new type-safe template based > API > > > > > > instead of legacy-style set of methods" we'd need the > > > flatMap/select > > > > > > method to be included. > > > > > > > > > > > > Yes. I think that we can include flatMap in this iteration, > perhaps as > > > > > > a separate PR? > > > > > > > > > > That should be no problem, I can split it up. > > > > > > > > > > > I don't think we really need specialized methods for primitives > (or > > > > > at > > > > > > least, not right away). At this point the primitive versions only > > > > > > really differ in what value they'd return if the binding would be > > > > > null > > > > > > and perhaps they do a little less boxing/unboxing. Since you can > > > > > select > > > > > > the default value with #orElse which is more flexible. I don't > see > > > > > much > > > > > > use to add those variants. > > > > > > > > > > > > I agree, I would avoid bloating the primitive specialization > classes > > > for > > > > > > now, especially when Valhalla is planned to take care of those. > > > > > > > > > > Yes, I think we can easily do without for now. > > > > > > > > > > > The ticket is a bit unclear as I can't see what type "x" is. > > > > > > > > > > > > Yes, but I got the impression that either way it can be solved > with map > > > > > > (or flatMap). > > > > > > > > > > Agreed. > > > > > > > > > > --John > > > > > > > > > > > > > From tsayao at openjdk.java.net Tue Sep 21 21:18:56 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 21 Sep 2021 21:18:56 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao wrote: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. Docs states: /* * When a user tries to activate a disabled window, or the window gets * accidentally brought to the top of the stacking order, the window * generates the FOCUS_DISABLED window event. A Glass client should react * to this event and bring the currently active modal blocker of the * disabled window to top by calling blocker's minimize(false), toFront(), * and requestFocus() methods. It may also 'blink' the blocker window to * further attract user's attention. */ But `WindowStage.java` actually does: final void handleFocusDisabled() { if (activeWindows.isEmpty()) { return; } WindowStage window = activeWindows.get(activeWindows.size() - 1); window.setIconified(false); window.requestToFront(); window.requestFocus(); } It brings up current activeWindows.size() - 1, not actually the MODAL blocker. Seems wrong to me. The event is born on `glass_window.cpp`: ```c++ mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); The current proposed code (which I will redo) blocks this line from being sent (on non-virtual machines apparently). But commenting the `jWindowNotifyFocusDisabled` should make the problem disappear (just to test the theory). ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From tsayao at openjdk.java.net Tue Sep 21 21:33:44 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 21 Sep 2021 21:33:44 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v2] In-Reply-To: References: Message-ID: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: handleFocusDisabled() should bring up the blocker window not the previous one. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/598/files - new: https://git.openjdk.java.net/jfx/pull/598/files/3770f101..850cfc8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=00-01 Stats: 16 lines in 2 files changed: 10 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/598.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598 PR: https://git.openjdk.java.net/jfx/pull/598 From tsayao at openjdk.java.net Tue Sep 21 21:33:45 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 21 Sep 2021 21:33:45 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation In-Reply-To: References: Message-ID: On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao wrote: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. I have proposed a different fix, but it might have concurrency issues and probably others that should be investigated. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From fkirmaier at openjdk.java.net Wed Sep 22 10:18:12 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 22 Sep 2021 10:18:12 GMT Subject: RFR: 8273969: Memory Leak on the Runnable provided to Platform.startup [v2] In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 12:56:39 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8273969 >> Some changes based on code review > > tests/system/src/test/java/test/javafx/scene/PlatformStartupMemoryLeakTest.java line 26: > >> 24: */ >> 25: >> 26: package test.javafx.scene; > > Similar tests are in the `test.com.sun.javafx.application` package, so I recommend putting this test there. done > tests/system/src/test/java/test/javafx/scene/PlatformStartupMemoryLeakTest.java line 34: > >> 32: public class PlatformStartupMemoryLeakTest { >> 33: >> 34: @Test > > Since this test calls `Platform::startup`, this class must only have a single `@Test` method. I recommend adding a comment to that effect, so that someone doesn't try to add a second test method later. I think that's redundant after moving it to the application package. In the application package, most of the test classes only have 1 test for this reason. > tests/system/src/test/java/test/javafx/scene/PlatformStartupMemoryLeakTest.java line 37: > >> 35: public void testStartupLeak() { >> 36: JMemoryBuddy.memoryTest((checker) -> { >> 37: // Doesn't work as lambda for some reason, due to "BoundMethodHandle$Species_L" > > Based on Tom's comment, and also my reading of the spec, this is expected (if somewhat counter-intuitive), so please modify this comment to indicate that the `Runnable` must not be turned into a lambda. done > tests/system/src/test/java/test/javafx/scene/PlatformStartupMemoryLeakTest.java line 47: > >> 45: checker.assertCollectable(r); >> 46: }); >> 47: } > > I recommend adding an `@After` (or `@AfterClass`) cleanup method that calls `Platform::exit`. done ------------- PR: https://git.openjdk.java.net/jfx/pull/626 From fkirmaier at openjdk.java.net Wed Sep 22 10:18:09 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 22 Sep 2021 10:18:09 GMT Subject: RFR: 8273969: Memory Leak on the Runnable provided to Platform.startup [v2] In-Reply-To: References: Message-ID: <8tLEKvzhJj4CBZHQrC67F_NwkDYSPKQ53wv-Il1ruMY=.419c8ff2-2818-405a-ae4e-be54519ce9e6@github.com> > Probably my most boring PR. ;) > Setting the lambda to null, after it has been used, fixes the leak. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8273969 Some changes based on code review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/626/files - new: https://git.openjdk.java.net/jfx/pull/626/files/7897fd64..9620ed5e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=626&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=626&range=00-01 Stats: 103 lines in 2 files changed: 55 ins; 48 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/626.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/626/head:pull/626 PR: https://git.openjdk.java.net/jfx/pull/626 From shadzic at openjdk.java.net Wed Sep 22 12:16:54 2021 From: shadzic at openjdk.java.net (Hadzic Samir) Date: Wed, 22 Sep 2021 12:16:54 GMT Subject: Integrated: 8090158: Wrong implementation of adjustValue in scrollBars In-Reply-To: References: Message-ID: On Tue, 20 Jul 2021 09:12:05 GMT, Hadzic Samir wrote: > JBS bug: [JDK-8090158](https://bugs.openjdk.java.net/browse/JDK-8090158) > > The javadoc of the ScrollBar#adjustValue specifically says that it will adjust the value based on the block increment value. Therefore, there is no reason to stop at the given value when reaching an end. This pull request has now been integrated. Changeset: 5c355fa2 Author: Hadzic Samir Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/5c355fa231e862a9db9b524cf14715066df142f5 Stats: 32 lines in 2 files changed: 28 ins; 3 del; 1 mod 8090158: Wrong implementation of adjustValue in scrollBars Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/582 From kcr at openjdk.java.net Wed Sep 22 12:28:53 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Sep 2021 12:28:53 GMT Subject: RFR: 8273969: Memory Leak on the Runnable provided to Platform.startup [v2] In-Reply-To: <8tLEKvzhJj4CBZHQrC67F_NwkDYSPKQ53wv-Il1ruMY=.419c8ff2-2818-405a-ae4e-be54519ce9e6@github.com> References: <8tLEKvzhJj4CBZHQrC67F_NwkDYSPKQ53wv-Il1ruMY=.419c8ff2-2818-405a-ae4e-be54519ce9e6@github.com> Message-ID: <2klWvgUFIlqIdhAzmE_t0et189_y2TGWq-NzP3aVLrs=.6b209682-4ec9-4b57-b6b9-5d0e6bdd39f9@github.com> On Wed, 22 Sep 2021 10:18:09 GMT, Florian Kirmaier wrote: >> Probably my most boring PR. ;) >> Setting the lambda to null, after it has been used, fixes the leak. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273969 > Some changes based on code review Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/626 From kcr at openjdk.java.net Wed Sep 22 12:52:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Sep 2021 12:52:00 GMT Subject: RFR: 8273946: Move clearQuad method to BaseShaderGraphics superclass In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 12:45:20 GMT, Kevin Rushforth wrote: > As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and `ES2Graphics` are now identical, which should have been the case all along. The fact that they weren't identical was the source of a bug that was only discovered during the testing of [JDK-8090547](https://bugs.openjdk.java.net/browse/JDK-8090547) on the es2 pipeline. > > This PR moves the `clearQuad` method to the `BaseShaderGraphics` superclass to get rid of the unnecessary code duplication. This will be helpful when implementing the metal pipeline as well. As a note, I made the `context` field in the `D3DGraphics` final, which it should have been. This is necessary to ensure that moving the method to the super-class is equivalent. > > No new tests are needed, since this is just refactoring. Thanks for the review. > Two unrelated comments that I have observed during the review: > > 1. `java.security.AccessController` is deprecated for removal since 17. We need to do something about this. It's used in `BaseShaderGraphics`, which is where I saw the warning, but it's used in other places too. We added `@SuppressWarnings("removal")` annotations for [JDK-8264139](https://bugs.openjdk.java.net/browse/JDK-8264139), so I'm surprised the IDE is still flagging it. FWIW, it will be several years before we can remove any of these calls, since running with a security manager is still supported in JDK 17 LTS. > 2. Eclipse graciously informs me that "The method `D3DGraphics.getContext()` does not override the inherited method from `BaseShaderGraphics` since it is private to a different package". It detected the `@Override` annotation there and noted that the superclass method is not visible to this class since they are in different packages, so it is not actually overriding. This could lead to another subtle bug. Maybe that method should be protected. I didn't investigate much further. Interesting. I guess the only reason the IDE is warning in this case is that it notices the `@Override` annotation, which is there because it implements the method in D3DGraphicsContextSource, and warns that it doesn't override the method of the same name in the superclass. We could consider a follow-up issue to clean this up, but I'm not really inclined to change anything. ------------- PR: https://git.openjdk.java.net/jfx/pull/628 From kcr at openjdk.java.net Wed Sep 22 13:50:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Sep 2021 13:50:57 GMT Subject: Integrated: 8273946: Move clearQuad method to BaseShaderGraphics superclass In-Reply-To: References: Message-ID: <9ikMgKUSgMluCxcWLp1pUNIfo56uQubp1OHkQ1If-vA=.a2f9d99c-3d0a-49cc-a3d1-7ac705c69e0e@github.com> On Tue, 21 Sep 2021 12:45:20 GMT, Kevin Rushforth wrote: > As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and `ES2Graphics` are now identical, which should have been the case all along. The fact that they weren't identical was the source of a bug that was only discovered during the testing of [JDK-8090547](https://bugs.openjdk.java.net/browse/JDK-8090547) on the es2 pipeline. > > This PR moves the `clearQuad` method to the `BaseShaderGraphics` superclass to get rid of the unnecessary code duplication. This will be helpful when implementing the metal pipeline as well. As a note, I made the `context` field in the `D3DGraphics` final, which it should have been. This is necessary to ensure that moving the method to the super-class is equivalent. > > No new tests are needed, since this is just refactoring. This pull request has now been integrated. Changeset: 338b9994 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/338b999414ed5dc8fea19c12bd3e656fd9cab6f4 Stats: 59 lines in 3 files changed: 18 ins; 40 del; 1 mod 8273946: Move clearQuad method to BaseShaderGraphics superclass Reviewed-by: jpereda, nlisker ------------- PR: https://git.openjdk.java.net/jfx/pull/628 From nlisker at openjdk.java.net Wed Sep 22 14:02:57 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 22 Sep 2021 14:02:57 GMT Subject: RFR: 8273946: Move clearQuad method to BaseShaderGraphics superclass In-Reply-To: References: Message-ID: <1JhwCdFFMxCIzxQUM9iWe87l7MxGGEvauAefJVWv0IM=.9055d60c-30ad-4f93-b33f-9a5f749318fe@github.com> On Tue, 21 Sep 2021 12:45:20 GMT, Kevin Rushforth wrote: > As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and `ES2Graphics` are now identical, which should have been the case all along. The fact that they weren't identical was the source of a bug that was only discovered during the testing of [JDK-8090547](https://bugs.openjdk.java.net/browse/JDK-8090547) on the es2 pipeline. > > This PR moves the `clearQuad` method to the `BaseShaderGraphics` superclass to get rid of the unnecessary code duplication. This will be helpful when implementing the metal pipeline as well. As a note, I made the `context` field in the `D3DGraphics` final, which it should have been. This is necessary to ensure that moving the method to the super-class is equivalent. > > No new tests are needed, since this is just refactoring. > We added `@SuppressWarnings("removal")` annotations for JDK-8264139, so I'm surprised the IDE is still flagging it. The warning is on the `import` of the class, which can be suppressed by adding the annotation to the class declaration. Maybe it's only this way in the Eclipse compiler. > We could consider a follow-up issue to clean this up, but I'm not really inclined to change anything. The question is if this can cause any bugs? Is the method supposed to override? If yes and it isn't, it sounds like something could go wrong. ------------- PR: https://git.openjdk.java.net/jfx/pull/628 From github.com+85555697+andreas-heger at openjdk.java.net Wed Sep 22 14:27:56 2021 From: github.com+85555697+andreas-heger at openjdk.java.net (Andreas Heger) Date: Wed, 22 Sep 2021 14:27:56 GMT Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight In-Reply-To: References: Message-ID: On Mon, 20 Sep 2021 14:11:50 GMT, Kevin Rushforth wrote: >> @kevinrushforth >>> The fix looks good. I tested it both in isolation and with PR #334 and it works on both a retina and non-retina display. >>> >>> If you have time to write an automated test, that would be useful, but if not then a manual test would be OK. >> >> Ok, I will try to write an automated test case which draws a sphere in a SubScene and then calculates the average color of the generated image. The test will be passed if the calculated average does not differ from the excepted average color by a certain tolerance value. I'm not sure if I will manage to do this... but I will give it a try. > > @andreas-heger are you able to come up with an automated test for this bug? @kevinrushforth yes, I still want to write an automated test for this bug. Sorry for the delay... I plan to do it within the next two weeks. ------------- PR: https://git.openjdk.java.net/jfx/pull/531 From kcr at openjdk.java.net Wed Sep 22 15:22:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 22 Sep 2021 15:22:56 GMT Subject: RFR: 8273946: Move clearQuad method to BaseShaderGraphics superclass In-Reply-To: <1JhwCdFFMxCIzxQUM9iWe87l7MxGGEvauAefJVWv0IM=.9055d60c-30ad-4f93-b33f-9a5f749318fe@github.com> References: <1JhwCdFFMxCIzxQUM9iWe87l7MxGGEvauAefJVWv0IM=.9055d60c-30ad-4f93-b33f-9a5f749318fe@github.com> Message-ID: <8Ir2-CLvkeEBhe1klkr8VJvNxoEeMP1iSJGfx6jBpaY=.4e28fd4d-3888-4c44-ab6b-1fc2d46b9187@github.com> On Wed, 22 Sep 2021 13:59:43 GMT, Nir Lisker wrote: > > We added `@SuppressWarnings("removal")` annotations for JDK-8264139, so I'm surprised the IDE is still flagging it. > > The warning is on the `import` of the class, which can be suppressed by adding the annotation to the class declaration. Maybe it's only this way in the Eclipse compiler. This sounds like an Eclipse problem then. In any case, I would not consider adding annotations to the classes. We went to some effort to make the scope of the annotations as local as possible (as did the JDK). > > We could consider a follow-up issue to clean this up, but I'm not really inclined to change anything. > > The question is if this can cause any bugs? Is the method supposed to override? If yes and it isn't, it sounds like something could go wrong. It isn't intended to be an override. The context parameter is passed up to the superclass and stored there as well as in the subclass. We could explore a different design pattern, but I don't think it is necessary. ------------- PR: https://git.openjdk.java.net/jfx/pull/628 From tsayao at openjdk.java.net Wed Sep 22 16:39:15 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Wed, 22 Sep 2021 16:39:15 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3] In-Reply-To: References: Message-ID: > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Break if reach self ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/598/files - new: https://git.openjdk.java.net/jfx/pull/598/files/850cfc8b..eb93b8b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=01-02 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/598.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598 PR: https://git.openjdk.java.net/jfx/pull/598 From mhanl at openjdk.java.net Wed Sep 22 17:36:55 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 22 Sep 2021 17:36:55 GMT Subject: RFR: 8271474: Tree-/TableCell: inconsistent edit event firing pattern In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 14:53:50 GMT, Jeanette Winzenburg wrote: > this PR fixes the inconsistent event firing pattern in cell's xxEdit methods (please see the issue for more details): > > - fires event if column != null > - accesses table state if table != null > > The first requires a change in CellEditEvent which now allows null table in its constructor. > > Added tests that failed/passed before/after the fix (along with some that also passed before for complete coverage of state permutations). Changed two old test methods which passed/failed before/after the fix - but did test the wrong thingy anyway ;) Looks good to me. ?? ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/620 From mhanl at openjdk.java.net Wed Sep 22 18:51:03 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 22 Sep 2021 18:51:03 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 19:57:17 GMT, Michael Strau? wrote: > The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. > > The following program shows the problem for HBox: > > Region r1 = new Region(); > Region r2 = new Region(); > Region r3 = new Region(); > Region r4 = new Region(); > Region r5 = new Region(); > Region r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); > hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox1.setPrefHeight(40); > > r1 = new Region(); > r2 = new Region(); > r3 = new Region(); > r4 = new Region(); > r5 = new Region(); > r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); > hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox2.setPrefHeight(40); > hbox2.setPrefWidth(152); > > VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); > root.setSpacing(20); > Scene scene = new Scene(root, 500, 250); > > primaryStage.setScene(scene); > primaryStage.show(); > > > Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. > ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) > > I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. I had a look at the PR. But it took quite a while to fully understand the changes (also the current implementation ??). I think it make sense to improve it a bit e.g. by adding javadoc to the new methods, maybe also the existing? Other ideas are also welcome. With that said maybe more people will review it then. I will have a full look soon as well. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/445 From jvos at openjdk.java.net Wed Sep 22 19:28:32 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 22 Sep 2021 19:28:32 GMT Subject: [jfx17u] RFR: 8273754: Re-introduce Automatic-Module-Name in empty jars Message-ID: <7vZiJD2pEKggIlJalWCsoSwr4RGNsAaR4TpeI8A-vsQ=.d634cd15-8b4b-4b7b-806d-44810e5220e6@github.com> Clean backport of JDK-8273754 which also appears in hotfix build 17.0.0.1 Reviewed-by: kcr, jvos ------------- Commit messages: - 8273754: Re-introduce Automatic-Module-Name in empty jars Changes: https://git.openjdk.java.net/jfx17u/pull/11/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=11&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273754 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/11.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/11/head:pull/11 PR: https://git.openjdk.java.net/jfx17u/pull/11 From jvos at openjdk.java.net Wed Sep 22 19:31:12 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 22 Sep 2021 19:31:12 GMT Subject: [jfx17u] RFR: 8269374: Menu inoperable after setting stage to second monitor Message-ID: Clean backport of JDK-8269374 (already in 11.0.13) Reviewed-by: kcr, arapte ------------- Commit messages: - 8269374: Menu inoperable after setting stage to second monitor Changes: https://git.openjdk.java.net/jfx17u/pull/12/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=12&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269374 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/12/head:pull/12 PR: https://git.openjdk.java.net/jfx17u/pull/12 From jvos at openjdk.java.net Wed Sep 22 19:42:13 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 22 Sep 2021 19:42:13 GMT Subject: [jfx17u] Integrated: 8273754: Re-introduce Automatic-Module-Name in empty jars In-Reply-To: <7vZiJD2pEKggIlJalWCsoSwr4RGNsAaR4TpeI8A-vsQ=.d634cd15-8b4b-4b7b-806d-44810e5220e6@github.com> References: <7vZiJD2pEKggIlJalWCsoSwr4RGNsAaR4TpeI8A-vsQ=.d634cd15-8b4b-4b7b-806d-44810e5220e6@github.com> Message-ID: On Wed, 22 Sep 2021 19:21:27 GMT, Johan Vos wrote: > Clean backport of JDK-8273754 which also appears in hotfix build 17.0.0.1 > > Reviewed-by: kcr, jvos This pull request has now been integrated. Changeset: 9bd87081 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/9bd87081be18e787d7fec41d9cb5c6db7544c932 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8273754: Re-introduce Automatic-Module-Name in empty jars Backport-of: 7329279e504070355ba9aa0517f0279e7e72c2cf ------------- PR: https://git.openjdk.java.net/jfx17u/pull/11 From jvos at openjdk.java.net Wed Sep 22 19:43:57 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 22 Sep 2021 19:43:57 GMT Subject: [jfx17u] Integrated: 8269374: Menu inoperable after setting stage to second monitor In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 19:25:41 GMT, Johan Vos wrote: > Clean backport of JDK-8269374 (already in 11.0.13) > > Reviewed-by: kcr, arapte This pull request has now been integrated. Changeset: 483e53b4 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/483e53b4763b384532f748a71a282c07ca133208 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod 8269374: Menu inoperable after setting stage to second monitor Backport-of: c490ddfdb1255add00dd7b0f14fe03857c6946c5 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/12 From nlisker at openjdk.java.net Thu Sep 23 03:27:05 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 23 Sep 2021 03:27:05 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers Message-ID: Replacements of more immutable collections. One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. ------------- Commit messages: - Fix a previous change - More leftovers - Unified style - Fix mistake from previous commit - Replace map in JSCL - Initial commit of 2 files Changes: https://git.openjdk.java.net/jfx/pull/627/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=627&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272808 Stats: 162 lines in 7 files changed: 0 ins; 28 del; 134 mod Patch: https://git.openjdk.java.net/jfx/pull/627.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/627/head:pull/627 PR: https://git.openjdk.java.net/jfx/pull/627 From github.com+51889757+delvh at openjdk.java.net Thu Sep 23 06:30:15 2021 From: github.com+51889757+delvh at openjdk.java.net (delvh) Date: Thu, 23 Sep 2021 06:30:15 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 11:13:06 GMT, Nir Lisker wrote: > Replacements of more immutable collections. > > One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. modules/javafx.graphics/src/main/java/com/sun/javafx/font/WindowsFontMap.java line 32: > 30: class WindowsFontMap { > 31: > 32: private static class FamilyDescription { Isn't that basically a `record` in disguise? Letting this class be a record would remove a lot of lines, especially down below. Also, it would come with the benefit of not having to worry about whether these values have been changed or not as they would then always be final. To me at least it does not look as if variables of this class should be mutable after having been created. ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From fkirmaier at openjdk.java.net Thu Sep 23 11:58:54 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Thu, 23 Sep 2021 11:58:54 GMT Subject: Integrated: 8273969: Memory Leak on the Runnable provided to Platform.startup In-Reply-To: References: Message-ID: On Sun, 19 Sep 2021 15:33:46 GMT, Florian Kirmaier wrote: > Probably my most boring PR. ;) > Setting the lambda to null, after it has been used, fixes the leak. This pull request has now been integrated. Changeset: 4b9cb210 Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/4b9cb2106c688574ed0f6602818ee9683e802ee7 Stats: 56 lines in 2 files changed: 56 ins; 0 del; 0 mod 8273969: Memory Leak on the Runnable provided to Platform.startup Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/626 From kcr at openjdk.java.net Thu Sep 23 12:45:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Sep 2021 12:45:56 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers In-Reply-To: References: Message-ID: <9iYyh5lZljjawk99v7684hoeVQhnhnerlR5fzPJKYso=.1096a6ab-c52a-4ef6-b86a-2abc12462d2f@github.com> On Wed, 22 Sep 2021 21:36:26 GMT, delvh wrote: >> Replacements of more immutable collections. >> >> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. > > modules/javafx.graphics/src/main/java/com/sun/javafx/font/WindowsFontMap.java line 32: > >> 30: class WindowsFontMap { >> 31: >> 32: private static class FamilyDescription { > > Isn't that basically a `record` in disguise? > Letting this class be a record would remove a lot of lines, especially down below. > Also, it would come with the benefit of not having to worry about whether these values have been changed or not as they would then always be final. > To me at least it does not look as if variables of this class should be mutable after having been created. We still build JavaFX with `--release 11` so applications using JavaFX can run on JDK 11 or later. At some point we will bump the minimum version of Java that is required, but until then we cannot use records or any other feature that isn't in Java 11. ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From kcr at openjdk.java.net Thu Sep 23 12:49:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Sep 2021 12:49:54 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 11:13:06 GMT, Nir Lisker wrote: > Replacements of more immutable collections. > > One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. This is a pretty simple change, but a second pair of eyes would be helpful. ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From rlichten at openjdk.java.net Thu Sep 23 14:20:10 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Thu, 23 Sep 2021 14:20:10 GMT Subject: RFR: 8274137: TableView scrollbar/header misaligned when reloading data Message-ID: This PR fixes JDK-8274137 by removing the optimization from updateHbar() that will no-op the method in case the VirtualFlow is invisible or currently has no scene. Since changes to the hBar's value can happen even if the VirtualFlow is not currently visible, the synchronisation between hBar and clipX must happen all the time. A test agains VirtualFlow has been added that will fail before the change and pass afterwards. ------------- Commit messages: - 8274137: TableView scrollbar/header misaligned when reloading data. - 8274137: TableView scrollbar/header misaligned when reloading data. - 8274137: TableView scrollbar/header misaligned when reloading data Changes: https://git.openjdk.java.net/jfx/pull/629/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=629&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274137 Stats: 33 lines in 3 files changed: 32 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/629.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/629/head:pull/629 PR: https://git.openjdk.java.net/jfx/pull/629 From kcr at openjdk.java.net Thu Sep 23 16:52:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 23 Sep 2021 16:52:13 GMT Subject: RFR: 8274137: TableView scrollbar/header misaligned when reloading data In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 13:48:44 GMT, Robert Lichtenberger wrote: > This PR fixes JDK-8274137 by removing the optimization from updateHbar() that will no-op the method in case the VirtualFlow is invisible or currently has no scene. > Since changes to the hBar's value can happen even if the VirtualFlow is not currently visible, the synchronisation between hBar and clipX must happen all the time. > > A test agains VirtualFlow has been added that will fail before the change and pass afterwards. I am hesitant to take this fix "as is". At least not without more evaluation and testing. First, this has the potential to hurt performance for applications that do a lot of setup on tables that aren't visible. There are several places where we defer updating and the usual way we address any such problems is to validate when "something" changes. In this case, the "something" should include becoming visible or the scene going to non-null (or alternatively being "treeVisible", which means visible and part of a scene that is showing). Second, the code you propose to remove was added as part of the fix for [JDK-8112072](https://bugs.openjdk.java.net/browse/JDK-8112072), and while I doubt it was added to ensure correctness, it will need to be tested. Third, I prefer that tests not check a specific implementation detail such as ensuring that derived values are computed when the scene is null or the node is invisible. Rather, it is better to check that a change made while the node is not visible (or the scene is null), is valid _after_ making it visible on an active scene. ------------- PR: https://git.openjdk.java.net/jfx/pull/629 From mhanl at openjdk.java.net Thu Sep 23 18:06:58 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 23 Sep 2021 18:06:58 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 11:13:06 GMT, Nir Lisker wrote: > Replacements of more immutable collections. > > One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. modules/javafx.graphics/src/main/java/com/sun/javafx/font/WindowsFontMap.java line 44: > 42: } > 43: > 44: private static Map PLATFORM_FONT_MAP; Shouldn't this variable name stay with the normal camel case because it is not final (only static)? ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From mhanl at openjdk.java.net Thu Sep 23 19:11:13 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 23 Sep 2021 19:11:13 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling Message-ID: This PR fixes an issue which is probably in JavaFX since VirtualFlow exists. While horizontal scrolling any VirtualFlow control the left blue border sometimes disappear/gets smaller. (see also image below) This can be fixed by **snapping** the scroll bar value (similar like e.g. a **ScrollPane** does). The same needs to be done on the table header as otherwise the column lines might be 1 px off to the cell lines. As a side effect this also fixes that the column lines sometimes get's blurry when horizontal scrolling (see second image). While testing with **-Dglass.win.uiScale** I found out that the problem is not fixed for a scale like 1.25 or 1.5, while it is fixed for 1 or 2. The border sometimes disappears only when the snapped value is a decimal number (which obviously does not happen on a scale of 1 or 2), e.g. something like 12.6 but it will never disappear when it's a normal number, so e.g. just 12. That's why something like **Math.round(..)** or just a **cast** to an **int** instead of snapping fixes this problem for all scales. I also didn't notice any side effect. But not sure if this the right fix then. How does JavaFX render a **node** when e.g. the x is a decimal number? And does a decimal number make sense (Why we e.g. don't round the value)? Another explanation could also be that there is an issue somewhere deep inside the node layout/snapping/Clip/Group/pixel rendering and to simply round/cast the value just fixes the symptom here. In any case I'm open for any feedback, help or explanation. I'm also glad for anything which might help identify the root cause here, if any. --- 1. ![image](https://user-images.githubusercontent.com/66004280/134562508-bea6ab9d-d3d0-4dbb-b0ce-dc6570a94ed7.png) --- 2. ![image](https://user-images.githubusercontent.com/66004280/134563377-970b4e48-8528-4dad-95fb-fb93780413e8.png) ------------- Commit messages: - 8218745: Snapping X/Y when scrolling Changes: https://git.openjdk.java.net/jfx/pull/630/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=630&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8218745 Stats: 59 lines in 6 files changed: 55 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/630.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/630/head:pull/630 PR: https://git.openjdk.java.net/jfx/pull/630 From arapte at openjdk.java.net Thu Sep 23 19:32:16 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 23 Sep 2021 19:32:16 GMT Subject: RFR: 8274107: Cherry pick GTK WebKit 2.32.4 changes Message-ID: Cherry pick the GTK webkit 2.32.4 changes https://webkitgtk.org/2021/09/17/webkitgtk2.32.4-released.html ------------- Commit messages: - cherry-pick webkit-2.32.4 Changes: https://git.openjdk.java.net/jfx/pull/631/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=631&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274107 Stats: 1811 lines in 131 files changed: 1043 ins; 205 del; 563 mod Patch: https://git.openjdk.java.net/jfx/pull/631.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/631/head:pull/631 PR: https://git.openjdk.java.net/jfx/pull/631 From github.com+51889757+delvh at openjdk.java.net Thu Sep 23 21:58:54 2021 From: github.com+51889757+delvh at openjdk.java.net (delvh) Date: Thu, 23 Sep 2021 21:58:54 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers In-Reply-To: <9iYyh5lZljjawk99v7684hoeVQhnhnerlR5fzPJKYso=.1096a6ab-c52a-4ef6-b86a-2abc12462d2f@github.com> References: <9iYyh5lZljjawk99v7684hoeVQhnhnerlR5fzPJKYso=.1096a6ab-c52a-4ef6-b86a-2abc12462d2f@github.com> Message-ID: On Thu, 23 Sep 2021 12:43:20 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/font/WindowsFontMap.java line 32: >> >>> 30: class WindowsFontMap { >>> 31: >>> 32: private static class FamilyDescription { >> >> Isn't that basically a `record` in disguise? >> Letting this class be a record would remove a lot of lines, especially down below. >> Also, it would come with the benefit of not having to worry about whether these values have been changed or not as they would then always be final. >> To me at least it does not look as if variables of this class should be mutable after having been created. > > We still build JavaFX with `--release 11` so applications using JavaFX can run on JDK 11 or later. At some point we will bump the minimum version of Java that is required, but until then we cannot use records or any other feature that isn't in Java 11. That is indeed a valid argument as to why this isn't a record. Obviously, I did not think about that while reviewing. ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From kcr at openjdk.java.net Fri Sep 24 01:54:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Sep 2021 01:54:54 GMT Subject: RFR: 8274107: Cherry pick GTK WebKit 2.32.4 changes In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 19:26:47 GMT, Ambarish Rapte wrote: > Cherry pick the GTK webkit 2.32.4 changes > https://webkitgtk.org/2021/09/17/webkitgtk2.32.4-released.html Looks good. I built and tested it on all platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/631 From nlisker at openjdk.java.net Fri Sep 24 02:27:55 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 24 Sep 2021 02:27:55 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers In-Reply-To: References: <9iYyh5lZljjawk99v7684hoeVQhnhnerlR5fzPJKYso=.1096a6ab-c52a-4ef6-b86a-2abc12462d2f@github.com> Message-ID: On Thu, 23 Sep 2021 21:55:57 GMT, delvh wrote: >> We still build JavaFX with `--release 11` so applications using JavaFX can run on JDK 11 or later. At some point we will bump the minimum version of Java that is required, but until then we cannot use records or any other feature that isn't in Java 11. > > That is indeed a valid argument as to why this isn't a record. > Obviously, I did not think about that while reviewing. @delvh If you are interested, I already have a branch with records replacements for when we are able to use them https://github.com/nlisker/jfx/tree/Records. It hasn't been updated in a while so it doesn't include everything on my list. ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From nlisker at openjdk.java.net Fri Sep 24 02:52:53 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 24 Sep 2021 02:52:53 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 18:03:37 GMT, Marius Hanl wrote: >> Replacements of more immutable collections. >> >> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. > > modules/javafx.graphics/src/main/java/com/sun/javafx/font/WindowsFontMap.java line 44: > >> 42: } >> 43: >> 44: private static Map PLATFORM_FONT_MAP; > > Shouldn't this variable name stay with the normal camel case because it is not final (only static)? Yes, but it's created only once via lazy initialization and then it's effectively final. A matter of taste I would say. There is also a JEP that deals with these cases https://openjdk.java.net/jeps/8209964. ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From rlichten at openjdk.java.net Fri Sep 24 06:20:54 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 24 Sep 2021 06:20:54 GMT Subject: RFR: 8274137: TableView scrollbar/header misaligned when reloading data In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 16:46:15 GMT, Kevin Rushforth wrote: > First, this has the potential to hurt performance for applications that do a lot of setup on tables that aren't visible. That would be possible if the hbar changes its visibility or its value. I can't really see how that would happen as long as the hbar isn't visible. Well I guess it is theoretically possible that someone subclasses VirtualFlow and adds thousands of items and changes the hbar value to some value after each item before making the VirtualFlow visible. > There are several places where we defer updating and the usual way we address any such problems is to validate when "something" changes. In this case, the "something" should include becoming visible or the scene going to non-null (or alternatively being "treeVisible", which means visible and part of a scene that is showing). If this is the "convention" of how things should be done then I will adapt my PR to **not** remove the said line but instead make the listenerX fire also when the VIrtualFlow's visible or scene property changes. This will also fix the problem an keep the performance optimization in place. > Second, the code you propose to remove was added as part of the fix for [JDK-8112072](https://bugs.openjdk.java.net/browse/JDK-8112072), and while I doubt it was added to ensure correctness, it will need to be tested. As posted in JDK-8274137: Tested it, found no problems. > Third, I prefer that tests not check a specific implementation detail such as ensuring that derived values are computed when the scene is null or the node is invisible. Rather, it is better to check that a change made while the node is not visible (or the scene is null), is valid _after_ making it visible on an active scene. I claim that testScrollBarClipSyncWhileInvisibleOrNoScene does just that. * It first checks that hBar and clipping stay in sync when the flow is visible and has a scene. (sunshine case) * Then it changes the hBar while the flow is invisible, makes the flow visible again and checks if (after the flow is now visible again) hBar and clipping are in sync again. * Then it does the same by removing hBar from the scene. ------------- PR: https://git.openjdk.java.net/jfx/pull/629 From rlichten at openjdk.java.net Fri Sep 24 06:28:30 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Fri, 24 Sep 2021 06:28:30 GMT Subject: RFR: 8274137: TableView scrollbar/header misaligned when reloading data [v2] In-Reply-To: References: Message-ID: > This PR fixes JDK-8274137 by removing the optimization from updateHbar() that will no-op the method in case the VirtualFlow is invisible or currently has no scene. > Since changes to the hBar's value can happen even if the VirtualFlow is not currently visible, the synchronisation between hBar and clipX must happen all the time. > > A test agains VirtualFlow has been added that will fail before the change and pass afterwards. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8274137: TableView scrollbar/header misaligned when reloading data Alternative fix using additional listeners instead of removing optimization. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/629/files - new: https://git.openjdk.java.net/jfx/pull/629/files/7d04993f..03bcd0f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=629&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=629&range=00-01 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/629.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/629/head:pull/629 PR: https://git.openjdk.java.net/jfx/pull/629 From aghaisas at openjdk.java.net Fri Sep 24 10:53:01 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 24 Sep 2021 10:53:01 GMT Subject: RFR: 8231644: TreeTableView Regression: Indentation wrong using Label as column content type [v3] In-Reply-To: <24XaRxgrUri2EYi_cdS5y1i3BljInwnBafxkvC7EgLg=.bd3b0dc8-c70b-49b9-a2d5-d1dc9aa3eb9f@github.com> References: <44hbYPKwJb2SX19CjpWQT7Lz64EQzz8o3znV6m5VDcQ=.3eb1a2de-d633-4547-aeee-279757cce7f1@github.com> <24XaRxgrUri2EYi_cdS5y1i3BljInwnBafxkvC7EgLg=.bd3b0dc8-c70b-49b9-a2d5-d1dc9aa3eb9f@github.com> Message-ID: On Tue, 27 Jul 2021 05:45:50 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue with the TreeTableView indentation. >> >> ![image](https://user-images.githubusercontent.com/66004280/124681647-473e7380-dec9-11eb-906d-4228fc39cbf9.png) >> >> In short: >> **TreeTableCellSkin** overrides **leftLabelPadding()** to calculate the indentation (the result of this method is added to **x**). >> While this is fine, this method is not always called (by **LabeledSkinBase#layoutLabelInArea**), e.g. when no text is set. >> So when a TreeTableCell only sets a graphic (e.g. via **setGraphic()** in **updateItem()**), the indentation will be messed up. >> >> Fixed this by adding the calculated indentation to **x** before we call **layoutChildren()**. >> >> We also need/should adjust every other location where `leftLabelPadding()` was used: >> - **computePrefHeight** -> prefWidth() is always called with -1, so nothing got broken by not overriding this, but we should do it of course to be accurate in case we do one day. >> - **computePrefWidth** -> this is needed for auto sizing. I saw that it was slightly off without, so this 100% needed. >> - **computeMinWidth** -> the min width of a cell is not used, so nothing got broken by not overriding this but same as in computePrefHeight(), we should comply with the specs. >> - **layoutChildren** -> I saw a slight off sizing if the indentation is not subtracted to the width. >> >> As a result of this, all method do effectively the same as they did with an overridden `leftLabelPadding()` (just earlier/later and always now of course). >> Note: I also added some tests which pass before and pass after. > > 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 8231644-indentation > >  Conflicts: >  modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableCellSkin.java > - calculated indentation in every method now which was previously done via leftLabelPadding > - 8231644: fixed wrong indentation for tree cells with graphic only Overall the fix looks ok. The new test fails without the fix and passes with it. Can you please confirm the test programs provided in 2 duplicated bugs of JDK-8231644 also work as expected with this fix? modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableCellSkin.java line 127: > 125: double leftInset) { > 126: if (isDeferToParentForPrefWidth) { > 127: return super.computePrefWidth(height, topInset, rightInset, bottomInset, leftInset) + calculateIndentation(); If we are deferring to Parent for the preferred width, then we need not add indentation. I think, we should interchange line 127 and line 130. ------------- PR: https://git.openjdk.java.net/jfx/pull/568 From kcr at openjdk.java.net Fri Sep 24 11:31:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Sep 2021 11:31:56 GMT Subject: RFR: 8274137: TableView scrollbar/header misaligned when reloading data [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 06:28:30 GMT, Robert Lichtenberger wrote: >> This PR fixes JDK-8274137 by removing the optimization from updateHbar() that will no-op the method in case the VirtualFlow is invisible or currently has no scene. >> Since changes to the hBar's value can happen even if the VirtualFlow is not currently visible, the synchronisation between hBar and clipX must happen all the time. >> >> A test agains VirtualFlow has been added that will fail before the change and pass afterwards. > > Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: > > 8274137: TableView scrollbar/header misaligned when reloading data > > Alternative fix using additional listeners instead of removing > optimization. The fix and test look good. I left one comment about some unrelated changes. I still need to test this, but will do so soon. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3194: > 3192: } > 3193: > 3194: @Override The added `@Override` annotations are unrelated to your fix. Can you please revert them? ------------- PR: https://git.openjdk.java.net/jfx/pull/629 From kcr at openjdk.java.net Fri Sep 24 11:31:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Sep 2021 11:31:56 GMT Subject: RFR: 8274137: TableView scrollbar/header misaligned when reloading data In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 06:16:55 GMT, Robert Lichtenberger wrote: > > First, this has the potential to hurt performance for applications that do a lot of setup on tables that aren't visible. > > That would be possible if the hbar changes its visibility or its value. I can't really see how that would happen as long as the hbar isn't visible. Well I guess it is theoretically possible that someone subclasses VirtualFlow and adds thousands of items and changes the hbar value to some value after each item before making the VirtualFlow visible. > > There are several places where we defer updating and the usual way we address any such problems is to validate when "something" changes. In this case, the "something" should include becoming visible or the scene going to non-null (or alternatively being "treeVisible", which means visible and part of a scene that is showing). > > If this is the "convention" of how things should be done then I will adapt my PR to **not** remove the said line but instead make the listenerX fire also when the VIrtualFlow's visible or scene property changes. > This will also fix the problem an keep the performance optimization in place. Good. This seems a better fix. While the performance hit is likely theoretical, it becomes a non-issue with your update fix. > > Second, the code you propose to remove was added as part of the fix for [JDK-8112072](https://bugs.openjdk.java.net/browse/JDK-8112072), and while I doubt it was added to ensure correctness, it will need to be tested. > > As posted in JDK-8274137: Tested it, found no problems. Thanks. > > Third, I prefer that tests not check a specific implementation detail such as ensuring that derived values are computed when the scene is null or the node is invisible. Rather, it is better to check that a change made while the node is not visible (or the scene is null), is valid _after_ making it visible on an active scene. > > I claim that testScrollBarClipSyncWhileInvisibleOrNoScene does just that. > > * It first checks that hBar and clipping stay in sync when the flow is visible and has a scene. (sunshine case) > * Then it changes the hBar while the flow is invisible, makes the flow visible again and checks if (after the flow is now visible again) hBar and clipping are in sync again. > * Then it does the same by removing hBar from the scene. Clearly I didn't look closely enough at the test. I missed that you were already doing what I was asking for. ------------- PR: https://git.openjdk.java.net/jfx/pull/629 From kevin.rushforth at oracle.com Fri Sep 24 11:47:13 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 24 Sep 2021 04:47:13 -0700 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> Message-ID: <9e5e7704-5f6e-5fcd-6ffb-4bc67e9ff5c8@oracle.com> I don't have an objection to adding this one additional convenience method if it is generally useful. If there aren't a lot of applications that would use it, it seems better to go with just the two identified so far and consider this one later. So: would this be a generally useful addition? -- Kevin On 9/21/2021 2:43 AM, Marius Hanl wrote: > As also written in a comment > here: https://github.com/openjdk/jfx/pull/610 > I would like to propose one more convenience method which should be > added to JavaFX: > > public static Border stroke(Paint stroke, double width) { > return new Border(new BorderStroke(stroke, BorderStrokeStyle.SOLID, null, ne > w BorderWidths(width))); > } > > I think it's quite common that you want to create a solid border with > another width then the default of 1 (for every side). > > Note: This is also the last use case I think makes sense to add as a > convenience method. > Any other use case is likely to be so complex that it makes sense to > use the normal existing constructors. > > Feel free to share you opinion. > > - Marius > > Gesendet: Dienstag, 08. Juni 2021 um 03:19 Uhr > Von: "Nir Lisker" > An: "Kevin Rushforth" > Cc: "openjfx-dev at openjdk.java.net Mailing" > > Betreff: Re: [External] : Re: Convenience factories for Border and > Background > The new API: > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` that does > `new Border(new BorderStroke(Paint stroke , BorderStrokeStyle.SOLID, > null, > null));` > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` that > does > `new Background(new BackgroundFill(Paint fill, null, null));` > I don't mind either name choice. > On Tue, Jun 8, 2021 at 2:50 AM Kevin Rushforth > > wrote: > > If I recall, there were a few developers that chimed in. It's a > simple > > enough addition -- at least your original proposal (not the > suggestion of > > mirroring the Color API, which I don't like) -- that it seems OK to > me. > > > > Can you repost your currently proposed API and see if those who might > like > > to use it are satisfied with it? > > > > -- Kevin > > > > > > On 6/7/2021 4:41 PM, Nir Lisker wrote: > > > > Does this constitute sufficient interest in the enhancement? > > > > On Thu, May 13, 2021 at 6:41 PM Michael Strau? > > > wrote: > > > >> Another option could be to mirror the `Color` API in both `Border` > and > >> `Background`, like in the following examples: > >> > >> Color.rgb(125, 100, 75) > >> Border.rgb(125, 100, 75) > >> Background.rgb(125, 100, 75) > >> > >> Color.gray(127) > >> Border.gray(127) > >> Background.gray(127) > >> > >> Color.web("orange", 0.5) > >> Border.web("orange", 0.5) > >> Background.web("orange", 0.5) > >> > >> We could also mirror the named color constants, which would enable a > >> very compact syntax: > >> > >> StackPane pane = new StackPane(); > >> pane.setBorder(Border.RED); > >> pane.setBackground(Background.BLUE); > >> > >> This is very similar to how "red" or "blue" are valid values for > >> "-fx-border" or "-fx-background" in CSS. > >> > > > > From nlisker at gmail.com Fri Sep 24 11:50:28 2021 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 24 Sep 2021 14:50:28 +0300 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: <9e5e7704-5f6e-5fcd-6ffb-4bc67e9ff5c8@oracle.com> References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> <9e5e7704-5f6e-5fcd-6ffb-4bc67e9ff5c8@oracle.com> Message-ID: I don't have a strong opinion on this addition. On Fri, Sep 24, 2021 at 2:47 PM Kevin Rushforth wrote: > I don't have an objection to adding this one additional convenience > method if it is generally useful. If there aren't a lot of applications > that would use it, it seems better to go with just the two identified so > far and consider this one later. > > So: would this be a generally useful addition? > > -- Kevin > > > On 9/21/2021 2:43 AM, Marius Hanl wrote: > > As also written in a comment > > here: https://github.com/openjdk/jfx/pull/610 > > I would like to propose one more convenience method which should be > > added to JavaFX: > > > > public static Border stroke(Paint stroke, double width) { > > return new Border(new BorderStroke(stroke, BorderStrokeStyle.SOLID, > null, ne > > w BorderWidths(width))); > > } > > > > I think it's quite common that you want to create a solid border with > > another width then the default of 1 (for every side). > > > > Note: This is also the last use case I think makes sense to add as a > > convenience method. > > Any other use case is likely to be so complex that it makes sense to > > use the normal existing constructors. > > > > Feel free to share you opinion. > > > > - Marius > > > > Gesendet: Dienstag, 08. Juni 2021 um 03:19 Uhr > > Von: "Nir Lisker" > > An: "Kevin Rushforth" > > Cc: "openjfx-dev at openjdk.java.net Mailing" > > > > Betreff: Re: [External] : Re: Convenience factories for Border and > > Background > > The new API: > > 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)` that > does > > `new Border(new BorderStroke(Paint stroke , BorderStrokeStyle.SOLID, > > null, > > null));` > > 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)` that > > does > > `new Background(new BackgroundFill(Paint fill, null, null));` > > I don't mind either name choice. > > On Tue, Jun 8, 2021 at 2:50 AM Kevin Rushforth > > > > wrote: > > > If I recall, there were a few developers that chimed in. It's a > > simple > > > enough addition -- at least your original proposal (not the > > suggestion of > > > mirroring the Color API, which I don't like) -- that it seems OK to > > me. > > > > > > Can you repost your currently proposed API and see if those who > might > > like > > > to use it are satisfied with it? > > > > > > -- Kevin > > > > > > > > > On 6/7/2021 4:41 PM, Nir Lisker wrote: > > > > > > Does this constitute sufficient interest in the enhancement? > > > > > > On Thu, May 13, 2021 at 6:41 PM Michael Strau? > > > > > wrote: > > > > > >> Another option could be to mirror the `Color` API in both `Border` > > and > > >> `Background`, like in the following examples: > > >> > > >> Color.rgb(125, 100, 75) > > >> Border.rgb(125, 100, 75) > > >> Background.rgb(125, 100, 75) > > >> > > >> Color.gray(127) > > >> Border.gray(127) > > >> Background.gray(127) > > >> > > >> Color.web("orange", 0.5) > > >> Border.web("orange", 0.5) > > >> Background.web("orange", 0.5) > > >> > > >> We could also mirror the named color constants, which would > enable a > > >> very compact syntax: > > >> > > >> StackPane pane = new StackPane(); > > >> pane.setBorder(Border.RED); > > >> pane.setBackground(Background.BLUE); > > >> > > >> This is very similar to how "red" or "blue" are valid values for > > >> "-fx-border" or "-fx-background" in CSS. > > >> > > > > > > > > From aghaisas at openjdk.java.net Fri Sep 24 11:57:53 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 24 Sep 2021 11:57:53 GMT Subject: RFR: 8271474: Tree-/TableCell: inconsistent edit event firing pattern In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 14:53:50 GMT, Jeanette Winzenburg wrote: > this PR fixes the inconsistent event firing pattern in cell's xxEdit methods (please see the issue for more details): > > - fires event if column != null > - accesses table state if table != null > > The first requires a change in CellEditEvent which now allows null table in its constructor. > > Added tests that failed/passed before/after the fix (along with some that also passed before for complete coverage of state permutations). Changed two old test methods which passed/failed before/after the fix - but did test the wrong thingy anyway ;) Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/620 From jvos at openjdk.java.net Fri Sep 24 15:14:58 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 24 Sep 2021 15:14:58 GMT Subject: RFR: 8274107: Cherry pick GTK WebKit 2.32.4 changes In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 19:26:47 GMT, Ambarish Rapte wrote: > Cherry pick the GTK webkit 2.32.4 changes > https://webkitgtk.org/2021/09/17/webkitgtk2.32.4-released.html build & tests ok on mac(x86_64 and aarch64)/linux/win ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/631 From arapte at openjdk.java.net Fri Sep 24 15:28:03 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 24 Sep 2021 15:28:03 GMT Subject: Integrated: 8274107: Cherry pick GTK WebKit 2.32.4 changes In-Reply-To: References: Message-ID: On Thu, 23 Sep 2021 19:26:47 GMT, Ambarish Rapte wrote: > Cherry pick the GTK webkit 2.32.4 changes > https://webkitgtk.org/2021/09/17/webkitgtk2.32.4-released.html This pull request has now been integrated. Changeset: 478512b7 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/478512b705af840cd9f658b22f272165bc1c1bc3 Stats: 1811 lines in 131 files changed: 1043 ins; 205 del; 563 mod 8274107: Cherry pick GTK WebKit 2.32.4 changes Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/631 From fastegal at openjdk.java.net Fri Sep 24 16:06:23 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 24 Sep 2021 16:06:23 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin Message-ID: Cleanup of Tree-/TableRowSkin to support switching skins The misbehavior/s - memory leaks due to manually registered listeners that were not removed - side-effects due to listeners still active on old skin (like NPEs) Fix - use skin api for all listener registration (for automatic removal in dispose) - do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745)) Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins. Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065) ------------- Commit messages: - 8274061: Tree-/TableRowSkin: misbehavior on switching skin Changes: https://git.openjdk.java.net/jfx/pull/632/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=632&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274061 Stats: 1005 lines in 8 files changed: 882 ins; 100 del; 23 mod Patch: https://git.openjdk.java.net/jfx/pull/632.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/632/head:pull/632 PR: https://git.openjdk.java.net/jfx/pull/632 From fastegal at openjdk.java.net Fri Sep 24 16:09:55 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 24 Sep 2021 16:09:55 GMT Subject: Integrated: 8271474: Tree-/TableCell: inconsistent edit event firing pattern In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 14:53:50 GMT, Jeanette Winzenburg wrote: > this PR fixes the inconsistent event firing pattern in cell's xxEdit methods (please see the issue for more details): > > - fires event if column != null > - accesses table state if table != null > > The first requires a change in CellEditEvent which now allows null table in its constructor. > > Added tests that failed/passed before/after the fix (along with some that also passed before for complete coverage of state permutations). Changed two old test methods which passed/failed before/after the fix - but did test the wrong thingy anyway ;) This pull request has now been integrated. Changeset: 55faac49 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/55faac49082ee8c92893dac15d2777011ec7dca0 Stats: 404 lines in 12 files changed: 358 ins; 22 del; 24 mod 8271474: Tree-/TableCell: inconsistent edit event firing pattern Reviewed-by: mhanl, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/620 From mhanl at openjdk.java.net Fri Sep 24 16:35:33 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 24 Sep 2021 16:35:33 GMT Subject: RFR: 8231644: TreeTableView Regression: Indentation wrong using Label as column content type [v3] In-Reply-To: References: <44hbYPKwJb2SX19CjpWQT7Lz64EQzz8o3znV6m5VDcQ=.3eb1a2de-d633-4547-aeee-279757cce7f1@github.com> <24XaRxgrUri2EYi_cdS5y1i3BljInwnBafxkvC7EgLg=.bd3b0dc8-c70b-49b9-a2d5-d1dc9aa3eb9f@github.com> Message-ID: <10hR53GHD2_CRTnyxXzBP6wBNZxn0diFusDejp_4U-g=.b84736bb-331e-43b8-9fd9-1735977c4dd5@github.com> On Fri, 24 Sep 2021 10:43:31 GMT, Ajit Ghaisas wrote: >> 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 8231644-indentation >> >>  Conflicts: >>  modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableCellSkin.java >> - calculated indentation in every method now which was previously done via leftLabelPadding >> - 8231644: fixed wrong indentation for tree cells with graphic only > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableCellSkin.java line 127: > >> 125: double leftInset) { >> 126: if (isDeferToParentForPrefWidth) { >> 127: return super.computePrefWidth(height, topInset, rightInset, bottomInset, leftInset) + calculateIndentation(); > > If we are deferring to Parent for the preferred width, then we need not add indentation. > I think, we should interchange line 127 and line 130. No that's actually correct as it is. That is because when a cell is deferred from the parent we want to know the width we need without being truncated. For now that is only set when the auto size of the table is triggered (see also: **TableColumnHeader#resizeColumnToFitContent**). And if not deferred, the width of the cell is in sync with the column (you can also see it in the **super.computePrefWidth**) ------------- PR: https://git.openjdk.java.net/jfx/pull/568 From mhanl at openjdk.java.net Fri Sep 24 16:41:06 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 24 Sep 2021 16:41:06 GMT Subject: RFR: 8231644: TreeTableView Regression: Indentation wrong using Label as column content type [v3] In-Reply-To: References: <44hbYPKwJb2SX19CjpWQT7Lz64EQzz8o3znV6m5VDcQ=.3eb1a2de-d633-4547-aeee-279757cce7f1@github.com> <24XaRxgrUri2EYi_cdS5y1i3BljInwnBafxkvC7EgLg=.bd3b0dc8-c70b-49b9-a2d5-d1dc9aa3eb9f@github.com> Message-ID: On Fri, 24 Sep 2021 10:48:53 GMT, Ajit Ghaisas wrote: > Overall the fix looks ok. The new test fails without the fix and passes with it. > > Can you please confirm the test programs provided in 2 duplicated bugs of JDK-8231644 also work as expected with this fix? Just tried them. They both work fine. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/568 From jhendrikx at openjdk.java.net Fri Sep 24 20:11:02 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 24 Sep 2021 20:11:02 GMT Subject: RFR: 8274274: Update JavaFX test framework to JUnit 5 Message-ID: I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. I've updated the Eclipse project file for the base module only. ------------- Commit messages: - Add JUnit 5 Changes: https://git.openjdk.java.net/jfx/pull/633/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274274 Stats: 141 lines in 4 files changed: 141 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/633/head:pull/633 PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Fri Sep 24 20:41:19 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 24 Sep 2021 20:41:19 GMT Subject: RFR: 8274274: Update JavaFX test framework to JUnit 5 [v2] In-Reply-To: References: Message-ID: > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Add JUnit 5 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/633/files - new: https://git.openjdk.java.net/jfx/pull/633/files/072494e6..233fdb80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=00-01 Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/633/head:pull/633 PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Fri Sep 24 20:41:21 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 24 Sep 2021 20:41:21 GMT Subject: RFR: 8274274: Update JavaFX test framework to JUnit 5 In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:05:01 GMT, John Hendrikx wrote: > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. Sorry for the force push, forgot I already submitted it as a PR. I only removed a few extraneous dependencies that got added in the `verification-metadata.xml` (a few extra got added from different versions of JUnit 5 that weren't needed for the final version I'm using). ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Fri Sep 24 20:53:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Sep 2021 20:53:55 GMT Subject: RFR: 8274274: Update JavaFX test framework to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:41:19 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. As mentioned in JBS, any new third-party libraries require prior third-party license approval. And we will need to work with you on sponsoring this (as you can't contribute any third-party code under the OCA). Speaking of which, there are more libraries added to `gradle-verification.xml` than I would expect. Each one will need third-party approval, if they are required. Since this is for internal use (build / test only) and not something we redistribute, that makes it easier, although it still depends on the license for each piece. Finally, we have some closed tests that we need to ensure aren't impacted by this, so that's one more area we need to coordinate. We can take a look, but it won't be right away. Can you also start a thread on openjfx-dev? I'd like to gauge the level of interest in enabling JUnit 5 for new tests. Btw, I think this should be moved to a Draft PR until the third-party issues are resolved (including any needed approvals). gradle/verification-metadata.xml line 121: > 119: > 120: > 121: Why the dependency on junit 4.13.2? gradle/verification-metadata.xml line 247: > 245: > 246: > 247: Is `apiguardian` actually required in order to support JUnit 5? If not, this should be reverted. If so, that's another third-party dependency we would need to get approval for. gradle/verification-metadata.xml line 273: > 271: > 272: > 273: Is `hamcrest` actually required in order to support JUnit 5? If not, this should be reverted. If so, that's another third-party dependency we would need to get approval for. gradle/verification-metadata.xml line 345: > 343: > 344: > 345: Is `opentest4j` actually required in order to support JUnit 5? If not, this should be reverted. If so, that's another third-party dependency we would need to get approval for. modules/javafx.base/src/test/java/test/JUnit5Test.java line 1: > 1: package test; This needs a copyright header block. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Fri Sep 24 20:53:56 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 24 Sep 2021 20:53:56 GMT Subject: RFR: 8274274: Update JavaFX test framework to JUnit 5 In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:25:48 GMT, John Hendrikx wrote: > Sorry for the force push, forgot I already submitted it as a PR. That's OK. I deleted the couple of comments I had added relating to blocks that disappeared. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Fri Sep 24 20:53:59 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 24 Sep 2021 20:53:59 GMT Subject: RFR: 8274274: Update JavaFX test framework to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:31:14 GMT, Kevin Rushforth wrote: >> John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > gradle/verification-metadata.xml line 121: > >> 119: >> 120: >> 121: > > Why the dependency on junit 4.13.2? The vintage engine pulls this in, so I think we may be forced to upgrade from 4.8.2 JUnit 4 to 4.13.2 JUnit 4 as well, although the current setup seems to work (I remember some Rules being deprecated in later JUnit 4, specifically rules for catching exceptions which could require rewriting those tests to use `assertThrows`). > gradle/verification-metadata.xml line 247: > >> 245: >> 246: >> 247: > > Is `apiguardian` actually required in order to support JUnit 5? If not, this should be reverted. If so, that's another third-party dependency we would need to get approval for. It's an annotation used within JUnit code, it might be possible to block this one, I will see how to do this in Gradle syntax. This is the whole transitive tree it pulls in: ![image](https://user-images.githubusercontent.com/995917/134737975-8cc2aca3-6b58-488d-b9b5-b6c4906d653f.png) > gradle/verification-metadata.xml line 273: > >> 271: >> 272: >> 273: > > Is `hamcrest` actually required in order to support JUnit 5? If not, this should be reverted. If so, that's another third-party dependency we would need to get approval for. I will try block this and get back to you. > gradle/verification-metadata.xml line 345: > >> 343: >> 344: >> 345: > > Is `opentest4j` actually required in order to support JUnit 5? If not, this should be reverted. If so, that's another third-party dependency we would need to get approval for. Will try block ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Fri Sep 24 21:20:19 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 24 Sep 2021 21:20:19 GMT Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v3] In-Reply-To: References: Message-ID: > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Add copyright header - Remove apiguardian and hamcrest dependencies as not strictly required ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/633/files - new: https://git.openjdk.java.net/jfx/pull/633/files/233fdb80..d0d7969e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=01-02 Stats: 53 lines in 3 files changed: 30 ins; 21 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/633/head:pull/633 PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Fri Sep 24 21:20:21 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 24 Sep 2021 21:20:21 GMT Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:48:26 GMT, John Hendrikx wrote: >> gradle/verification-metadata.xml line 247: >> >>> 245: >>> 246: >>> 247: >> >> Is `apiguardian` actually required in order to support JUnit 5? If not, this should be reverted. If so, that's another third-party dependency we would need to get approval for. > > It's an annotation used within JUnit code, it might be possible to block this one, I will see how to do this in Gradle syntax. > > This is the whole transitive tree it pulls in: > ![image](https://user-images.githubusercontent.com/995917/134737975-8cc2aca3-6b58-488d-b9b5-b6c4906d653f.png) Blocked this one without ill effects, tests still run. >> gradle/verification-metadata.xml line 345: >> >>> 343: >>> 344: >>> 345: >> >> Is `opentest4j` actually required in order to support JUnit 5? If not, this should be reverted. If so, that's another third-party dependency we would need to get approval for. > > Will try block I couldn't block opentest4j. Apparently this is a project that harmonizes the exceptions thrown by various test frameworks (not just JUnit 5) and JUnit 5 depends on it for the exceptions it uses to signal test failures and other error conditions. It is a fairly small project (6 classes only) licensed under the Apache 2.0 license: https://github.com/ota4j-team/opentest4j ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Fri Sep 24 21:20:23 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 24 Sep 2021 21:20:23 GMT Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v3] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:49:00 GMT, John Hendrikx wrote: >> gradle/verification-metadata.xml line 273: >> >>> 271: >>> 272: >>> 273: >> >> Is `hamcrest` actually required in order to support JUnit 5? If not, this should be reverted. If so, that's another third-party dependency we would need to get approval for. > > I will try block this and get back to you. Hamcrest could be blocked, tests still run. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Fri Sep 24 21:20:27 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 24 Sep 2021 21:20:27 GMT Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:36:30 GMT, Kevin Rushforth wrote: >> John Hendrikx has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > modules/javafx.base/src/test/java/test/JUnit5Test.java line 1: > >> 1: package test; > > This needs a copyright header block. Added ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From hjohn at xs4all.nl Fri Sep 24 21:40:26 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Fri, 24 Sep 2021 23:40:26 +0200 Subject: Gauging interest in updating the JavaFX test framework with JUnit 5 Message-ID: Posting this to gauge the interest in adding JUnit 5 as a test dependency to JavaFX, enabling writing tests with this new version of JUnit while still supporting all JUnit 4 tests. A draft PR has been submitted here: https://github.com/openjdk/jfx/pull/633 And an issue has been filed here: https://bugs.openjdk.java.net/browse/JDK-8274274 Although very personally motivated to be able to write nested unit tests in future JavaFX pull requests, I think this would be a great addition to have in our testing arsenal. The main benefits of using JUnit 5: Better integration with Java 8, specifically use of Lambda functions where this would make sense. For example `assertThrows` is really useful and can replace the `expected` parameter in the Test annotation (although this has also been backported to recent JUnit 4 versions). Support for better organization of tests (using Nested) and better naming. See this image to see Nested and naming in action: https://user-images.githubusercontent.com/995917/111858133-d6ce0f80-8936-11eb-9724-be2c15150590.png Better extension system allowing to combine extensions whereas JUnit 4 only allowed one extension at a time. Native support for parameterized tests, repeated tests, nested tests, conditional test execution (by platform or environment for example), assumptions, test generation and timeouts. Please let us know if you'd like to see a newer version of JUnit included in JavaFX to further ease testing :) --John From nlisker at gmail.com Sat Sep 25 07:16:39 2021 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 25 Sep 2021 10:16:39 +0300 Subject: Gauging interest in updating the JavaFX test framework with JUnit 5 In-Reply-To: References: Message-ID: I much prefer JUnit 5 to 4, so I'm in favor. On Sat, Sep 25, 2021 at 12:40 AM John Hendrikx wrote: > Posting this to gauge the interest in adding JUnit 5 as a test > dependency to JavaFX, enabling writing tests with this new version of > JUnit while still supporting all JUnit 4 tests. > > A draft PR has been submitted here: > https://github.com/openjdk/jfx/pull/633 > > And an issue has been filed here: > https://bugs.openjdk.java.net/browse/JDK-8274274 > > Although very personally motivated to be able to write nested unit tests > in future JavaFX pull requests, I think this would be a great addition > to have in our testing arsenal. > > The main benefits of using JUnit 5: > > Better integration with Java 8, specifically use of Lambda functions > where this would make sense. For example `assertThrows` is really useful > and can replace the `expected` parameter in the Test annotation > (although this has also been backported to recent JUnit 4 versions). > > Support for better organization of tests (using Nested) and better > naming. See this image to see Nested and naming in action: > > https://user-images.githubusercontent.com/995917/111858133-d6ce0f80-8936-11eb-9724-be2c15150590.png > > Better extension system allowing to combine extensions whereas JUnit 4 > only allowed one extension at a time. > > Native support for parameterized tests, repeated tests, nested tests, > conditional test execution (by platform or environment for example), > assumptions, test generation and timeouts. > > Please let us know if you'd like to see a newer version of JUnit > included in JavaFX to further ease testing :) > > --John > > > > From kcr at openjdk.java.net Sat Sep 25 13:15:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 25 Sep 2021 13:15:49 GMT Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v3] In-Reply-To: References: Message-ID: <5eXqfRJIOcL37_X6UzSVAFHlKLhakw-6_XzFOIhYUo8=.5fb78ffa-06af-4df5-81eb-5677642abd30@github.com> On Fri, 24 Sep 2021 21:20:19 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add copyright header > - Remove apiguardian and hamcrest dependencies as not strictly required The gradle verification task failed (see the test results from GitHub Actiona). It looks like it still needs the hamcrest jars. Go ahead and add them back in (and remove the exclusion for them). ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Sat Sep 25 13:21:35 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 25 Sep 2021 13:21:35 GMT Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v4] In-Reply-To: References: Message-ID: <95AlDRKqddv_5fQZsudQ5Ir4b6p5utQ3UTDPJYwLRS4=.d61ac3e7-0cc3-4089-ad2a-705f062f38fd@github.com> > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Upgrade to JUnit 4.13.2 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/633/files - new: https://git.openjdk.java.net/jfx/pull/633/files/d0d7969e..df3fd2e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=02-03 Stats: 15 lines in 2 files changed: 13 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/633/head:pull/633 PR: https://git.openjdk.java.net/jfx/pull/633 From kevin.rushforth at oracle.com Sat Sep 25 13:23:39 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 25 Sep 2021 06:23:39 -0700 Subject: Gauging interest in updating the JavaFX test framework with JUnit 5 In-Reply-To: References: Message-ID: <5f018725-c26c-2d18-b068-f0258733703f@oracle.com> I also see advantages in moving to JUnit 5, given that we can still support both JUint 4 and JUnit 5 in the same project using jupiter-vintage (thus avoiding the need to rewrite existing tests). Do any other contributors have experiences with JUnit 5 that they could share? -- Kevin On 9/25/2021 12:16 AM, Nir Lisker wrote: > I much prefer JUnit 5 to 4, so I'm in favor. > > On Sat, Sep 25, 2021 at 12:40 AM John Hendrikx wrote: > >> Posting this to gauge the interest in adding JUnit 5 as a test >> dependency to JavaFX, enabling writing tests with this new version of >> JUnit while still supporting all JUnit 4 tests. >> >> A draft PR has been submitted here: >> https://github.com/openjdk/jfx/pull/633 >> >> And an issue has been filed here: >> https://bugs.openjdk.java.net/browse/JDK-8274274 >> >> Although very personally motivated to be able to write nested unit tests >> in future JavaFX pull requests, I think this would be a great addition >> to have in our testing arsenal. >> >> The main benefits of using JUnit 5: >> >> Better integration with Java 8, specifically use of Lambda functions >> where this would make sense. For example `assertThrows` is really useful >> and can replace the `expected` parameter in the Test annotation >> (although this has also been backported to recent JUnit 4 versions). >> >> Support for better organization of tests (using Nested) and better >> naming. See this image to see Nested and naming in action: >> >> https://user-images.githubusercontent.com/995917/111858133-d6ce0f80-8936-11eb-9724-be2c15150590.png >> >> Better extension system allowing to combine extensions whereas JUnit 4 >> only allowed one extension at a time. >> >> Native support for parameterized tests, repeated tests, nested tests, >> conditional test execution (by platform or environment for example), >> assumptions, test generation and timeouts. >> >> Please let us know if you'd like to see a newer version of JUnit >> included in JavaFX to further ease testing :) >> >> --John >> >> >> >> From jhendrikx at openjdk.java.net Sat Sep 25 13:27:49 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 25 Sep 2021 13:27:49 GMT Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v3] In-Reply-To: <5eXqfRJIOcL37_X6UzSVAFHlKLhakw-6_XzFOIhYUo8=.5fb78ffa-06af-4df5-81eb-5677642abd30@github.com> References: <5eXqfRJIOcL37_X6UzSVAFHlKLhakw-6_XzFOIhYUo8=.5fb78ffa-06af-4df5-81eb-5677642abd30@github.com> Message-ID: On Sat, 25 Sep 2021 13:13:03 GMT, Kevin Rushforth wrote: > The gradle verification task failed (see the test results from GitHub Actiona). It looks like it still needs the hamcrest jars. Go ahead and add them back in (and remove the exclusion for them). Yeah, I noticed, I couldn't get rid of them. Apparently JUnit 4 itself is depending on them now (starting from 4.10 orso) and the Vintage engine requires JUnit 4.12+, so it is actually overriding JUnit 4.8.2 to 4.13.2 and pulls in the Hamcrest jars again. I've tried forcing JUnit to 4.8.2 and even though that works, it leads to a spam stacktrace in the logs for each test executed because it can't find something via reflection. I then tried to hide this log message, but have been unable to find any way of getting that message blocked by configuring java.util.logging that works in combination with Gradle and its daemon. So... I've sort of think this is not a fight we can win easily and have reincluded the Hamcrest jars. I also removed the JUnit 4 dependency as the Vintage engine will pull a newer one in any way. I think I should upgrade these lines as well: `testImplementation group: "junit", name: "junit", version: "4.8.2"` in each of the modules to make it clear 4.13.2 is used and not 4.8.2. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Sat Sep 25 13:55:15 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sat, 25 Sep 2021 13:55:15 GMT Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v5] In-Reply-To: References: Message-ID: > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Readd junit declaration in allprojects and set junit version to 4.13.2 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/633/files - new: https://git.openjdk.java.net/jfx/pull/633/files/df3fd2e3..7d56bcd0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=03-04 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/633/head:pull/633 PR: https://git.openjdk.java.net/jfx/pull/633 From mariushanl at web.de Sat Sep 25 15:57:35 2021 From: mariushanl at web.de (Marius Hanl) Date: Sat, 25 Sep 2021 17:57:35 +0200 Subject: Gauging interest in updating the JavaFX test framework with JUnit 5 In-Reply-To: <5f018725-c26c-2d18-b068-f0258733703f@oracle.com> References: <5f018725-c26c-2d18-b068-f0258733703f@oracle.com> Message-ID: I also really like this move, thanks for that. I have also experience with JUnit 5. And if there is something where I may can help I'm glad to do so. For people who may don't know, this are the features JUnit5 gives us and I'm also excited about: - assertThrows(..) - assertDoesNotThrows(..) -> No more tests without any assert... :) - Parameterized tests are much easier to write and can be mixed with normal tests - We can provide a display name - We can provide better display names for parameterized test - We can decide where the value the parameterized test should use come from, this gives us the ability to have multiple parameterized tests in one class More: [1]https://junit.org/junit5/docs/current/user-guide/#writing-test s-parameterized-tests Example: Hopefully it's ok readable on the mailing list: ----- START ------ @DisplayName("A parameterized test with named arguments") @ParameterizedTest(name = "{0} should match with {1} (lower case)") @MethodSource("initData") void testToLowerCase(String string1, String string2) { assertEquals(string1, string2.toLowerCase()); } static Stream initData() { return Stream.of(of("aaa", "AAA"), of("bbb", "BBB"), of("ccc", "cCc")); } static Arguments of(String string1, String string2) { return Arguments.of(string1, string2); } ----- END------ -- Marius Gesendet: Samstag, 25. September 2021 um 15:23 Uhr Von: "Kevin Rushforth" An: "Nir Lisker" , "John Hendrikx" Cc: "openjfx-dev at openjdk.java.net Mailing" Betreff: Re: Gauging interest in updating the JavaFX test framework with JUnit 5 I also see advantages in moving to JUnit 5, given that we can still support both JUint 4 and JUnit 5 in the same project using jupiter-vintage (thus avoiding the need to rewrite existing tests). Do any other contributors have experiences with JUnit 5 that they could share? -- Kevin On 9/25/2021 12:16 AM, Nir Lisker wrote: > I much prefer JUnit 5 to 4, so I'm in favor. > > On Sat, Sep 25, 2021 at 12:40 AM John Hendrikx wrote: > >> Posting this to gauge the interest in adding JUnit 5 as a test >> dependency to JavaFX, enabling writing tests with this new version of >> JUnit while still supporting all JUnit 4 tests. >> >> A draft PR has been submitted here: >> [2]https://github.com/openjdk/jfx/pull/633 >> >> And an issue has been filed here: >> [3]https://bugs.openjdk.java.net/browse/JDK-8274274 >> >> Although very personally motivated to be able to write nested unit tests >> in future JavaFX pull requests, I think this would be a great addition >> to have in our testing arsenal. >> >> The main benefits of using JUnit 5: >> >> Better integration with Java 8, specifically use of Lambda functions >> where this would make sense. For example `assertThrows` is really useful >> and can replace the `expected` parameter in the Test annotation >> (although this has also been backported to recent JUnit 4 versions). >> >> Support for better organization of tests (using Nested) and better >> naming. See this image to see Nested and naming in action: >> >> [4]https://user-images.githubusercontent.com/995917/111858133-d6ce0f80- 8936-11eb-9724-be2c15150590.png >> >> Better extension system allowing to combine extensions whereas JUnit 4 >> only allowed one extension at a time. >> >> Native support for parameterized tests, repeated tests, nested tests, >> conditional test execution (by platform or environment for example), >> assumptions, test generation and timeouts. >> >> Please let us know if you'd like to see a newer version of JUnit >> included in JavaFX to further ease testing :) >> >> --John >> >> >> >> References 1. https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests 2. https://github.com/openjdk/jfx/pull/633 3. https://bugs.openjdk.java.net/browse/JDK-8274274 4. https://user-images.githubusercontent.com/995917/111858133-d6ce0f80-8936-11eb-9724-be2c15150590.png From johan at lodgon.com Sat Sep 25 17:39:59 2021 From: johan at lodgon.com (Johan Vos) Date: Sat, 25 Sep 2021 19:39:59 +0200 Subject: Gauging interest in updating the JavaFX test framework with JUnit 5 In-Reply-To: References: <5f018725-c26c-2d18-b068-f0258733703f@oracle.com> Message-ID: I agree. The availability of assertThrows and assertDoesNotThrows is already a justification for jUnit 5, imho. - Johan Op za 25 sep. 2021 om 17:58 schreef Marius Hanl : > I also really like this move, thanks for that. > > I have also experience with JUnit 5. > And if there is something where I may can help I'm glad to do so. > > For people who may don't know, this are the features JUnit5 gives > us and I'm also excited about: > - assertThrows(..) > - assertDoesNotThrows(..) > -> No more tests without any assert... :) > > - Parameterized tests are much easier to write and can be mixed with > normal tests > - We can provide a display name > - We can provide better display names for parameterized test > - We can decide where the value the parameterized test should use > come from, > this gives us the ability to have multiple parameterized tests in > one class > > More: [1]https://junit.org/junit5/docs/current/user-guide/#writing-test > s-parameterized-tests > > Example: Hopefully it's ok readable on the mailing list: > ----- START ------ > > @DisplayName("A parameterized test with named arguments") > @ParameterizedTest(name = "{0} should match with {1} (lower case)") > @MethodSource("initData") > void testToLowerCase(String string1, String string2) { > assertEquals(string1, string2.toLowerCase()); > } > > static Stream initData() { > return Stream.of(of("aaa", "AAA"), of("bbb", "BBB"), of("ccc", "cCc")); > } > > static Arguments of(String string1, String string2) { > return Arguments.of(string1, string2); > } > > > ----- END------ > > -- Marius > > Gesendet: Samstag, 25. September 2021 um 15:23 Uhr > Von: "Kevin Rushforth" > An: "Nir Lisker" , "John Hendrikx" > Cc: "openjfx-dev at openjdk.java.net Mailing" > > Betreff: Re: Gauging interest in updating the JavaFX test framework > with JUnit 5 > I also see advantages in moving to JUnit 5, given that we can still > support both JUint 4 and JUnit 5 in the same project using > jupiter-vintage (thus avoiding the need to rewrite existing tests). > Do any other contributors have experiences with JUnit 5 that they could > share? > -- Kevin > On 9/25/2021 12:16 AM, Nir Lisker wrote: > > I much prefer JUnit 5 to 4, so I'm in favor. > > > > On Sat, Sep 25, 2021 at 12:40 AM John Hendrikx > wrote: > > > >> Posting this to gauge the interest in adding JUnit 5 as a test > >> dependency to JavaFX, enabling writing tests with this new version > of > >> JUnit while still supporting all JUnit 4 tests. > >> > >> A draft PR has been submitted here: > >> [2]https://github.com/openjdk/jfx/pull/633 > >> > >> And an issue has been filed here: > >> [3]https://bugs.openjdk.java.net/browse/JDK-8274274 > >> > >> Although very personally motivated to be able to write nested unit > tests > >> in future JavaFX pull requests, I think this would be a great > addition > >> to have in our testing arsenal. > >> > >> The main benefits of using JUnit 5: > >> > >> Better integration with Java 8, specifically use of Lambda functions > >> where this would make sense. For example `assertThrows` is really > useful > >> and can replace the `expected` parameter in the Test annotation > >> (although this has also been backported to recent JUnit 4 versions). > >> > >> Support for better organization of tests (using Nested) and better > >> naming. See this image to see Nested and naming in action: > >> > >> > [4]https://user-images.githubusercontent.com/995917/111858133-d6ce0f80- > 8936-11eb-9724-be2c15150590.png > >> > >> Better extension system allowing to combine extensions whereas JUnit > 4 > >> only allowed one extension at a time. > >> > >> Native support for parameterized tests, repeated tests, nested > tests, > >> conditional test execution (by platform or environment for example), > >> assumptions, test generation and timeouts. > >> > >> Please let us know if you'd like to see a newer version of JUnit > >> included in JavaFX to further ease testing :) > >> > >> --John > >> > >> > >> > >> > > References > > 1. > https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests > 2. https://github.com/openjdk/jfx/pull/633 > 3. https://bugs.openjdk.java.net/browse/JDK-8274274 > 4. > https://user-images.githubusercontent.com/995917/111858133-d6ce0f80-8936-11eb-9724-be2c15150590.png > From fastegal at openjdk.java.net Sun Sep 26 12:01:01 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 26 Sep 2021 12:01:01 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v5] In-Reply-To: References: Message-ID: On Sun, 19 Sep 2021 11:52:55 GMT, Marius Hanl wrote: >> This PR sets an unified logic to every **startEdit()** method of all Cell implementations. >> So startEdit() is always doing the same now: >> >> `super.startEdit();` >> `if (!isEditing()) { >> return; >> }` >> >> This will prevent a NPE while also being cleaner (no more double checks) >> The commits are splitted into 4 base commits: >> - First commit changes the startEdit() for TableCell implementations (8 files) >> - Second commit changes the startEdit() for TreeTableCell implementations (7 files) >> - Third commit changes the startEdit() for ListCell implementations (7 files) >> - Fourth commit changes the startEdit() for TreeCell implementations (7 files) >> >> While writing tests, I found out that the CheckBoxListCell and the CheckBoxTreeCell don't disable their CheckBox, which is wrong. >> In CheckBoxTableCell and CheckBoxTreeTableCell the CheckBox is disabled, but they don't check their dependencies e.g. TableColumn for null, leading to a NPE if not set. >> >> I wrote a follow-up and assigned it to myself: https://bugs.openjdk.java.net/browse/JDK-8270042 >> The aim of this should be, that all 4 CheckBox...Cells have a proper CheckBox disablement while also being nullsafe. >> >> ~Note 1: I removed the tests in TableCellTest added in https://github.com/openjdk/jfx/pull/529 in favor of the new parameterized TableCellStartEditTest~ >> Note 2: This also fixes https://bugs.openjdk.java.net/browse/JDK-8268295 > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments > > - cell is supplied in setup() method > - treeItem = null guard is done before calling startEdit() > - Added checks for the cell graphic fix looks okay now :) Still a bit weary about the tests: personally, I don't like re-using and re-configuring the same instance of an object inside a longish test method (here: in the tight loop). But then, there are other tests in the code base doing it so probably okay here as well. ------------- Marked as reviewed by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/569 From fastegal at openjdk.java.net Sun Sep 26 12:07:58 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Sun, 26 Sep 2021 12:07:58 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v4] In-Reply-To: <01yFJX73YIxKwYhlnmhAqiWnwdPdMvXCepGGTFsjKsU=.f57e3740-fedb-470b-a0ae-262d16980c60@github.com> References: <01yFJX73YIxKwYhlnmhAqiWnwdPdMvXCepGGTFsjKsU=.f57e3740-fedb-470b-a0ae-262d16980c60@github.com> Message-ID: On Sun, 19 Sep 2021 11:24:43 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java line 301: >> >>> 299: return; >>> 300: } >>> 301: >> >> (darn, can't add the important lines - which is backing out if treeItem is null) >> >> The re-ordering leads to change of behavior, here's a test that's passing/failing before/after: >> >> /** >> * change of behavior: cell must not be editing if treeItem == null. >> * fails with fix, passes without >> */ >> @Test >> public void testChoiceBoxTreeCellEditing() { >> TreeView treeView = new TreeView<>(); >> treeView.setEditable(true); >> ChoiceBoxTreeCell cell = new ChoiceBoxTreeCell<>(); >> cell.updateTreeView(treeView); >> cell.updateItem("TEST", false); >> >> cell.startEdit(); >> assertFalse(cell.isEditing()); >> assertNull(cell.getGraphic()); >> } >> >> same for ComboBoxTreeCell > > Hm.. weird that the super class is firing an edit event even with `treeItem = null`. Maybe this should be investigated in a follow-up. Good catch though. :) yeah, there are whacky aspects: - we can switch a cell that's not attached to its surroundings (like table, column, treeItem, off-range) into editing state - the only constraint being that it's not empty - the other way round: a cell that didn't switch into editing will nevertheless fire a editStart on its target Definitely leeway for improvements ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/569 From ebresie at gmail.com Sun Sep 26 19:40:53 2021 From: ebresie at gmail.com (Eric Bresie) Date: Sun, 26 Sep 2021 14:40:53 -0500 Subject: Proof of concept for fluent bindings for ObservableValue In-Reply-To: References: <5c820017-f55d-4737-adce-6c2bc96c8399@Erics-iPhone-12-Pro-Max> Message-ID: I?m no expert here so take it with a grain of salt but? I was proposing moving this sorts of ObservableValue type interfaces and implementations out of jfx (and React) context and into JDK context. Then these sorts of observable type properties/ bindings can be used outside of just UI contexts. Eric On Tue, Sep 21, 2021 at 12:27 PM Nir Lisker wrote: > I'm not sure what you're proposing. Move what, to where, and for what use? > > On Tue, Sep 21, 2021 at 8:02 PM Eric Bresie wrote: > >> I?m very much an Observer here ;-) but >> >> Given the comparisons with FX and React implementations, is there value >> in moving some of this out of here and into the JDK proper context making >> it potentially usable outside of fx or react circles? >> >> I?m reminded of old JDK workings when someone might be working a headless >> application needing a Swing dependency. >> >> Eric Bresie >> Ebresie at gmail.com (mailto:Ebresie at gmail.com) > > >> >> > On September 21, 2021 at 5:36:13 AM CDT, Nir Lisker > (mailto:nlisker at gmail.com)> wrote: >> > > >> > > The OrElseBinding is incorrect >> > > >> > >> > Yes, that was a typo with the order of the arguments in the ternary >> > statement. >> > >> > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I >> > > think the tests would become pretty unreadable and less useful / >> > > thourough otherwise). >> > > >> > > What are the options? >> > > >> > >> > This is a bigger question. Kevin will have to answer that. >> > >> > As for the subscription model: flat map has a more complicated one, but >> > > orElse, orElseGet and map all have the same one. >> > > >> > >> > From what I saw, ReactFX uses a different subscription model for these. >> I >> > could have misread it. >> > >> > The messages will need to be written from the perspective of the Binding >> > > class then IMHO. >> > > >> > >> > That's fine. >> > >> > As for the Optional methods, I'll have a look in my code base and see if >> > the places I would like to use them at will become irrelevant anyway >> with >> > the fluent bindings. I'm fine with proceeding with the current names of >> the >> > proposed methods. >> > >> > On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx > hjohn at xs4all.nl)> wrote: >> > >> > > I need to get you the tests I wrote, unfortunately, they're JUnit 5, >> > > please see the tests here: >> > > >> > > >> > > >> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value >> > > >> > > The OrElseBinding is incorrect, the compute value should read: >> > > >> > > protected T computeValue() { >> > > T value = source.getValue(); >> > > return value == null ? constant : value; >> > > } >> > > >> > > Similar for OrElseGetBinding. >> > > >> > > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I >> > > think the tests would become pretty unreadable and less useful / >> > > thourough otherwise). >> > > >> > > What are the options? >> > > >> > > - Integrate a nested runner (there is an Apache 2.0 licensed one >> available) >> > > - Create our own nested runner (about 200 lines of code) >> > > - Can we introduce JUnit 5? >> > > - Rewrite to plain JUnit 4? >> > > >> > > Let me know, and I can integrate them. >> > > >> > > --John >> > > >> > > On 19/09/2021 02:12, Nir Lisker wrote: >> > > > I've played around with the implementation and pushed a modified >> > > > prototype to the sandbox [1]. I ended up with something similar to >> > > ReactFX: >> > > > the orElse and orElseGet methods have their own binding classes that >> > > > extend LazyObjectBinding, just like MapBinding and FlatMapBinding. >> The >> > > > reason being that both their compute value and their subscription >> models >> > > > are slightly different. While they can be matched to MapBinding >> like you >> > > > did, it entails a bit of a roundabout way in my opinion. Creating a >> > > > supplier for the constant value of orElse somewhat defeats the >> purpose I >> > > > think. >> > > >> > > I have no strong opinion here, just wanted to keep the MR small. The >> > > supplier should be an inline candidate, but creating a separate class >> is >> > > fine too. >> > > >> > > As for the subscription model: flat map has a more complicated one, >> but >> > > orElse, orElseGet and map all have the same one. >> > > >> > > > In addition, I think that it's fine to move the arguments' null >> checks to >> > > > the binding classes themselves, even if it's a couple of levels >> deeper on >> > > > the stack, while adding a message in the 2nd argument of >> > > > Objects.requireNonNull for clarity. These classes are >> "self-contained" so >> > > > it makes sense for them to check their arguments. They might be >> used in >> > > > other places, perhaps in the public Bindings class. >> > > >> > > The messages will need to be written from the perspective of the >> Binding >> > > class then IMHO. >> > > >> > > > I also moved the subscription-related methods from ObservableValue >> to >> > > > static methods in Subscription, at least for now, to defer the API >> > > related >> > > > to Subscription. >> > > >> > > Sounds good. >> > > >> > > > The branch doesn't compile because I didn't finish working on the >> > > > visibility issue, but it's close enough to what I envision it like >> for >> > > the >> > > > first PR. >> > > >> > > I've ported the changes over to my branch and ran the tests on it, >> they >> > > all pass apart from the above mentioned problem in the OrElse >> bindings. >> > > >> > > > As for the java,util.Optional methods, I indeed did something like >> > > > `x.orElse(5).getValue()` in the past in other cases, but this >> approach >> > > > creates a new binding just to get the wrapped value out, which is >> very >> > > > inefficient. (In one case I did booleanValue.isNull().get(), which >> > > creates >> > > > a boolean binding, because isPresent() does not exist). I would >> like to >> > > see >> > > > what others think about the Optional methods, The binding method >> variants >> > > > are much more important, but I want to avoid a name clash if the >> Optional >> > > > ones will have support. >> > > >> > > Okay, some more things to consider: >> > > >> > > ObservableValue is not an Optional, their get methods respond >> > > differently with Optional#get throwing an exception when null -- the >> > > #orElse is a necessity; this is not the case for >> ObservableValue#getValue. >> > > >> > > When creating mapping chains, you are going to do this because you >> want >> > > to bind this to another property or to listen on it (with subscribe). >> > > You don't want to do this as a one time thing. If you are creating a >> > > chain just to calculate a value you can just do this directly. >> Instead of: >> > > >> > > widthProperty().map(x -> x * 2).getValue() >> > > >> > > You'd do: >> > > >> > > getWidth() * 2; >> > > >> > > With flat mapping however this is not as easy: >> > > >> > > [1] >> > > node.sceneProperty() >> > > .flatMap(Scene::windowProperty) >> > > .flatMap(Window::showingProperty) >> > > .orElse(false); >> > > >> > > You could try: >> > > >> > > node.getScene().getWindow().isShowing(); >> > > >> > > But that will not work when Scene or Window is null. You'd have to >> > > write it as: >> > > >> > > [2] >> > > Optional.ofNullable(node.getScene()) >> > > .map(Scene::getWindow) >> > > .map(Window::isShowing) >> > > .orElse(false); >> > > >> > > If you only offer a "specialized" orElse, you'd still need to create >> > > several bindings: >> > > >> > > [3] >> > > node.sceneProperty() >> > > .flatMap(Scene::windowProperty) >> > > .flatMap(Window::showingProperty) >> > > .orElse2(false); // orElse which returns a value not a binding >> > > >> > > If you compare [2] (which is possible now) with [3] the difference is >> > > minimal. A bit more ceremony at the start for [2] but a shorter, >> cleaner >> > > and faster mapping (no bindings and no need to use the property >> methods). >> > > >> > > Now, if you already HAVE the binding for some other purpose, then it >> is >> > > highly likely it also already has an #orElse that is needed as part of >> > > the binding. In that case calling #getValue is fine without much need >> > > for another #orElse variant. >> > > >> > > --John >> > > >> > > > >> > > > [1] >> > > > >> > > >> https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings >> > > > >> > > > On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx > (mailto:hjohn at xs4all.nl)> wrote: >> > > > >> > > > > >> > > > > >> > > > > On 15/09/2021 02:28, Nir Lisker wrote: >> > > > > > Sorry, I'm not quite sure what you mean by this. Could you >> > > elaborate? >> > > > > > The methods orElse and orElseGet are present in the PoC, and I >> > > think >> > > > > > they're highly useful to have to deal with nulls. >> > > > > > >> > > > > > >> > > > > > The methods that you call orElse and orElseGet return an >> > > > > > ObservableValue. The Optional methods with the same names >> return the >> > > > > > wrapped value (of type T). For comparison, ReactFX has: >> > > > > > T getOrElse(T defaultValue) >> > > > > > T getOrSupply(Supplier defaultSupplier) >> > > > > > Val orElseConst(T other) >> > > > > > Val orElse(ObservableValue other) >> > > > > >> > > > > I see what you mean now. The methods from java.util.Optional will >> return >> > > > > an unwrapped value, while the ones from ObservableValue in the PoC >> > > > > return an ObservableValue, but they have the same name. >> > > > > >> > > > > So java.util.Optional offers: >> > > > > >> > > > > T orElse(T other) >> > > > > T orElseGet(Supplier supplier) >> > > > > >> > > > > And the PoC: >> > > > > >> > > > > ObservableValue orElse(T alternativeValue) >> > > > > ObservableValue orElseGet(Supplier supplier) >> > > > > >> > > > > The main difference is in the returned types. Personally, I think >> it is >> > > > > rarely useful for a binding to be queried directly and I've never >> used >> > > > > the #getOrElse or #getOrSupply variants that ReactFX offers. On >> top of >> > > > > that: >> > > > > >> > > > > x.orElse(5).getValue() === x.getOrElse(5) >> > > > > >> > > > > So it introduces another method in the interface to avoid having >> to >> > > > > write ".getValue()". The opposite, introducing only the >> "unwrapped" >> > > > > variants would still require the "wrapped" variants to be present >> as >> > > well. >> > > > > >> > > > > So, what I would suggest is to not add variants for #getOrElse and >> > > > > #getOrSupply at all as they are of questionable value and would >> just >> > > > > bloat the API for a bit less typing. In that case I think we can >> still >> > > > > use the signatures as they are. >> > > > > >> > > > > ReactFX also offers: >> > > > > >> > > > > Val orElse(ObservableValue other) >> > > > > >> > > > > This is another rarely used feature IMHO, and I think Optional#or >> would >> > > > > a better match for this functionality: >> > > > > >> > > > > Optional or(Supplier> supplier) >> > > > > >> > > > > In the POC the signature would be: >> > > > > >> > > > > ObservableValue or( >> > > > > Supplier> supplier >> > > > > ) >> > > > > >> > > > > I didn't implement this one in the PoC to keep it small, but I did >> > > > > implement this in my JavaFX EventStream library before. >> > > > > >> > > > > > So it deals with both getting the wrapped value in null cases >> and with >> > > > > > getting a "dynamic value" in null cases. I find the >> Optional-like >> > > method >> > > > > > 'T getOrElse(T defaultValue)' useful (along with others such as >> > > > > > ifPresent because Optional is just useful for dealing with >> wrapped >> > > > > > values). What I'm saying is that we should be careful with the >> names if >> > > > > > we include both "constant" and "dynamic" versions of >> 'orElse'-like >> > > > > methods. >> > > > > >> > > > > I think #ifPresent can be added, not so sure about the usefulness >> of >> > > > > #getOrElse (see above). >> > > > > >> > > > > > The null check in ReactFX's #computeValue is >> > > > > > actually checking the result of the mapping function, not >> whether >> > > the >> > > > > > function instance itself was null. >> > > > > > >> > > > > > I didn't mean the null-ness of the map argument. What I meant >> was that >> > > > > > there is this implementation, which is similar to what ReactFX >> does: >> > > > > >> > > > > Sorry, I see it now. You have a good point, the current >> implementation >> > > > > indeed wraps another Lambda to add the null check which could >> have been >> > > > > done in #computeValue. I think it would be a good move to avoid >> the >> > > > > extra lambda simply because the end result would be more readable >> -- any >> > > > > performance improvement would be a bonus, I don't know if there >> will be >> > > > > any. >> > > > > >> > > > > > As for my points 3 and 4, I'll have to try and play with the >> > > > > > implementation myself, which will be easier to do when there is >> some PR >> > > > > > in the works. >> > > > > >> > > > > Perhaps this is useful: >> > > > > >> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx >> > > > > >> > > > > When you add this as a maven dependency to your project, you will >> get >> > > > > the new PoC functionality. It basically uses the Maven shade >> plugin to >> > > > > replace a few classes in javafx-base -- I use this sometimes to >> fix bugs >> > > > > I need fixed immediately by patching jfx, but found it also works >> very >> > > > > nicely to experiment with this PoC. >> > > > > >> > > > > Also, the PoC PR compiles fine, it may need rebasing. >> > > > > >> > > > > > To close "Bindings.select*(): add new type-safe template based >> API >> > > > > > instead of legacy-style set of methods" we'd need the >> > > flatMap/select >> > > > > > method to be included. >> > > > > > >> > > > > > Yes. I think that we can include flatMap in this iteration, >> perhaps as >> > > > > > a separate PR? >> > > > > >> > > > > That should be no problem, I can split it up. >> > > > > >> > > > > > I don't think we really need specialized methods for primitives >> (or >> > > > > at >> > > > > > least, not right away). At this point the primitive versions >> only >> > > > > > really differ in what value they'd return if the binding would >> be >> > > > > null >> > > > > > and perhaps they do a little less boxing/unboxing. Since you can >> > > > > select >> > > > > > the default value with #orElse which is more flexible. I don't >> see >> > > > > much >> > > > > > use to add those variants. >> > > > > > >> > > > > > I agree, I would avoid bloating the primitive specialization >> classes >> > > for >> > > > > > now, especially when Valhalla is planned to take care of those. >> > > > > >> > > > > Yes, I think we can easily do without for now. >> > > > > >> > > > > > The ticket is a bit unclear as I can't see what type "x" is. >> > > > > > >> > > > > > Yes, but I got the impression that either way it can be solved >> with map >> > > > > > (or flatMap). >> > > > > >> > > > > Agreed. >> > > > > >> > > > > --John >> > > > > >> > > > >> > > >> > -- Eric Bresie ebresie at gmail.com From john at status6.com Mon Sep 27 02:12:49 2021 From: john at status6.com (John Neffenger) Date: Sun, 26 Sep 2021 19:12:49 -0700 Subject: CFV: New OpenJFX Committer: Thiago Sayao In-Reply-To: References: Message-ID: <6b01b151-2781-ad90-2d4e-df34d44dad2e@status6.com> Vote: YES Just in time, John On 9/13/21 7:37 AM, Kevin Rushforth wrote: > I hereby nominate Thiago Sayao [1] to OpenJFX Committer. > > Thiago is an OpenJFX community member, who has contributed 15 commits > [2] to OpenJFX. > > Votes are due by September 27, 2021 at 15:00 UTC. > > Only current OpenJFX Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. Nomination to a project > Committer is described in [6]. > > Thanks. > > -- Kevin > > > [1] https://openjdk.java.net/census#tsayao > > [2] > https://github.com/openjdk/jfx/search?q=author-name%3A%22Thiago+Sayao%22&s=author-date&type=commits > > > [3] https://openjdk.java.net/census#openjfx > > [4] https://openjdk.java.net/bylaws#lazy-consensus > > [6] https://openjdk.java.net/projects#project-committer From rlichten at openjdk.java.net Mon Sep 27 05:21:05 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 27 Sep 2021 05:21:05 GMT Subject: RFR: 8274137: TableView scrollbar/header misaligned when reloading data [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 11:22:22 GMT, Kevin Rushforth wrote: >> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274137: TableView scrollbar/header misaligned when reloading data >> >> Alternative fix using additional listeners instead of removing >> optimization. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3194: > >> 3192: } >> 3193: >> 3194: @Override > > The added `@Override` annotations are unrelated to your fix. Can you please revert them? By trying to make eclipse remove trailing whitespace I've accidentally activated the "Add missing Annotations" option :-(. Will remove them and update the PR ... ------------- PR: https://git.openjdk.java.net/jfx/pull/629 From rlichten at openjdk.java.net Mon Sep 27 05:27:25 2021 From: rlichten at openjdk.java.net (Robert Lichtenberger) Date: Mon, 27 Sep 2021 05:27:25 GMT Subject: RFR: 8274137: TableView scrollbar/header misaligned when reloading data [v3] In-Reply-To: References: Message-ID: > This PR fixes JDK-8274137 by removing the optimization from updateHbar() that will no-op the method in case the VirtualFlow is invisible or currently has no scene. > Since changes to the hBar's value can happen even if the VirtualFlow is not currently visible, the synchronisation between hBar and clipX must happen all the time. > > A test agains VirtualFlow has been added that will fail before the change and pass afterwards. Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision: 8274137: TableView scrollbar/header misaligned when reloading data Remove @Override annotations unrelated to fix. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/629/files - new: https://git.openjdk.java.net/jfx/pull/629/files/03bcd0f3..20156784 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=629&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=629&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/629.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/629/head:pull/629 PR: https://git.openjdk.java.net/jfx/pull/629 From mariushanl at web.de Mon Sep 27 09:41:40 2021 From: mariushanl at web.de (Marius Hanl) Date: Mon, 27 Sep 2021 11:41:40 +0200 Subject: JavaFX snapping and scale Message-ID: I recently tried to fix "TableView: visual glitch at borders on horizontal scrolling". Ticket: [1]https://bugs.openjdk.java.net/browse/JDK-8218745 PR: [2]https://github.com/openjdk/jfx/pull/630 As also written in the PR I have problems understanding the snapping/scaling of JavaFX. Here in short what I found out: - Snapping fixed the issue for a scale of 1 or 2, but not for a scale like 1.25 or 1.5 --- Also VirtualFlow is the only occurence where we set the layoutX of a clip (might be the problem?) - This visual glitch only happens sometimes when the x value is a decimal number, e.g. 12.66 (never when it's a round number like 13) - Math.round(..) or a cast to int fixed this (for all scales), but is probably not the correct solution or maybe only fixing a symptom here Which leads to my question where may some of you can help me: - How does JavaFX renders a node when e.g. x is a decimal number? How many pixel are used then? - And does a decimal number make sense (Why we e.g. don't round the value), which looks like it works fine and doesn't result in visual glitches Also information/insights about fixes made in the past which relates with this are welcome. I saw that there were quite some issues with a scale other then 1 in the past. Note: If the result is that everything works as expected chances are there might a generic problem with snapping/layout/rendering somewhere then. Any information are welcome and feel free to also have a look at the PR. -- Marius References 1. https://bugs.openjdk.java.net/browse/JDK-8218745 2. https://github.com/openjdk/jfx/pull/630 From aghaisas at openjdk.java.net Mon Sep 27 10:58:17 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 27 Sep 2021 10:58:17 GMT Subject: RFR: 8231644: TreeTableView Regression: Indentation wrong using Label as column content type [v3] In-Reply-To: <24XaRxgrUri2EYi_cdS5y1i3BljInwnBafxkvC7EgLg=.bd3b0dc8-c70b-49b9-a2d5-d1dc9aa3eb9f@github.com> References: <44hbYPKwJb2SX19CjpWQT7Lz64EQzz8o3znV6m5VDcQ=.3eb1a2de-d633-4547-aeee-279757cce7f1@github.com> <24XaRxgrUri2EYi_cdS5y1i3BljInwnBafxkvC7EgLg=.bd3b0dc8-c70b-49b9-a2d5-d1dc9aa3eb9f@github.com> Message-ID: On Tue, 27 Jul 2021 05:45:50 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue with the TreeTableView indentation. >> >> ![image](https://user-images.githubusercontent.com/66004280/124681647-473e7380-dec9-11eb-906d-4228fc39cbf9.png) >> >> In short: >> **TreeTableCellSkin** overrides **leftLabelPadding()** to calculate the indentation (the result of this method is added to **x**). >> While this is fine, this method is not always called (by **LabeledSkinBase#layoutLabelInArea**), e.g. when no text is set. >> So when a TreeTableCell only sets a graphic (e.g. via **setGraphic()** in **updateItem()**), the indentation will be messed up. >> >> Fixed this by adding the calculated indentation to **x** before we call **layoutChildren()**. >> >> We also need/should adjust every other location where `leftLabelPadding()` was used: >> - **computePrefHeight** -> prefWidth() is always called with -1, so nothing got broken by not overriding this, but we should do it of course to be accurate in case we do one day. >> - **computePrefWidth** -> this is needed for auto sizing. I saw that it was slightly off without, so this 100% needed. >> - **computeMinWidth** -> the min width of a cell is not used, so nothing got broken by not overriding this but same as in computePrefHeight(), we should comply with the specs. >> - **layoutChildren** -> I saw a slight off sizing if the indentation is not subtracted to the width. >> >> As a result of this, all method do effectively the same as they did with an overridden `leftLabelPadding()` (just earlier/later and always now of course). >> Note: I also added some tests which pass before and pass after. > > 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 8231644-indentation > >  Conflicts: >  modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableCellSkin.java > - calculated indentation in every method now which was previously done via leftLabelPadding > - 8231644: fixed wrong indentation for tree cells with graphic only Marked as reviewed by aghaisas (Reviewer). > > Overall the fix looks ok. The new test fails without the fix and passes with it. > > Can you please confirm the test programs provided in 2 duplicated bugs of JDK-8231644 also work as expected with this fix? > > Just tried them. They both work fine. :) > > Overall the fix looks ok. The new test fails without the fix and passes with it. > > Can you please confirm the test programs provided in 2 duplicated bugs of JDK-8231644 also work as expected with this fix? > > Just tried them. They both work fine. :) That's great! ------------- PR: https://git.openjdk.java.net/jfx/pull/568 From aghaisas at openjdk.java.net Mon Sep 27 10:58:18 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 27 Sep 2021 10:58:18 GMT Subject: RFR: 8231644: TreeTableView Regression: Indentation wrong using Label as column content type [v3] In-Reply-To: <10hR53GHD2_CRTnyxXzBP6wBNZxn0diFusDejp_4U-g=.b84736bb-331e-43b8-9fd9-1735977c4dd5@github.com> References: <44hbYPKwJb2SX19CjpWQT7Lz64EQzz8o3znV6m5VDcQ=.3eb1a2de-d633-4547-aeee-279757cce7f1@github.com> <24XaRxgrUri2EYi_cdS5y1i3BljInwnBafxkvC7EgLg=.bd3b0dc8-c70b-49b9-a2d5-d1dc9aa3eb9f@github.com> <10hR53GHD2_CRTnyxXzBP6wBNZxn0diFusDejp_4U-g=.b84736bb-331e-43b8-9fd9-1735977c4dd5@github.com> Message-ID: On Fri, 24 Sep 2021 16:32:26 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableCellSkin.java line 127: >> >>> 125: double leftInset) { >>> 126: if (isDeferToParentForPrefWidth) { >>> 127: return super.computePrefWidth(height, topInset, rightInset, bottomInset, leftInset) + calculateIndentation(); >> >> If we are deferring to Parent for the preferred width, then we need not add indentation. >> I think, we should interchange line 127 and line 130. > > No that's actually correct as it is. > > That is because when a cell is deferred from the parent we want to know the width we need without being truncated. For now that is only set when the auto size of the table is triggered (see also: **TableColumnHeader#resizeColumnToFitContent**). > > And if not deferred, the width of the cell is in sync with the column (you can also that in the super class -> **super.computePrefWidth(..)**) OK. Thanks for the explanation. ------------- PR: https://git.openjdk.java.net/jfx/pull/568 From kevin.rushforth at oracle.com Mon Sep 27 16:19:21 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 27 Sep 2021 09:19:21 -0700 Subject: Result: New OpenJFX Committer: Thiago Sayao Message-ID: Voting for Thiago Sayao [1] to OpenJFX Committer [2] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.java.net/census#tsayao [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-September/031963.html From kcr at openjdk.java.net Mon Sep 27 17:10:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Sep 2021 17:10:17 GMT Subject: [jfx11u] RFR: 8274107: Cherry pick GTK WebKit 2.32.4 changes Message-ID: <7egte0t67IaPFHyCET5ZhRke0FMsu--j3Qr58hCMYRE=.c8e6bf23-bd01-431c-9a04-8dab71697f0b@github.com> Clean backport to `jfx11u` of WebKit GTK 2.32.4 fixes. ------------- Commit messages: - 8274107: Cherry pick GTK WebKit 2.32.4 changes Changes: https://git.openjdk.java.net/jfx11u/pull/54/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=54&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274107 Stats: 1811 lines in 131 files changed: 1043 ins; 205 del; 563 mod Patch: https://git.openjdk.java.net/jfx11u/pull/54.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/54/head:pull/54 PR: https://git.openjdk.java.net/jfx11u/pull/54 From kcr at openjdk.java.net Mon Sep 27 17:11:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Sep 2021 17:11:13 GMT Subject: [jfx17u] RFR: 8274107: Cherry pick GTK WebKit 2.32.4 changes Message-ID: Clean backport to `jfx17u` of WebKit GTK 2.32.4 fixes. ------------- Commit messages: - 8274107: Cherry pick GTK WebKit 2.32.4 changes Changes: https://git.openjdk.java.net/jfx17u/pull/13/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=13&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274107 Stats: 1811 lines in 131 files changed: 1043 ins; 205 del; 563 mod Patch: https://git.openjdk.java.net/jfx17u/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/13/head:pull/13 PR: https://git.openjdk.java.net/jfx17u/pull/13 From kcr at openjdk.java.net Mon Sep 27 17:22:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Sep 2021 17:22:08 GMT Subject: [jfx17u] Integrated: 8274107: Cherry pick GTK WebKit 2.32.4 changes In-Reply-To: References: Message-ID: On Mon, 27 Sep 2021 16:59:37 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u` of WebKit GTK 2.32.4 fixes. This pull request has now been integrated. Changeset: 90a7c28c Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/90a7c28c6143242c4b6d349e6259c962553bb92f Stats: 1811 lines in 131 files changed: 1043 ins; 205 del; 563 mod 8274107: Cherry pick GTK WebKit 2.32.4 changes Backport-of: 478512b705af840cd9f658b22f272165bc1c1bc3 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/13 From kcr at openjdk.java.net Mon Sep 27 17:22:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 27 Sep 2021 17:22:10 GMT Subject: [jfx11u] Integrated: 8274107: Cherry pick GTK WebKit 2.32.4 changes In-Reply-To: <7egte0t67IaPFHyCET5ZhRke0FMsu--j3Qr58hCMYRE=.c8e6bf23-bd01-431c-9a04-8dab71697f0b@github.com> References: <7egte0t67IaPFHyCET5ZhRke0FMsu--j3Qr58hCMYRE=.c8e6bf23-bd01-431c-9a04-8dab71697f0b@github.com> Message-ID: On Mon, 27 Sep 2021 16:59:42 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u` of WebKit GTK 2.32.4 fixes. This pull request has now been integrated. Changeset: 070c2435 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/070c243590d3082ba3e0bf1a4673de058715ae98 Stats: 1811 lines in 131 files changed: 1043 ins; 205 del; 563 mod 8274107: Cherry pick GTK WebKit 2.32.4 changes Backport-of: 478512b705af840cd9f658b22f272165bc1c1bc3 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/54 From kevin.rushforth at oracle.com Mon Sep 27 23:57:06 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 27 Sep 2021 16:57:06 -0700 Subject: JavaFX snapping and scale In-Reply-To: References: Message-ID: The basic idea behind snapping to pixel boundaries (which is optional, but on by default) is that 2D primitives will look more crisp if they are rendered on whole pixel boundaries. When there is no HiDPI involved, the operation of snapping to a pixel boundary can be done with a simple floor, round, or ceil operation (depending on what you are snapping). When there is a HIDPI scale involved, the value in user space needs to be chosen such that the transformed value ends up on a pixel boundary. That's why you will see snapped values that aren't on integer boundaries when the HiDPI scale is, say 1.25. In the case you ran into, the problem might be that the snapping isn't happening in the right place in the computation. Also, it seems quite possible that the clipping isn't being calculated correctly with respect to pixel snapping. You can take a look at JDK-8211294 [1] which was fixed by PR #308 [2] for a recent example of a HiDPI bug affecting ScrollPane that was fixed. There are a couple of follow-on issues that came out of that issue, although I suspect they aren't relevant to the bug you are looking at. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8211294 [2] https://github.com/openjdk/jfx/pull/308 On 9/27/2021 2:41 AM, Marius Hanl wrote: > I recently tried to fix "TableView: visual glitch at borders on > horizontal scrolling". > Ticket: [1]https://bugs.openjdk.java.net/browse/JDK-8218745 > PR: [2]https://github.com/openjdk/jfx/pull/630 > > As also written in the PR I have problems understanding the > snapping/scaling of JavaFX. > Here in short what I found out: > - Snapping fixed the issue for a scale of 1 or 2, but not for a scale > like 1.25 or 1.5 > --- Also VirtualFlow is the only occurence where we set the layoutX of > a clip (might be the problem?) > - This visual glitch only happens sometimes when the x value is a > decimal number, e.g. 12.66 (never when it's a round number like 13) > - Math.round(..) or a cast to int fixed this (for all scales), but is > probably not the correct solution or maybe only fixing a symptom here > > Which leads to my question where may some of you can help me: > - How does JavaFX renders a node when e.g. x is a decimal number? How > many pixel are used then? > - And does a decimal number make sense (Why we e.g. don't round the > value), which looks like it works fine and doesn't result in visual > glitches > > Also information/insights about fixes made in the past which relates > with this are welcome. > I saw that there were quite some issues with a scale other then 1 in > the past. > > Note: If the result is that everything works as expected chances are > there might a generic problem with snapping/layout/rendering somewhere > then. > Any information are welcome and feel free to also have a look at the > PR. > > -- Marius > > References > > 1. https://bugs.openjdk.java.net/browse/JDK-8218745 > 2. https://github.com/openjdk/jfx/pull/630 From fkirmaier at openjdk.java.net Tue Sep 28 10:01:59 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 28 Sep 2021 10:01:59 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v5] In-Reply-To: References: Message-ID: > When using Swing it's possible to generate a Deadlock. > It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. > Sample Programm and Threaddump are added to the ticket. > > Removing the nested loop fixes the Problem. > I hope this doesn't have any side effect - so far i don't know of any. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8273485 Fixed Beep sound when closing a fullscreen window ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/622/files - new: https://git.openjdk.java.net/jfx/pull/622/files/8bee7a41..b8bf1a44 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/622.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/622/head:pull/622 PR: https://git.openjdk.java.net/jfx/pull/622 From fkirmaier at openjdk.java.net Tue Sep 28 10:05:03 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 28 Sep 2021 10:05:03 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v4] In-Reply-To: References: <_qrnVf27DezSXoUj2DOc3PxhzNXFyJyspVlI0L2qEqw=.82287feb-4c82-4ee2-aaf7-e0fecd356e7f@github.com> Message-ID: On Fri, 17 Sep 2021 12:51:53 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8273485 >> small cleanup of the changes. > > You can also see the exception with _any_ JavaFX program: enter full-screen with the green button, move the mouse to the upper-left corner to reveal the window decorations, and press the red button to exit the program. > > I think you need to look for a different solution to your deadlock, one that preserves the existing nested event loop. @kevinrushforth Did you test really test my change and was able to reproduce the JDK-8126842 with it? On my system everything works - except the small "beep" sound. After investigating it, I've made another small change - which fixes the beep sound. It also makes it closer to the implementation for iOS. I've changed the `waitUntilDone` value to true, when closing the window. I think removing the nestedEventLoops should be preferred over another fix - in my experience the nested event loops are the cause of so many rare and very complicated bugs. ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From fastegal at openjdk.java.net Tue Sep 28 10:11:24 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 28 Sep 2021 10:11:24 GMT Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v4] In-Reply-To: References: <01yFJX73YIxKwYhlnmhAqiWnwdPdMvXCepGGTFsjKsU=.f57e3740-fedb-470b-a0ae-262d16980c60@github.com> Message-ID: On Sun, 26 Sep 2021 12:05:11 GMT, Jeanette Winzenburg wrote: > the other way round: a cell that didn't switch into editing will nevertheless fire a editStart on its target FYI: filed [JDK-8274433](https://bugs.openjdk.java.net/browse/JDK-8274433) ------------- PR: https://git.openjdk.java.net/jfx/pull/569 From fkirmaier at openjdk.java.net Tue Sep 28 12:07:36 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 28 Sep 2021 12:07:36 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v6] In-Reply-To: References: Message-ID: > When using Swing it's possible to generate a Deadlock. > It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. > Sample Programm and Threaddump are added to the ticket. > > Removing the nested loop fixes the Problem. > I hope this doesn't have any side effect - so far i don't know of any. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8273485 removed the toggle fullscreen before closing - to avoid the beep and improve the user experience ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/622/files - new: https://git.openjdk.java.net/jfx/pull/622/files/b8bf1a44..e263f379 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/622.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/622/head:pull/622 PR: https://git.openjdk.java.net/jfx/pull/622 From fkirmaier at openjdk.java.net Tue Sep 28 12:15:30 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 28 Sep 2021 12:15:30 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v6] In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 12:07:36 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273485 > removed the toggle fullscreen before closing - to avoid the beep and improve the user experience I've just noticed that I've missed to commit a change, to prevent the beep - which I've now added. The changes I've now committed also have another welcome side effects: JavaFX behaves more like "normal" Mac apps. Before: - Animation out of fullscreen - Closing the window Now: - Closing the window This is how other mac applications behave - and should probably therefore be preferred. I've tested it with apps like Finder, Textedit, Chrome, Safari. ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From mpaus at openjdk.java.net Tue Sep 28 16:13:59 2021 From: mpaus at openjdk.java.net (Michael Paus) Date: Tue, 28 Sep 2021 16:13:59 GMT Subject: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT Message-ID: Fixes the issue by using the "open" command as discussed before. See: https://bugs.openjdk.java.net/browse/JDK-8214158 ------------- Commit messages: - Remove dependency on java.awt.Desktop Changes: https://git.openjdk.java.net/jfx/pull/634/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=634&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8214158 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/634.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/634/head:pull/634 PR: https://git.openjdk.java.net/jfx/pull/634 From kcr at openjdk.java.net Tue Sep 28 17:10:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 28 Sep 2021 17:10:37 GMT Subject: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 16:06:30 GMT, Michael Paus wrote: > Fixes the issue by using the "open" command as discussed before. > See: https://bugs.openjdk.java.net/browse/JDK-8214158 This seems like a good RFE. I have a couple overall questions. First, calling `open` was originally proposed in the since-abandoned Draft PR javafxports/openjdk-jfx#310. As I wrote there: > One thing of note is that the AWT code, which we are currently calling, uses a native method to call LSOpenURLsWithRole rather than "exec"-ing a new process from Java. I'm not sure why (maybe the open command wasn't as robust when it was implemented? Or maybe there is some benefit to using LSOpenURLsWithRole?), but we will need to make sure that there isn't a regression in behavior as a result." Can you comment on this? Second, can you provide a manual test for this? I was thinking something that would go somewhere under `tests/manual` and when run, provide an option to open one of two or three different file types (e.g., a `.txt` file and a `.html` file) that are also checked in to the same dir as the test program. It could use `FIle::toURI` or similar to construct the URI string. ------------- PR: https://git.openjdk.java.net/jfx/pull/634 From mpaus at openjdk.java.net Tue Sep 28 17:22:33 2021 From: mpaus at openjdk.java.net (Michael Paus) Date: Tue, 28 Sep 2021 17:22:33 GMT Subject: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 16:06:30 GMT, Michael Paus wrote: > Fixes the issue by using the "open" command as discussed before. > See: https://bugs.openjdk.java.net/browse/JDK-8214158 First of all. Shall I follow the bot request above and create a new pull request? Wouldn't we loose the discussion here then? ------------- PR: https://git.openjdk.java.net/jfx/pull/634 From mpaus at openjdk.java.net Tue Sep 28 18:05:31 2021 From: mpaus at openjdk.java.net (Michael Paus) Date: Tue, 28 Sep 2021 18:05:31 GMT Subject: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 16:06:30 GMT, Michael Paus wrote: > Fixes the issue by using the "open" command as discussed before. > See: https://bugs.openjdk.java.net/browse/JDK-8214158 To answer your questions: 1. I have no idea about LSOpenURLsWithRole. I am not a Mac developer. 2. I have manually tested the change: Button showHtml = new Button("HTML"); showHtml.setOnAction(e -> {this.getHostServices().showDocument(new File("data/test.html").toURI().toString());}); Button showTxt = new Button("TXT"); showTxt.setOnAction(e -> {this.getHostServices().showDocument(new File("data/test.txt").toURI().toString());}); Button showCsv = new Button("CSV"); showCsv.setOnAction(e -> {this.getHostServices().showDocument(new File("data/test.csv").toURI().toString());}); The code fragment above reliably opens the HTML document in Firefox (my default browser), the text document in BBEdit (my default text editor) and the CSV document in LibreOffice (my default Excel :-) This also works if you just use the plain strings without conversion to an URI. Here are the printed Java/FX version strings for completness: java.runtime.version: 18-ea+16-926 javafx.runtime.version: 18-internal+0-2021-09-28-174132 ------------- PR: https://git.openjdk.java.net/jfx/pull/634 From github.com+12087024+beldenfox at openjdk.java.net Tue Sep 28 21:07:01 2021 From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox) Date: Tue, 28 Sep 2021 21:07:01 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout Message-ID: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` but `getKeyCodeForChar("+")` generated `KeyCode.PLUS`. In this PR `getKeyCodeForChar` mirrors the behavior of `get_glass_key`; it determines which key the character lies on and generates a key code based on the unshifted character on the same key. I'm working on a more comprehensive test case that allows you to press any key on the keyboard and test whether a KeyCharacterCombination for that character will succeed or not. I've attached it to this thread. It might be worth submitting as a manual test case [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) . ------------- Commit messages: - Query the current keyboard layout and key to correctly respond to getKeyCodeForChar. Changes: https://git.openjdk.java.net/jfx/pull/635/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=635&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273743 Stats: 82 lines in 1 file changed: 63 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jfx/pull/635.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/635/head:pull/635 PR: https://git.openjdk.java.net/jfx/pull/635 From alessandro.parisi406 at gmail.com Tue Sep 28 22:04:00 2021 From: alessandro.parisi406 at gmail.com (Alessandro Parisi) Date: Wed, 29 Sep 2021 00:04:00 +0200 Subject: RFR: 8267606: Style classes not always working Message-ID: Can we have a look at this report please? I'm having this issue more and more often when making custom controls JBS From mariushanl at web.de Tue Sep 28 22:12:53 2021 From: mariushanl at web.de (Marius Hanl) Date: Wed, 29 Sep 2021 00:12:53 +0200 Subject: =?UTF-8?Q?Aw=3A=C2=A0RFR=3A_8267606=3A_Style_classes_not_always_working?= In-Reply-To: References: Message-ID: It would be very helpful if you could provide a minimum reproducable example. So really just the code which is necessary for all of us to reproduce it. Am 29.09.21, 00:06 schrieb Alessandro Parisi : Can we have a look at this report please? I'm having this issue more and more often when making custom controls JBS <[1]https://bugs.openjdk.java.net/browse/JDK-8267606> References 1. https://bugs.openjdk.java.net/browse/JDK-8267606 From hjohn at xs4all.nl Tue Sep 28 22:46:43 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 29 Sep 2021 00:46:43 +0200 Subject: Transparent stages and AnimationTimer on Windows Message-ID: <5948baf5-312d-c50b-9467-2ab1e5532047@xs4all.nl> I'm seeing some really weird issues with Transparent Stages on Windows when their framerate (both stability and speed) is compared with normal decorated/undecorated stages. The transparent stages seem to obey different rules when it comes to timely firing AnimationTimers. Where a decorated stage will show an almost exact 60 Hz in all circumstances (usually in a pattern of 24 frames of ~15ms then a double frame of ~30ms averaging out to 1/60th of a second per frame) the transparent stages act completely different. Increasing the javafx.animation.pulse on a decorated stage to say 240 will reduce this variance even further (min/max will be between 16 and 18 ms) while keeping an exact 60 Hz. However, on a transparent stage this all goes out the window: Running a test with javafx.animation.pulse left unchanged, it reaches an unsteady 56/57 Hz with the variance being incredibly high and random (5 - 40 ms)... while FOCUSED. Unfocusing the stage and this becomes a more steady 62.5 Hz and the variance reduces to 8 - 24 ms. Refocusing the stage immediately sees variance spiking again and framerate dropping to an unsteady 56/57 Hz. The same test with javafx.animation.pulse set to 240 on a transparent stage shows some odd things as well. While focused the stage retains a similar behaviour (unsteady 56/57 Hz with a 5-40 ms variance). When unfocused it starts running at 72-78 Hz with about an 8-24 ms variance (same as before but with a higher frame rate). Setting javafx.animation.pulse to 24 for a transparent stage locks the framerate to an exact 24 Hz with almost no variance. Focused/unfocused suddenly makes no difference any more. For decorated/undecorated stages this does not change the framerate (it remains rock solid at 60 Hz) but the variances become much larger (but show a steady repeated pattern). So in summary: 1) Decorated/undecorated stages perform very stable, variance can be reduced by increasing javafx.animation.pulse -- this property seems to have the effect of making the animation timings more accurate (reduces variance) while retaining an exact 60 Hz. The variance pattern is very consistent and predictable. 2) Transparent stages perform much more erratic, and are extra erratic when they have focus. They never reach an exact 60 Hz (measured over 300 frames) but either go several frames under (57.5 Hz when focused) or over (62.5 Hz when not focused). Their variance has no pattern to it and seems random. 3) javafx.animation.pulse for Transparent stages seems to control the maximum frame rate (setting it to 24 for example will limit the fps to almost exactly 24 Hz with almost no variance). Below is the code I used to test this. --John public class FrameRateTest extends Application { private static int SIZE = 300; @Override public void start(Stage stage) { System.out.println("javafx.runtime.version: " + System.getProperties().get("javafx.runtime.version")); Label fpsLabel = new Label(); fpsLabel.setTextFill(Color.ALICEBLUE); Canvas canvas = new Canvas(SIZE, 100); GraphicsContext g2d = canvas.getGraphicsContext2D(); g2d.setStroke(Color.WHITE); StackPane fpsPane = new StackPane(fpsLabel, canvas); AnimationTimer frameRateMeter = new AnimationTimer() { private final long[] frameTimes = new long[SIZE]; private final long[] frameDeltas = new long[SIZE]; private int frameTimeIndex = 0; private int elementsFilled = 0; private long then = System.nanoTime(); @Override public void handle(long now) { long oldFrameTime = frameTimes[frameTimeIndex - elementsFilled % SIZE]; long delta = now - then; frameTimes[frameTimeIndex] = now; frameDeltas[frameTimeIndex] = delta; frameTimeIndex = (frameTimeIndex + 1) % frameTimes.length; if(elementsFilled < SIZE) { elementsFilled++; } long elapsedNanos = now - oldFrameTime; long elapsedNanosPerFrame = elapsedNanos / elementsFilled; double frameRate = 1_000_000_000.0 / elapsedNanosPerFrame; double min = Double.MAX_VALUE; double max = 0; for(int i = 0; i < elementsFilled; i++) { min = Math.min(min, frameDeltas[i]); max = Math.max(max, frameDeltas[i]); } GraphicsContext g2d = canvas.getGraphicsContext2D(); g2d.clearRect(frameTimeIndex, 0, 1, 100); g2d.strokeLine(frameTimeIndex, 100, frameTimeIndex, 100 - (delta) / 1000000.0); fpsLabel.setText(String.format(" %.1f/%.1f ms - %.1f fps", min / 1000000.0, max / 1000000.0, frameRate)); then = now; } }; frameRateMeter.start(); fpsPane.setBackground(new Background(new BackgroundFill(Color.BLACK, CornerRadii.EMPTY, Insets.EMPTY))); Scene scene = new Scene(fpsPane); scene.setFill(Color.BLACK); stage = new Stage(StageStyle.TRANSPARENT); stage.setWidth(1500); stage.setHeight(1500); stage.setScene(scene); stage.show(); } public static void main(String[] args) { launch(args); } } From alessandro.parisi406 at gmail.com Wed Sep 29 10:47:17 2021 From: alessandro.parisi406 at gmail.com (Alessandro Parisi) Date: Wed, 29 Sep 2021 12:47:17 +0200 Subject: RFR: 8267606: Style classes not always working Message-ID: > > It would be very helpful if you could provide a minimum reproducable > example. So really just the code which is necessary for all of us to > reproduce it. Oh wow, what happened on JBS, there should be the projects files attached, did Praveen forget to upload them? Do I re-send additional information? What should I do? For now, here's the link to download the project: Google Drive Explanation and info on how to test: The project has changed a bit, now there's a third example and the JavaFX version has been updated to 17. All examples can be run by modifying the Launcher class. CSS files are in the resources folder and loaded by a ResourceManager. 1) The first example is TableTest. The main files for this test are TableViewSkin and TableView.css. The table has a HBox which contains the columns, from the CSS the bottom border is set to be 'lightgray'. The test is set up to succeed initially. However, if you go in the skin class and switch the ID for a style class, update the CSS file accordingly (.custom-table-view .columns-container) you'll see that the bottom border is not styled anymore. Both the second and third examples are about the userAgentStylesheet which doesn't behave correctly. 2) Let's start with the NotificationsTest first. The main files are MFXNotificationCenter, MFXNotificationCenterSkin and NotificationCenter.css. The icon shown in the StackPane comes from the NotificationsCounter class (inner class of the skin). The icon should be big and gray. The test is set to succeed initially. Let's take a look at the MFXNotificationCenter class, at the bottom you'll see that I commented the getUserAgentStylesheet() method and instead of using that I added a this call 'getStylesheets().add(STYLESHEET);' in the initialize() method. If you invert this (uncomment the user agent method and remove this call) you'll notice that the icon is not styled anymore. Now let's check the skin class, check lines 31-109-212. If you comment the latter one you'll see that the icon is styled again. The other lines have no visible effect for this test but in the real control I must add them too, otherwise not everything is styled. 3) The last example is the ToggleTest. This shows the exact same issue described above but the structure/control is simplier. The example is set to fail initially. If you run it you can see that the label has a black line underneath which would be normal but the issue is that in the MFXRectangleToggleNode.css (at the bottom of the file) the lines are set to be transparent, the background too. To make it work, go into the skin class (MFXRectangleToggleNodeSkin) uncomment the indicated line and it will work. Another workaround is like I did above, instad of using the user agent, add the stylesheet with 'getStylesheets().add(STYLESHEET);' From kcr at openjdk.java.net Wed Sep 29 11:53:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 29 Sep 2021 11:53:47 GMT Subject: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 17:19:38 GMT, Michael Paus wrote: > First of all. Shall I follow the bot request above and create a new pull request? Wouldn't we loose the discussion here then? As long as you don't otherwise need to update your `master` branch, you can wait to reset it until after this PR is integrated. If you prefer to create a new branch and a new PR, then you could link to the discussion. I'll leave it up to you. > I have no idea about LSOpenURLsWithRole. I am not a Mac developer. I think calling `Runtime::exec("open", uri)` is fine. It matches the behavior on Windows and Linux. I'll do some testing, but I don't anticipate any problems. > I have manually tested the change. In that case, can you create a new manual test as part of this PR? I recommend a new directory: `tests/manual/desktop/HostServices` (my thinking is that `tests/manual/desktop` could eventually include tests for `FileChooser` or other similar manual tests). I'm open to other names as well. You can look at `tests/manual/web/InputTypeAcceptAttributeTest.java` for an example of a good manual test. I recommend adding at least a `.txt` and a `.html` file. You can hard-code the filenames so you don't need to use a `FileChooser`. ------------- PR: https://git.openjdk.java.net/jfx/pull/634 From kevin.rushforth at oracle.com Wed Sep 29 12:07:01 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 29 Sep 2021 05:07:01 -0700 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> <9e5e7704-5f6e-5fcd-6ffb-4bc67e9ff5c8@oracle.com> Message-ID: <8d14fe5a-febf-adab-5090-f392a119dea0@oracle.com> Absent a strong motivation for adding this, I recommend to go with the current proposal, which does not include this newly requested method. It can always be added later if there is a compelling need. -- Kevin On 9/24/2021 4:50 AM, Nir Lisker wrote: > I don't have a strong opinion on this addition. > > On Fri, Sep 24, 2021 at 2:47 PM Kevin Rushforth > > wrote: > > I don't have an objection to adding this one additional convenience > method if it is generally useful. If there aren't a lot of > applications > that would use it, it seems better to go with just the two > identified so > far and consider this one later. > > So: would this be a generally useful addition? > > -- Kevin > > > On 9/21/2021 2:43 AM, Marius Hanl wrote: > >? ? ?As also written in a comment > >? ? ?here: https://github.com/openjdk/jfx/pull/610 > > >? ? ?I would like to propose one more convenience method which > should be > >? ? ?added to JavaFX: > > > > public static Border stroke(Paint stroke, double width) { > >? ? ? return new Border(new BorderStroke(stroke, > BorderStrokeStyle.SOLID, null, ne > > w BorderWidths(width))); > > } > > > >? ? ?I think it's quite common that you want to create a solid > border with > >? ? ?another width then the default of 1 (for every side). > > > >? ? ?Note: This is also the last use case I think makes sense to > add as a > >? ? ?convenience method. > >? ? ?Any other use case is likely to be so complex that it makes > sense to > >? ? ?use the normal existing constructors. > > > >? ? ?Feel free to share you opinion. > > > >? ? ?- Marius > > > >? ? ?Gesendet: Dienstag, 08. Juni 2021 um 03:19 Uhr > >? ? ?Von: "Nir Lisker" > > >? ? ?An: "Kevin Rushforth" > > >? ? ?Cc: "openjfx-dev at openjdk.java.net > Mailing" > >? ? ? > > >? ? ?Betreff: Re: [External] : Re: Convenience factories for > Border and > >? ? ?Background > >? ? ?The new API: > >? ? ?1. `Border.of(Paint stroke)` or `Border.stroke(Paint > stroke)` that does > >? ? ?`new Border(new BorderStroke(Paint stroke , > BorderStrokeStyle.SOLID, > >? ? ?null, > >? ? ?null));` > >? ? ?2. `Background.of((Paint fill)` or `Background.fill(Paint > fill)` that > >? ? ?does > >? ? ?`new Background(new BackgroundFill(Paint fill, null, null));` > >? ? ?I don't mind either name choice. > >? ? ?On Tue, Jun 8, 2021 at 2:50 AM Kevin Rushforth > >? ? ?> > >? ? ?wrote: > >? ? ?> If I recall, there were a few developers that chimed in. > It's a > >? ? ?simple > >? ? ?> enough addition -- at least your original proposal (not the > >? ? ?suggestion of > >? ? ?> mirroring the Color API, which I don't like) -- that it > seems OK to > >? ? ?me. > >? ? ?> > >? ? ?> Can you repost your currently proposed API and see if > those who might > >? ? ?like > >? ? ?> to use it are satisfied with it? > >? ? ?> > >? ? ?> -- Kevin > >? ? ?> > >? ? ?> > >? ? ?> On 6/7/2021 4:41 PM, Nir Lisker wrote: > >? ? ?> > >? ? ?> Does this constitute sufficient interest in the enhancement? > >? ? ?> > >? ? ?> On Thu, May 13, 2021 at 6:41 PM Michael Strau? > >? ? ?> > >? ? ?> wrote: > >? ? ?> > >? ? ?>> Another option could be to mirror the `Color` API in both > `Border` > >? ? ?and > >? ? ?>> `Background`, like in the following examples: > >? ? ?>> > >? ? ?>> Color.rgb(125, 100, 75) > >? ? ?>> Border.rgb(125, 100, 75) > >? ? ?>> Background.rgb(125, 100, 75) > >? ? ?>> > >? ? ?>> Color.gray(127) > >? ? ?>> Border.gray(127) > >? ? ?>> Background.gray(127) > >? ? ?>> > >? ? ?>> Color.web("orange", 0.5) > >? ? ?>> Border.web("orange", 0.5) > >? ? ?>> Background.web("orange", 0.5) > >? ? ?>> > >? ? ?>> We could also mirror the named color constants, which > would enable a > >? ? ?>> very compact syntax: > >? ? ?>> > >? ? ?>> StackPane pane = new StackPane(); > >? ? ?>> pane.setBorder(Border.RED); > >? ? ?>> pane.setBackground(Background.BLUE); > >? ? ?>> > >? ? ?>> This is very similar to how "red" or "blue" are valid > values for > >? ? ?>> "-fx-border" or "-fx-background" in CSS. > >? ? ?>> > >? ? ?> > >? ? ?> > From kevin.rushforth at oracle.com Wed Sep 29 12:33:36 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 29 Sep 2021 05:33:36 -0700 Subject: RFR: 8267606: Style classes not always working In-Reply-To: References: Message-ID: <8cb08cfc-9ff1-7eab-ddc5-a05c7db52ea8@oracle.com> I can see the original submission you sent (and yes, Praveen didn't attach it). I can attach it, but I have a question about it. Also, it will need some modifications before we can take a look at it. 1. There are differences between the one you originally sent and the one pointed two in your google drive project below. Which version would you like attached to the JBS bug? 2. We really need a self-contained test program, without using gradle or maven to download any artifacts. There should be no dependencies on any external libraries / jar files / etc. We need to be able to build it from source, pointing to a local build of JavaFX, in order to debug it (so we don't need any .class files or .jar files in the zip bundle). -- Kevin On 9/29/2021 3:47 AM, Alessandro Parisi wrote: >> It would be very helpful if you could provide a minimum reproducable >> example. So really just the code which is necessary for all of us to >> reproduce it. > > Oh wow, what happened on JBS, there should be the projects files attached, > did Praveen forget to upload them? > > Do I re-send additional information? What should I do? > For now, here's the link to download the project: Google Drive > > > Explanation and info on how to test: > > The project has changed a bit, now there's a third example and the JavaFX > version has been updated to 17. > > All examples can be run by modifying the Launcher class. > CSS files are in the resources folder and loaded by a ResourceManager. > > 1) The first example is TableTest. The main files for this test are > TableViewSkin and TableView.css. > The table has a HBox which contains the columns, from the CSS the > bottom border is set to be 'lightgray'. The test is set up to succeed > initially. However, if you go in the skin class and switch the ID for a > style class, update the CSS file accordingly (.custom-table-view > .columns-container) you'll see that the bottom border is not styled anymore. > > Both the second and third examples are about the userAgentStylesheet which > doesn't behave correctly. > > 2) Let's start with the NotificationsTest first. The main files are > MFXNotificationCenter, MFXNotificationCenterSkin and NotificationCenter.css. > The icon shown in the StackPane comes from the NotificationsCounter class > (inner class of the skin). The icon should be big and gray. The test is set > to succeed initially. Let's take a look at the MFXNotificationCenter class, > at the bottom you'll see that I commented the getUserAgentStylesheet() > method and instead of using that I added a this call > 'getStylesheets().add(STYLESHEET);' in the initialize() method. If you > invert this (uncomment the user agent method and remove this call) you'll > notice that the icon is not styled anymore. Now let's check the skin class, > check lines 31-109-212. If you comment the latter one you'll see that the > icon is styled again. The other lines have no visible effect for this test > but in the real control I must add them too, otherwise not everything is > styled. > > 3) The last example is the ToggleTest. This shows the exact same issue > described above but the structure/control is simplier. The example is set > to fail initially. If you run it you can see that the label has a black > line underneath which would be normal but the issue is that in the > MFXRectangleToggleNode.css (at the bottom of the file) the lines are set to > be transparent, the background too. To make it work, go into the skin class > (MFXRectangleToggleNodeSkin) uncomment the indicated line and it will work. > Another workaround is like I did above, instad of using the user agent, add > the stylesheet with 'getStylesheets().add(STYLESHEET);' From nlisker at gmail.com Wed Sep 29 12:42:04 2021 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 29 Sep 2021 15:42:04 +0300 Subject: [External] : Re: Convenience factories for Border and Background In-Reply-To: <8d14fe5a-febf-adab-5090-f392a119dea0@oracle.com> References: <03abd0f8-eff6-481a-bb8e-ba2e99dc04ce@oracle.com> <9e5e7704-5f6e-5fcd-6ffb-4bc67e9ff5c8@oracle.com> <8d14fe5a-febf-adab-5090-f392a119dea0@oracle.com> Message-ID: Then the PR is ready for a final review. I'll create the CSR shortly. On Wed, Sep 29, 2021 at 3:07 PM Kevin Rushforth wrote