bound property

Minor: Our typical pattern for example code is:

     * {@code
     * code sample
     * ...
     * }

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From kcr at openjdk.java.net  Fri Jul  9 23:07:59 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 9 Jul 2021 23:07:59 GMT
Subject: [jfx17] RFR: 8268642: Expand the javafx.beans.property.Property
 documentation [v2]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 24 Jun 2021 01:17:55 GMT, Nir Lisker  wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes as per review
>
> modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 120:
> 
>> 118: 
>> 119:     /**
>> 120:      * Removes a bidirectional binding that was established with {@link #bindBidirectional(Property)}.
> 
> "the" (it's possible to have multiple bidi bindings, but only 1 to the same `other` property).

Agreed.

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From mstrauss at openjdk.java.net  Sat Jul 10 01:47:51 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 10 Jul 2021 01:47:51 GMT
Subject: [jfx17] RFR: 8268642: Expand the javafx.beans.property.Property
 documentation [v2]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 9 Jul 2021 22:17:21 GMT, Kevin Rushforth  wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes as per review
>
> modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 111:
> 
>> 109:      * established. However, doing so is not a meaningful use of this API, because the
>> 110:      * unidirectionally bound property will cause any attempt to change the value of any of
>> 111:      * the properties to fail with an exception.
> 
> I don't think this quite matches the implementation. What I've observed is:
> 
> * If a unidirectional binding already exists for this property, calling this method to attempt to establish a bidirectional binding will immediately cause an exception to happen.
> * If a bidirectional binding already exists (as a result of calling this method), subsequently calling the bind() method to set up a unidirectional binding seems to "partially" remove the bidirectional binding. Setting the other bidirectionally bound property no longer updates this property, but setting this (or the newly bound property) does set the other bidirectionally bound property. I very much doubt we want to specify this, though.
> 
> More to the point, what we want to convey is that a property should not be both bound unidirectionally and bidirectionally. So I'd like to see a stronger "don't do that" sort of statement. The docs should state that an application should not call this method if a unidirectional binding already exists for either `this` property or the `other` property (rather than saying that it's possible, but discouraged or not meaningful). I think it would be fine to say that it is likely to cause an exception. 
> 
> Similarly, the docs for `bind` should say something about not calling that method if `this` property is bidirectionally bound to any other property.

Maybe we could simply the mental model of the property specification by making it illegal in all cases to use unidirectional and bidirectional bindings at the same time. The specification would be reduced to "it's illegal", instead of having a long explanation that says it's only _likely_ to cause an exception.

Most attempts to use both kinds of bindings will fail with an exception anyway. Some will fail instantly when calling `bindBidirectional`, some will fail later when calling `setValue`. Some will fail more silently because the exception will happen inside `BidirectionalBinding` and not bring down the application. Only a kind-of-exotic situation will not produce exceptions at all (the situation that you described in the second bullet point).

If we were to always fail instantly at the point of calling `bind` or `bindBidirectional`, we would make the misuse of this API visible where it's most relevant, instead of failing later in other parts of the codebase.

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From nlisker at openjdk.java.net  Sat Jul 10 12:36:51 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Sat, 10 Jul 2021 12:36:51 GMT
Subject: [jfx17] RFR: 8268642: Expand the javafx.beans.property.Property
 documentation [v2]
In-Reply-To: 
References: 

Message-ID: <5jf-IsKqtzwQhnhAZtc4BkD8AJ4qPfLboeyfULkHjm8=.f273f877-7004-4511-9917-911fa8d538b3@github.com>

On Sat, 10 Jul 2021 01:44:43 GMT, Michael Strau?  wrote:

>> modules/javafx.base/src/main/java/javafx/beans/property/Property.java line 111:
>> 
>>> 109:      * established. However, doing so is not a meaningful use of this API, because the
>>> 110:      * unidirectionally bound property will cause any attempt to change the value of any of
>>> 111:      * the properties to fail with an exception.
>> 
>> I don't think this quite matches the implementation. What I've observed is:
>> 
>> * If a unidirectional binding already exists for this property, calling this method to attempt to establish a bidirectional binding will immediately cause an exception to happen.
>> * If a bidirectional binding already exists (as a result of calling this method), subsequently calling the bind() method to set up a unidirectional binding seems to "partially" remove the bidirectional binding. Setting the other bidirectionally bound property no longer updates this property, but setting this (or the newly bound property) does set the other bidirectionally bound property. I very much doubt we want to specify this, though.
>> 
>> More to the point, what we want to convey is that a property should not be both bound unidirectionally and bidirectionally. So I'd like to see a stronger "don't do that" sort of statement. The docs should state that an application should not call this method if a unidirectional binding already exists for either `this` property or the `other` property (rather than saying that it's possible, but discouraged or not meaningful). I think it would be fine to say that it is likely to cause an exception. 
>> 
>> Similarly, the docs for `bind` should say something about not calling that method if `this` property is bidirectionally bound to any other property.
>
> Maybe we could simply the mental model of the property specification by making it illegal in all cases to use unidirectional and bidirectional bindings at the same time. The specification would be reduced to "it's illegal", instead of having a long explanation that says it's only _likely_ to cause an exception.
> 
> Most attempts to use both kinds of bindings will fail with an exception anyway. Some will fail instantly when calling `bindBidirectional`, some will fail later when calling `setValue`. Some will fail more silently because the exception will happen inside `BidirectionalBinding` and not bring down the application. Only a kind-of-exotic situation will not produce exceptions at all (the situation that you described in the second bullet point).
> 
> If we were to always fail instantly at the point of calling `bind` or `bindBidirectional`, we would make the misuse of this API visible where it's most relevant, instead of failing later in other parts of the codebase.

The following unit test demonstrated the *current* behavior, though maybe it's not the desired one:

import static org.junit.Assert.*;

import javafx.beans.property.IntegerProperty;
import javafx.beans.property.SimpleIntegerProperty;

import org.junit.Before;
import org.junit.Test;

public class BindingsTest {

	private IntegerProperty property1, property2, property3;

	@Before
	public void setup() {
		property1 = new SimpleIntegerProperty(1);
		property2 = new SimpleIntegerProperty(2);
		property3 = new SimpleIntegerProperty(3);
	}

	@Test
	public void testBidiAndThenUni() {
		property1.bindBidirectional(property2);
		assertEquals(2, property1.get());
		assertEquals(2, property2.get());
		property1.bind(property3);
		assertEquals(3, property1.get());
		assertEquals(3, property2.get());
		assertEquals(3, property3.get());
	}

	@Test(expected = RuntimeException.class)
	public void setProperty1() {
		property1.bindBidirectional(property2);
		property1.bind(property3);

		property1.set(4);
	}

	@Test
	public void setProperty2() {
		property1.bindBidirectional(property2);
		property1.bind(property3);

		// ignores exception (but still prints stack trace) at
		// com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
		property2.set(5);
		assertEquals(3, property1.get());
		assertEquals(3, property2.get()); // "Bidirectional binding failed, setting to the previous value"
		assertEquals(3, property3.get());
	}

	@Test
	public void setProperty3() {
		property1.bindBidirectional(property2);
		property1.bind(property3);

		property3.set(6);
		assertEquals(6, property1.get());
		assertEquals(6, property2.get());
		assertEquals(6, property3.get());
	}

	@Test(expected = RuntimeException.class)
	public void testUniAndThenBidiOnBound() {
		property1.bind(property3);
		property1.bindBidirectional(property2);
	}

	@Test
	public void testUniAndThenBidiOnUnbound() {
		property1.bind(property3);
		property2.bindBidirectional(property1);

		assertEquals(3, property1.get());
		assertEquals(3, property2.get());
		assertEquals(3, property3.get());
	}
}

My observations:

* `setProperty2()` is weird in that it throws an exception internally which is ignored by the JVM, and then reverts the change to the unidirectionally unbound property when it finds out that its counterpart can't be changed. It makes sense logically, but I don't see a valid use case for this.
* `setProperty3()` behaves as I expect it to, but this is effectively 2 chained unidirectional binds: `property3` changes `property1` which changes `property2`. This is the same as `testUniAndThenBidiOnUnbound()`.

It would make sense to disallow this mixing of bindings on grounds that this is probably not what the developer wants to do. If we opt to let them do it but write that it should not be done, we could emit a warning. I'm leaning towards to fail-fast approach.

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From tsayao at openjdk.java.net  Sat Jul 10 16:06:18 2021
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Sat, 10 Jul 2021 16:06:18 GMT
Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window
 behaves correctly [v3]
In-Reply-To: 
References: 
Message-ID: 

> The PR approach is to set  `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows.
> 
> This is passed on WindowStage.java:198 as a mask.
> 
> The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Remove unneeded test for modal

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/551/files
  - new: https://git.openjdk.java.net/jfx/pull/551/files/612a61ea..f7d2a9dd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=551&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=551&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/551.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/551/head:pull/551

PR: https://git.openjdk.java.net/jfx/pull/551

From tsayao at openjdk.java.net  Sat Jul 10 16:06:19 2021
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Sat, 10 Jul 2021 16:06:19 GMT
Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window
 behaves correctly [v2]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 9 Jul 2021 18:41:11 GMT, Kevin Rushforth  wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reuse existing set_modal (which was previously unused).
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1436:
> 
>> 1434:             gtk_window_set_transient_for(GTK_WINDOW(gtk_widget), parent->get_gtk_window());
>> 1435:         } else {
>> 1436:             gtk_window_set_keep_above(GTK_WINDOW(gtk_widget), modal ? TRUE : FALSE);
> 
> The test of `modal` is unnecessary here, since this is all within an `if (modal)` block.

Done.

-------------

PR: https://git.openjdk.java.net/jfx/pull/551

From mhanl at openjdk.java.net  Sun Jul 11 18:09:50 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Sun, 11 Jul 2021 18:09:50 GMT
Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit
In-Reply-To: 
References: 

Message-ID: 

On Fri, 9 Jul 2021 10:51:16 GMT, Jeanette Winzenburg  wrote:

> > Do we wanna create follow-ups for this, so this PR won''t get any bigger? That would be at least my preference.
> > Right now I see:
> > ```
> > * !isEditing check in cancelEdit() (we can return directly)
> > 
> > * isEditing check in startEdit() (we can return directly)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Is there more?
> 
> 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. 
If there is nothing left, should I create a ticket for `startEdit` and for `cancelEdit` (this only affects the sub classes) ? :)

-------------

PR: https://git.openjdk.java.net/jfx/pull/569

From mhanl at openjdk.java.net  Sun Jul 11 18:30:52 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Sun, 11 Jul 2021 18:30:52 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v4]
In-Reply-To: <6wPykr1TUU8yQzpmU9ZIk93DJP-FOZzGY8KcTZt8918=.73a813e7-091f-4faf-92e4-7168113b0458@github.com>
References: 

 <91fcb06ADbxWngHhQAleXNlvbZJ2szifQ1jkYXZkAkk=.fae2ad28-0816-447a-8c15-1f554287819b@github.com>
 <6vkoeD3UL4p0WrAH0fLfsJUS1tAZXoZGDCLmzmFhw2s=.59810ed0-9833-4636-ab22-b2a3a31d00a6@github.com>
 <6wPykr1TUU8yQzpmU9ZIk93DJP-FOZzGY8KcTZt8918=.73a813e7-091f-4faf-92e4-7168113b0458@github.com>
Message-ID: <2lIO7TwOxtjFEU0uuUfcV7anitTbc_N1BhE054Q4nyI=.7aed22e5-c4fd-470d-83c7-55e4779db102@github.com>

On Fri, 9 Jul 2021 09:58:38 GMT, Jeanette Winzenburg  wrote:

>> Hmm, but leaving a test without an assert is also bad. You have any suggestions?
>> I may can add another editable test, which will pass before and after.
>
>> 
>> 
>> Hmm, but leaving a test without an assert is also bad. You have any suggestions?
> 
> Not aware of such a rule - if we fix code throwing an exception there is not much to assert, except that it fails before and passes after. And paddling back a bit, I think a separate test for the back switch would be overdoing it :) 
> 
>          @Test 
>          ...
>          // configure: just as you do
>          comboBox.setEditable(true)
>          ...
>          // the test: just as you do - switch to false
>          comboBox.setEditable(false)
>          // safe-guard against future implementation changes: switch back to true
>          comboBox.setEditable(true)
>          // end of test

There is no rule, but in my opinion it is also not a good practise. 
I agree it's also not a big problem, but in general a test should check something. 
And I think it's not a problem to check, that we still have no value inside ComboBox, even though is not really related. 

In JUnit 5, there would be `assertDoesNotThrow?()` for that usecase. But I may found a solution for our version, there is  `@Test(expected = Test.None.class)`, which basically tells us explicitly, that we don't expect any exception (and so, the code under test did throw an exception one time in the past).

-------------

PR: https://git.openjdk.java.net/jfx/pull/557

From jpereda at openjdk.java.net  Mon Jul 12 12:52:04 2021
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Mon, 12 Jul 2021 12:52:04 GMT
Subject: RFR: 8269374: Menu inoperable after setting stage to second monitor
Message-ID: 

On Windows, with two monitors with different DPI settings, if a JavaFX application changes screens (either by dragging or programmatically) there is a resize event to adjust the view to its new platform scale.

Note that there is already a [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java#L206) to `View::updateLocation` in WinWindow, right after `notifyMoveToAnotherScreen` and `notifyScaleChanged `. But this is done too soon, before the resize event. There are other MOVE events processed too (in a long complex chain of recursive calls to `WinWindow::setBounds`).

As a consequence, as commented in the issue [JDK-8269374](https://bugs.openjdk.java.net/browse/JDK-8269374), the view x/y coordinates are wrongly set using the _old_ X,Y values (from the previous screen) with the _new_ platform scale (from the new screen).

This PR adds an extra call to View::updateLocation` in WinWindow, forcing the view relocation on Windows after every resize event to fix the issue. With the correct location of the scene, the Menus are now perfectly aligned, and the mouse events are correctly processed. It doesn't have any side effect on other platforms.

There's a very small penalty, as this new relocation will be called whenever there is a resize event on Windows, but it simplifies the overhead of detecting when the change of screens is effectively done (including the chain of move/resize) events.

No tests are provided, since these would require a setup of two monitors with different DPI settings. However, the test case in the JBS issue can be used to validate the fix.

-------------

Commit messages:
 - Use public method
 - Force view relocation on Windows after a resize event

Changes: https://git.openjdk.java.net/jfx/pull/572/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=572&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/jfx/pull/572.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/572/head:pull/572

PR: https://git.openjdk.java.net/jfx/pull/572

From fastegal at openjdk.java.net  Mon Jul 12 12:52:09 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 12 Jul 2021 12:52:09 GMT
Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit
In-Reply-To: 
References: 

Message-ID: 

On Sun, 11 Jul 2021 18:06:52 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?

-------------

PR: https://git.openjdk.java.net/jfx/pull/569

From fastegal at openjdk.java.net  Mon Jul 12 12:58:58 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 12 Jul 2021 12:58:58 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v4]
In-Reply-To: <2lIO7TwOxtjFEU0uuUfcV7anitTbc_N1BhE054Q4nyI=.7aed22e5-c4fd-470d-83c7-55e4779db102@github.com>
References: 

 <91fcb06ADbxWngHhQAleXNlvbZJ2szifQ1jkYXZkAkk=.fae2ad28-0816-447a-8c15-1f554287819b@github.com>
 <6vkoeD3UL4p0WrAH0fLfsJUS1tAZXoZGDCLmzmFhw2s=.59810ed0-9833-4636-ab22-b2a3a31d00a6@github.com>
 <6wPykr1TUU8yQzpmU9ZIk93DJP-FOZzGY8KcTZt8918=.73a813e7-091f-4faf-92e4-7168113b0458@github.com>
 <2lIO7TwOxtjFEU0uuUfcV7anitTbc_N1BhE054Q4nyI=.7aed22e5-c4fd-470d-83c7-55e4779db102@github.com>
Message-ID: 

On Sun, 11 Jul 2021 18:28:24 GMT, Marius Hanl  wrote:

>>> 
>>> 
>>> Hmm, but leaving a test without an assert is also bad. You have any suggestions?
>> 
>> Not aware of such a rule - if we fix code throwing an exception there is not much to assert, except that it fails before and passes after. And paddling back a bit, I think a separate test for the back switch would be overdoing it :) 
>> 
>>          @Test 
>>          ...
>>          // configure: just as you do
>>          comboBox.setEditable(true)
>>          ...
>>          // the test: just as you do - switch to false
>>          comboBox.setEditable(false)
>>          // safe-guard against future implementation changes: switch back to true
>>          comboBox.setEditable(true)
>>          // end of test
>
> There is no rule, but in my opinion it is also not a good practise. 
> I agree it's also not a big problem, but in general a test should check something. 
> And I think it's not a problem to check, that we still have no value inside ComboBox, even though is not really related. 
> 
> In JUnit 5, there would be `assertDoesNotThrow?()` for that usecase. But I may found a solution for our version, there is  `@Test(expected = Test.None.class)`, which basically tells us explicitly, that we don't expect any exception (and so, the code under test did throw an exception one time in the past).

agree to all that makes the test code easier to read/understand, the JUnit 5 looks good :) Your solution for JU4 isn't really easier to understand .. but could be only me, or simple enough to get used to.

Just: adding an assert that basically asserts nothing or the wrong (because unspecified) thing is .. worse than a test that's hard to read, IMO

-------------

PR: https://git.openjdk.java.net/jfx/pull/557

From fastegal at openjdk.java.net  Mon Jul 12 13:04:00 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 12 Jul 2021 13:04:00 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v4]
In-Reply-To: <6vkoeD3UL4p0WrAH0fLfsJUS1tAZXoZGDCLmzmFhw2s=.59810ed0-9833-4636-ab22-b2a3a31d00a6@github.com>
References: 

 <91fcb06ADbxWngHhQAleXNlvbZJ2szifQ1jkYXZkAkk=.fae2ad28-0816-447a-8c15-1f554287819b@github.com>
 <6vkoeD3UL4p0WrAH0fLfsJUS1tAZXoZGDCLmzmFhw2s=.59810ed0-9833-4636-ab22-b2a3a31d00a6@github.com>
Message-ID: 

On Thu, 8 Jul 2021 21:05:51 GMT, Marius Hanl  wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java line 324:
>> 
>>> 322: 
>>> 323:         comboBox.layout();
>>> 324: 
>> 
>> KISS again :)
>> 
>> - buttonCell is unrelated
>> - setting the value is a not immediately obvious trigger of the NPE
>> - the test relies on the fact that the combo's skin is installed in setup - when installing it later, we'd run into a NPE at a different location in code
>> 
>> but then, this might be something to remember for a future bug/fix, if we agree on not including the list/combo sync into this bug
>
> ButtonCell strikes again. ?? I will remove it.
> Hm, this sounds like a follow-up then. Should I test this and create one?
> 
> EDIT: I think it's not wrong to check the button cell. But I guess you may want to see another check, but then again, I don't know what should I check for. 
> We should expect that the value is still shown in the button cell after an editable change (and ofc selectionModel null)

the buttonCell state is simply irrelevant here, what's striking - you - again is a test without final assert :) Same as toggling editability.

-------------

PR: https://git.openjdk.java.net/jfx/pull/557

From fastegal at openjdk.java.net  Mon Jul 12 13:10:01 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 12 Jul 2021 13:10:01 GMT
Subject: RFR: 8240506: TextFieldSkin/Behavior: misbehavior on switching
 skin [v2]
In-Reply-To: <_3IQGzS0GHrEkK-wziwqmn8xsbE5NRrXmlSu_yZmh0o=.2092ad5b-9a95-4355-a1ec-b5e8f37222ac@github.com>
References: 
 <_3IQGzS0GHrEkK-wziwqmn8xsbE5NRrXmlSu_yZmh0o=.2092ad5b-9a95-4355-a1ec-b5e8f37222ac@github.com>
Message-ID: 

On Mon, 28 Jun 2021 13:44:16 GMT, Marius Hanl  wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressed review issues
>
> Just a formal review, I left some comments inline

@Maran23 did resolve all we discussed - anything I missed?

-------------

PR: https://git.openjdk.java.net/jfx/pull/534

From kcr at openjdk.java.net  Mon Jul 12 13:18:54 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 12 Jul 2021 13:18:54 GMT
Subject: RFR: 8269374: Menu inoperable after setting stage to second
 monitor
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Jul 2021 12:46:10 GMT, Jose Pereda  wrote:

> On Windows, with two monitors with different DPI settings, if a JavaFX application changes screens (either by dragging or programmatically) there is a resize event to adjust the view to its new platform scale.
> 
> Note that there is already a [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java#L206) to `View::updateLocation` in WinWindow, right after `notifyMoveToAnotherScreen` and `notifyScaleChanged `. But this is done too soon, before the resize event. There are other MOVE events processed too (in a long complex chain of recursive calls to `WinWindow::setBounds`).
> 
> As a consequence, as commented in the issue [JDK-8269374](https://bugs.openjdk.java.net/browse/JDK-8269374), the view x/y coordinates are wrongly set using the _old_ X,Y values (from the previous screen) with the _new_ platform scale (from the new screen).
> 
> This PR adds an extra call to View::updateLocation` in WinWindow, forcing the view relocation on Windows after every resize event to fix the issue. With the correct location of the scene, the Menus are now perfectly aligned, and the mouse events are correctly processed. It doesn't have any side effect on other platforms.
> 
> There's a very small penalty, as this new relocation will be called whenever there is a resize event on Windows, but it simplifies the overhead of detecting when the change of screens is effectively done (including the chain of move/resize) events.
> 
> No tests are provided, since these would require a setup of two monitors with different DPI settings. However, the test case in the JBS issue can be used to validate the fix.

This seems like a correct fix. I can test it along with a formal review. Even though it is a small change in terms of lines of code, I'd like a second reviewer.

-------------

PR: https://git.openjdk.java.net/jfx/pull/572

From kcr at openjdk.java.net  Mon Jul 12 16:02:10 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 12 Jul 2021 16:02:10 GMT
Subject: [jfx17] RFR: 8270246: Deprecate for removal implementation methods in
 Scene
Message-ID: 

The following methods in Scene were former `impl_*` method that were intended to be encapsulated as part of [JDK-8157295](https://bugs.openjdk.java.net/browse/JDK-8157295) in JDK 9, but were mistakenly left as public:

    public void disposePeer()
    public void enableInputMethodEvents(boolean enable)
    public void processKeyEvent(KeyEvent e)

In the fix for [JDK-8157295](https://bugs.openjdk.java.net/browse/JDK-8157295), the `impl_` prefix was removed, and the necessary accessors were added, but the `public` modifier was not removed. See the diffs for these three methods in Scene.java: [`disposePeer`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL833), [`enableInputMethodEvents`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL2221), [`processKeyEvent`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL2129)

We will deprecate these methods for removal with the intention to remove them from the public API in a future version of JavaFX. This will need a CSR.

NOTE: this is targeted to `jfx17`.

-------------

Commit messages:
 - 8270246: Deprecate for removal implementation methods in Scene

Changes: https://git.openjdk.java.net/jfx/pull/573/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=573&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270246
  Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/573.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/573/head:pull/573

PR: https://git.openjdk.java.net/jfx/pull/573

From kevin.rushforth at oracle.com  Mon Jul 12 17:22:26 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 12 Jul 2021 10:22:26 -0700
Subject: TreeTableCell: Misnamed / inconsistent methods for row and column
 properties
Message-ID: 

While evaluating a javadoc fix [1] that removes spurious warnings for 
missing comments on JavaFX property methods, I looked at the remaining 
warnings, and discovered an inconsistency in the naming of two of the 
properties in the TreeTableCell class. I filed JDK-8270314 [2] to track 
this.

Before I submit a PR, I wanted to solicit comments.

In TreeTableCell, there is a mismatch between name of the following 
property method vs the getter:

 ? tableRowProperty()
 ? getTreeTableRow()

the get method has "Tree" in the name while the property method does not.

The corresponding methods for column are self-consistent, and are named 
without the "tree" in the name:

 ????? tableColumnProperty()
 ????? getTableColumn()

Given the type of the property -- TreeTableRow and TreeTableColumn, 
respectively -- the properties should have "Tree" in the name, but 
don't. Somewhat related is that the update methods for both row and 
column are updateTreeTableColumn? and updateTreeTableRow? which do have 
"TreeTable" in the name:

There are two possible solutions that seem workable:

Possible solutions:

1. Add Tree to all methods of the row and column properties

 ? tableRowProperty() --> treeTableRowProperty()

 ? tableColumnProperty() --> treeTableColumnProperty()
 ? getTableColumn() --> getTreeTableColumn()

This is the most consistent, but is slightly more intrusive in that 
changes 3 of the 4 public methods of the row and column properties.

2. Remove Tree from all methods of these properties

 ? getTreeTableRow() -> getTableRow()

This is a less intrusive change that only affects one method. While it 
makes the properties self-consistent and consistent with each other, the 
names are not what would be expected given the return type 
(TreeTableColumn and TreeTableRow), and are not consistent with the 
update methods. Also, for applications that don't use the property 
method, and only use the getter, it isn't any less change than the the 
first option.

I propose to go with option #1 for maximum consistency and further 
propose to deprecate *not for removal* the misnamed methods.

Comments?

-- Kevin

[1] https://github.com/openjdk/jdk/pull/4747
[2] https://bugs.openjdk.java.net/browse/JDK-8270314

From prr at openjdk.java.net  Mon Jul 12 18:56:26 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 12 Jul 2021 18:56:26 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final
Message-ID: 

- Make various setters and getters and properties final as needed
- Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
- Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
- Add a manual test program just so you can see what toString() does. No pass or fail, just informative.

This will need a CSR but I won't create that until the review is done.

-------------

Commit messages:
 - 8269638: Property methods, setters, and getters in printing API should be final

Changes: https://git.openjdk.java.net/jfx/pull/574/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=574&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269638
  Stats: 402 lines in 4 files changed: 253 ins; 118 del; 31 mod
  Patch: https://git.openjdk.java.net/jfx/pull/574.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/574/head:pull/574

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Mon Jul 12 21:46:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 12 Jul 2021 21:46:52 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Jul 2021 18:50:34 GMT, Phil Race  wrote:

> - Make various setters and getters and properties final as needed
> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
> 
> This will need a CSR but I won't create that until the review is done.

Two quick comments, otherwise looks good (I'll do a more detailed review of the added docs as well we double-check that nothing else was missed).

1. `PrinterJob::setPrinter` is not `final` (and probably some / all of the docs could move to the property).
2. There are two new warnings about empty `` tags:

jfx/modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java:968: warning: empty 
 tag
     * 

       ^
jfx/modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java:1049: warning: empty 
 tag
     * 

       ^

modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 968:

> 966:      * and it is safest to stick to selecting a standard value that
> 967:      * matches the requirement.
> 968:      * 

Empty `
` tag (you can simply remove this line).

modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 1049:

> 1047:      * and it is safest to stick to selecting a standard value that
> 1048:      * matches the requirement.
> 1049:      * 

Empty `
` tag (you can simply remove this line).

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kevin.rushforth at oracle.com  Mon Jul 12 21:55:37 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 12 Jul 2021 14:55:37 -0700
Subject: TreeTableCell: Misnamed / inconsistent methods for row and column
 properties
In-Reply-To: 
References: 
Message-ID: <11600b45-031b-4900-d7e7-a581ef09eda6@oracle.com>

In looking at this more closely, I now think that option 2 is the better 
approach for the following reasons:

* TreeTablePosition extends TablePositionBase (which is also extended by 
TablePosition), and inherits a getTableColumn() method that is 
overridden with a covariant return type (using the type of the generic 
"TC" parameter) of TreeTableColumn.

* Although not public API, TreeTableCellBehavior extends 
TableCellBehaviorBase ( which is also extended by TableCellBehavior), 
and inherits inherits a getTableColumn() method that is overridden with 
a covariant return type of TreeTableColumn.

So option 2 is the one that will provide better consistency, in addition 
to being less intrusive.

Thus, the only change I am proposing to the public API is: 
getTreeTableRow() -> getTableRow() -- which I will do by deprecating 
(not for removal) the existing method and adding getTableRow() to match 
the property name.

-- Kevin

On 7/12/2021 10:22 AM, Kevin Rushforth wrote:
> While evaluating a javadoc fix [1] that removes spurious warnings for 
> missing comments on JavaFX property methods, I looked at the remaining 
> warnings, and discovered an inconsistency in the naming of two of the 
> properties in the TreeTableCell class. I filed JDK-8270314 [2] to 
> track this.
>
> Before I submit a PR, I wanted to solicit comments.
>
> In TreeTableCell, there is a mismatch between name of the following 
> property method vs the getter:
>
> ? tableRowProperty()
> ? getTreeTableRow()
>
> the get method has "Tree" in the name while the property method does not.
>
> The corresponding methods for column are self-consistent, and are 
> named without the "tree" in the name:
>
> ????? tableColumnProperty()
> ????? getTableColumn()
>
> Given the type of the property -- TreeTableRow and TreeTableColumn, 
> respectively -- the properties should have "Tree" in the name, but 
> don't. Somewhat related is that the update methods for both row and 
> column are updateTreeTableColumn? and updateTreeTableRow? which do 
> have "TreeTable" in the name:
>
> There are two possible solutions that seem workable:
>
> Possible solutions:
>
> 1. Add Tree to all methods of the row and column properties
>
> ? tableRowProperty() --> treeTableRowProperty()
>
> ? tableColumnProperty() --> treeTableColumnProperty()
> ? getTableColumn() --> getTreeTableColumn()
>
> This is the most consistent, but is slightly more intrusive in that 
> changes 3 of the 4 public methods of the row and column properties.
>
>
> 2. Remove Tree from all methods of these properties
>
> ? getTreeTableRow() -> getTableRow()
>
> This is a less intrusive change that only affects one method. While it 
> makes the properties self-consistent and consistent with each other, 
> the names are not what would be expected given the return type 
> (TreeTableColumn and TreeTableRow), and are not consistent with the 
> update methods. Also, for applications that don't use the property 
> method, and only use the getter, it isn't any less change than the the 
> first option.
>
>
> I propose to go with option #1 for maximum consistency and further 
> propose to deprecate *not for removal* the misnamed methods.
>
>
> Comments?
>
> -- Kevin
>
> [1] https://github.com/openjdk/jdk/pull/4747
> [2] https://bugs.openjdk.java.net/browse/JDK-8270314
>

From prr at openjdk.java.net  Mon Jul 12 22:04:25 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 12 Jul 2021 22:04:25 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v2]
In-Reply-To: 
References: 
Message-ID: <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>

> - Make various setters and getters and properties final as needed
> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
> 
> This will need a CSR but I won't create that until the review is done.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8269638: Property methods, setters, and getters in printing API should be final

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/574/files
  - new: https://git.openjdk.java.net/jfx/pull/574/files/4fad1a0d..380ad63f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=574&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=574&range=00-01

  Stats: 33 lines in 2 files changed: 11 ins; 18 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/574.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/574/head:pull/574

PR: https://git.openjdk.java.net/jfx/pull/574

From prr at openjdk.java.net  Mon Jul 12 22:04:26 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 12 Jul 2021 22:04:26 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final
In-Reply-To: 
References: 
Message-ID: <1A4mG773jw8JtIT6t8blsmS5HvnboEK4tJgHMnNbZx0=.67c36f48-57de-4868-acaa-886b23cb43c2@github.com>

On Mon, 12 Jul 2021 18:50:34 GMT, Phil Race  wrote:

> - Make various setters and getters and properties final as needed
> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
> 
> This will need a CSR but I won't create that until the review is done.

fixed all the above and uploaded new commit

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From prr at openjdk.java.net  Mon Jul 12 22:04:31 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 12 Jul 2021 22:04:31 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v2]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 12 Jul 2021 21:28:41 GMT, Kevin Rushforth  wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8269638: Property methods, setters, and getters in printing API should be final
>
> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 968:
> 
>> 966:      * and it is safest to stick to selecting a standard value that
>> 967:      * matches the requirement.
>> 968:      * 

> 
> Empty `
` tag (you can simply remove this line).

done

> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 1049:
> 
>> 1047:      * and it is safest to stick to selecting a standard value that
>> 1048:      * matches the requirement.
>> 1049:      * 

> 
> Empty `
` tag (you can simply remove this line).

done

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Mon Jul 12 22:29:51 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 12 Jul 2021 22:29:51 GMT
Subject: [jfx17] RFR: 8268642: Expand the javafx.beans.property.Property
 documentation [v2]
In-Reply-To: <5jf-IsKqtzwQhnhAZtc4BkD8AJ4qPfLboeyfULkHjm8=.f273f877-7004-4511-9917-911fa8d538b3@github.com>
References: 

 <5jf-IsKqtzwQhnhAZtc4BkD8AJ4qPfLboeyfULkHjm8=.f273f877-7004-4511-9917-911fa8d538b3@github.com>
Message-ID: 

On Sat, 10 Jul 2021 12:33:52 GMT, Nir Lisker  wrote:

>> Maybe we could simply the mental model of the property specification by making it illegal in all cases to use unidirectional and bidirectional bindings at the same time. The specification would be reduced to "it's illegal", instead of having a long explanation that says it's only _likely_ to cause an exception.
>> 
>> Most attempts to use both kinds of bindings will fail with an exception anyway. Some will fail instantly when calling `bindBidirectional`, some will fail later when calling `setValue`. Some will fail more silently because the exception will happen inside `BidirectionalBinding` and not bring down the application. Only a kind-of-exotic situation will not produce exceptions at all (the situation that you described in the second bullet point).
>> 
>> If we were to always fail instantly at the point of calling `bind` or `bindBidirectional`, we would make the misuse of this API visible where it's most relevant, instead of failing later in other parts of the codebase.
>
> The following unit test demonstrated the *current* behavior, though maybe it's not the desired one:
> 
> 
> import static org.junit.Assert.*;
> 
> import javafx.beans.property.IntegerProperty;
> import javafx.beans.property.SimpleIntegerProperty;
> 
> import org.junit.Before;
> import org.junit.Test;
> 
> public class BindingsTest {
> 
> 	private IntegerProperty property1, property2, property3;
> 
> 	@Before
> 	public void setup() {
> 		property1 = new SimpleIntegerProperty(1);
> 		property2 = new SimpleIntegerProperty(2);
> 		property3 = new SimpleIntegerProperty(3);
> 	}
> 
> 	@Test
> 	public void testBidiAndThenUni() {
> 		property1.bindBidirectional(property2);
> 		assertEquals(2, property1.get());
> 		assertEquals(2, property2.get());
> 		property1.bind(property3);
> 		assertEquals(3, property1.get());
> 		assertEquals(3, property2.get());
> 		assertEquals(3, property3.get());
> 	}
> 
> 	@Test(expected = RuntimeException.class)
> 	public void setProperty1() {
> 		property1.bindBidirectional(property2);
> 		property1.bind(property3);
> 
> 		property1.set(4);
> 	}
> 
> 	@Test
> 	public void setProperty2() {
> 		property1.bindBidirectional(property2);
> 		property1.bind(property3);
> 
> 		// ignores exception (but still prints stack trace) at
> 		// com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
> 		property2.set(5);
> 		assertEquals(3, property1.get());
> 		assertEquals(3, property2.get()); // "Bidirectional binding failed, setting to the previous value"
> 		assertEquals(3, property3.get());
> 	}
> 
> 	@Test
> 	public void setProperty3() {
> 		property1.bindBidirectional(property2);
> 		property1.bind(property3);
> 
> 		property3.set(6);
> 		assertEquals(6, property1.get());
> 		assertEquals(6, property2.get());
> 		assertEquals(6, property3.get());
> 	}
> 
> 	@Test(expected = RuntimeException.class)
> 	public void testUniAndThenBidiOnBound() {
> 		property1.bind(property3);
> 		property1.bindBidirectional(property2);
> 	}
> 
> 	@Test
> 	public void testUniAndThenBidiOnUnbound() {
> 		property1.bind(property3);
> 		property2.bindBidirectional(property1);
> 		
> 		assertEquals(3, property1.get());
> 		assertEquals(3, property2.get());
> 		assertEquals(3, property3.get());
> 	}
> }
> 
> 
> My observations:
> 
> * `setProperty2()` is weird in that it throws an exception internally which is ignored by the JVM, and then reverts the change to the unidirectionally unbound property when it finds out that its counterpart can't be changed. It makes sense logically, but I don't see a valid use case for this.
> * `setProperty3()` behaves as I expect it to, but this is effectively 2 chained unidirectional binds: `property3` changes `property1` which changes `property2`. This is the same as `testUniAndThenBidiOnUnbound()`.
> 
> It would make sense to disallow this mixing of bindings on grounds that this is probably not what the developer wants to do. If we opt to let them do it but write that it should not be done, we could emit a warning. I'm leaning towards to fail-fast approach.

I also like documenting it as illegal, but am hesitant to make any implementation change in this area for JavaFX 17 during rampdown. So I would recommend documenting as illegal, but not adding the `@throws` to the docs. We could still say that an exception might be thrown or could say something like "results are undefined". Then in JavaFX 18, we can add the `@throws` and change the implementation to fail fast.

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From arapte at openjdk.java.net  Tue Jul 13 07:33:01 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 13 Jul 2021 07:33:01 GMT
Subject: RFR: 8269967: JavaFX should fail fast on macOS below minimum
 version [v2]
In-Reply-To: 
References: <9Qc7nizwWLNj5S3kDSGan9j_CZpSqVumiAycGi3urlA=.9f7e631d-b382-4a1c-9aeb-61eace526055@github.com>

Message-ID: <6kIkCZXNUa3gQHGDLgh4MIHpPzGlRWKlp1OcHCYf2FU=.6b5e2597-b009-4bb4-b332-e93a671dfd72@github.com>

On Fri, 9 Jul 2021 13:19:20 GMT, Kevin Rushforth  wrote:

>> This PR implements a version check in the JavaFX runtime initialization code on macOS to ensure that the platform is running a version of macOS that is at or above the minimum version. If the platform is below the specified minimum, the JavaFX initialization code throws an exception.
>> 
>> The minimum version is passed from the `mac.gradle` file to the Mac glass code as a pair of build time constants, which are compared at runtime to the platform version.
>> 
>> Notes to reviewers:
>> 
>> * In case anyone is interested, the first commit has some debug logging which will print the minimum version and the detected platform version. I removed them with the second commit.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move version check to beginning of initIDs

Marked as reviewed by arapte (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/567

From nlisker at openjdk.java.net  Tue Jul 13 09:47:21 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Tue, 13 Jul 2021 09:47:21 GMT
Subject: [jfx17] RFR: 8268642: Expand the javafx.beans.property.Property
 documentation [v2]
In-Reply-To: 
References: 

 <5jf-IsKqtzwQhnhAZtc4BkD8AJ4qPfLboeyfULkHjm8=.f273f877-7004-4511-9917-911fa8d538b3@github.com>

Message-ID: 

On Mon, 12 Jul 2021 22:27:12 GMT, Kevin Rushforth  wrote:

>> The following unit test demonstrated the *current* behavior, though maybe it's not the desired one:
>> 
>> 
>> import static org.junit.Assert.*;
>> 
>> import javafx.beans.property.IntegerProperty;
>> import javafx.beans.property.SimpleIntegerProperty;
>> 
>> import org.junit.Before;
>> import org.junit.Test;
>> 
>> public class BindingsTest {
>> 
>> 	private IntegerProperty property1, property2, property3;
>> 
>> 	@Before
>> 	public void setup() {
>> 		property1 = new SimpleIntegerProperty(1);
>> 		property2 = new SimpleIntegerProperty(2);
>> 		property3 = new SimpleIntegerProperty(3);
>> 	}
>> 
>> 	@Test
>> 	public void testBidiAndThenUni() {
>> 		property1.bindBidirectional(property2);
>> 		assertEquals(2, property1.get());
>> 		assertEquals(2, property2.get());
>> 		property1.bind(property3);
>> 		assertEquals(3, property1.get());
>> 		assertEquals(3, property2.get());
>> 		assertEquals(3, property3.get());
>> 	}
>> 
>> 	@Test(expected = RuntimeException.class)
>> 	public void setProperty1() {
>> 		property1.bindBidirectional(property2);
>> 		property1.bind(property3);
>> 
>> 		property1.set(4);
>> 	}
>> 
>> 	@Test
>> 	public void setProperty2() {
>> 		property1.bindBidirectional(property2);
>> 		property1.bind(property3);
>> 
>> 		// ignores exception (but still prints stack trace) at
>> 		// com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:181)
>> 		property2.set(5);
>> 		assertEquals(3, property1.get());
>> 		assertEquals(3, property2.get()); // "Bidirectional binding failed, setting to the previous value"
>> 		assertEquals(3, property3.get());
>> 	}
>> 
>> 	@Test
>> 	public void setProperty3() {
>> 		property1.bindBidirectional(property2);
>> 		property1.bind(property3);
>> 
>> 		property3.set(6);
>> 		assertEquals(6, property1.get());
>> 		assertEquals(6, property2.get());
>> 		assertEquals(6, property3.get());
>> 	}
>> 
>> 	@Test(expected = RuntimeException.class)
>> 	public void testUniAndThenBidiOnBound() {
>> 		property1.bind(property3);
>> 		property1.bindBidirectional(property2);
>> 	}
>> 
>> 	@Test
>> 	public void testUniAndThenBidiOnUnbound() {
>> 		property1.bind(property3);
>> 		property2.bindBidirectional(property1);
>> 		
>> 		assertEquals(3, property1.get());
>> 		assertEquals(3, property2.get());
>> 		assertEquals(3, property3.get());
>> 	}
>> }
>> 
>> 
>> My observations:
>> 
>> * `setProperty2()` is weird in that it throws an exception internally which is ignored by the JVM, and then reverts the change to the unidirectionally unbound property when it finds out that its counterpart can't be changed. It makes sense logically, but I don't see a valid use case for this.
>> * `setProperty3()` behaves as I expect it to, but this is effectively 2 chained unidirectional binds: `property3` changes `property1` which changes `property2`. This is the same as `testUniAndThenBidiOnUnbound()`.
>> 
>> It would make sense to disallow this mixing of bindings on grounds that this is probably not what the developer wants to do. If we opt to let them do it but write that it should not be done, we could emit a warning. I'm leaning towards to fail-fast approach.
>
> I also like documenting it as illegal, but am hesitant to make any implementation change in this area for JavaFX 17 during rampdown. So I would recommend documenting as illegal, but not adding the `@throws` to the docs. We could still say that an exception might be thrown or could say something like "results are undefined". Then in JavaFX 18, we can add the `@throws` and change the implementation to fail fast.

Fine with me.

I didn't look at the current tests, but if it helps, we can add the one I wrote.

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From kcr at openjdk.java.net  Tue Jul 13 11:56:54 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Jul 2021 11:56:54 GMT
Subject: Integrated: 8269967: JavaFX should fail fast on macOS below minimum
 version
In-Reply-To: <9Qc7nizwWLNj5S3kDSGan9j_CZpSqVumiAycGi3urlA=.9f7e631d-b382-4a1c-9aeb-61eace526055@github.com>
References: <9Qc7nizwWLNj5S3kDSGan9j_CZpSqVumiAycGi3urlA=.9f7e631d-b382-4a1c-9aeb-61eace526055@github.com>
Message-ID: <9tvS9jQaN_bgfMIFuBg5UG213MZgCnASE7EEBS1rkhM=.dc8f1fff-2119-4811-8a9f-4e97e8e9a51e@github.com>

On Tue, 6 Jul 2021 23:54:12 GMT, Kevin Rushforth  wrote:

> This PR implements a version check in the JavaFX runtime initialization code on macOS to ensure that the platform is running a version of macOS that is at or above the minimum version. If the platform is below the specified minimum, the JavaFX initialization code throws an exception.
> 
> The minimum version is passed from the `mac.gradle` file to the Mac glass code as a pair of build time constants, which are compared at runtime to the platform version.
> 
> Notes to reviewers:
> 
> * In case anyone is interested, the first commit has some debug logging which will print the minimum version and the detected platform version. I removed them with the second commit.

This pull request has now been integrated.

Changeset: 00b353e8
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/00b353e8f0afbe2b024b15463df867c6647d34be
Stats:     35 lines in 2 files changed: 34 ins; 0 del; 1 mod

8269967: JavaFX should fail fast on macOS below minimum version

Reviewed-by: jvos, arapte

-------------

PR: https://git.openjdk.java.net/jfx/pull/567

From kcr at openjdk.java.net  Tue Jul 13 12:47:16 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Jul 2021 12:47:16 GMT
Subject: RFR: 8269968: [REDO] Bump minimum version of macOS for x64 to 10.12
Message-ID: 

The fix for [JDK-8266743](https://bugs.openjdk.java.net/browse/JDK-8266743) (crash on macOS 10.11) -- was to partially revert [JDK-8265031](https://bugs.openjdk.java.net/browse/JDK-8265031), and lower the minimum macOS version for x64 back to 10.10 in JavaFX 17. We should bump it back to 10.12 in JavaFX 18.

This will be done in connection with [JDK-8269967](https://bugs.openjdk.java.net/browse/JDK-8269967), PR #567, which will provide a fail-fast when attempting to run on an older version of macOS than the minimum. I will not integrate this PR until after that one is integrated.

-------------

Commit messages:
 - 8269968: [REDO] Bump minimum version of macOS for x64 to 10.12

Changes: https://git.openjdk.java.net/jfx/pull/570/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=570&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269968
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/570.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/570/head:pull/570

PR: https://git.openjdk.java.net/jfx/pull/570

From jvos at openjdk.java.net  Tue Jul 13 13:59:54 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 13 Jul 2021 13:59:54 GMT
Subject: RFR: 8269968: [REDO] Bump minimum version of macOS for x64 to
 10.12
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Jul 2021 23:17:44 GMT, Kevin Rushforth  wrote:

> The fix for [JDK-8266743](https://bugs.openjdk.java.net/browse/JDK-8266743) (crash on macOS 10.11) -- was to partially revert [JDK-8265031](https://bugs.openjdk.java.net/browse/JDK-8265031), and lower the minimum macOS version for x64 back to 10.10 in JavaFX 17. We should bump it back to 10.12 in JavaFX 18.
> 
> This will be done in connection with [JDK-8269967](https://bugs.openjdk.java.net/browse/JDK-8269967), PR #567, which will provide a fail-fast when attempting to run on an older version of macOS than the minimum. I will not integrate this PR until after that one is integrated.

Marked as reviewed by jvos (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/570

From kcr at openjdk.java.net  Tue Jul 13 14:21:56 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Jul 2021 14:21:56 GMT
Subject: Integrated: 8269968: [REDO] Bump minimum version of macOS for x64 to
 10.12
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Jul 2021 23:17:44 GMT, Kevin Rushforth  wrote:

> The fix for [JDK-8266743](https://bugs.openjdk.java.net/browse/JDK-8266743) (crash on macOS 10.11) -- was to partially revert [JDK-8265031](https://bugs.openjdk.java.net/browse/JDK-8265031), and lower the minimum macOS version for x64 back to 10.10 in JavaFX 17. We should bump it back to 10.12 in JavaFX 18.
> 
> This will be done in connection with [JDK-8269967](https://bugs.openjdk.java.net/browse/JDK-8269967), PR #567, which will provide a fail-fast when attempting to run on an older version of macOS than the minimum. I will not integrate this PR until after that one is integrated.

This pull request has now been integrated.

Changeset: a34928fb
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/a34928fb8e0506b2d6e4834bb77f7b52c691660b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269968: [REDO] Bump minimum version of macOS for x64 to 10.12

Reviewed-by: jvos

-------------

PR: https://git.openjdk.java.net/jfx/pull/570

From kevin.rushforth at oracle.com  Tue Jul 13 14:58:23 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 13 Jul 2021 07:58:23 -0700
Subject: TreeTableCell: Misnamed / inconsistent methods for row and column
 properties
In-Reply-To: <11600b45-031b-4900-d7e7-a581ef09eda6@oracle.com>
References: 
 <11600b45-031b-4900-d7e7-a581ef09eda6@oracle.com>
Message-ID: <40de6e31-918d-cfbd-fc76-e7ea5779e321@oracle.com>

Here is a Draft PR that implements option 2:

https://github.com/openjdk/jfx/pull/575

It also fixes two additional issues with the properties:

* The docs for each property is on a private property field that does 
have tree in the name, which results in no docs being generated for 
either the tableRow or tableColumn property.

* The implementation of the tableRowProperty() method returns the 
writable property by mistake rather than the read-only property that is 
specified by the method's return type.

I will likely make it RFR tomorrow, and plan to target it to jfx17.

-- Kevin

On 7/12/2021 2:55 PM, Kevin Rushforth wrote:
> In looking at this more closely, I now think that option 2 is the 
> better approach for the following reasons:
>
> * TreeTablePosition extends TablePositionBase (which is also extended 
> by TablePosition), and inherits a getTableColumn() method that is 
> overridden with a covariant return type (using the type of the generic 
> "TC" parameter) of TreeTableColumn.
>
> * Although not public API, TreeTableCellBehavior extends 
> TableCellBehaviorBase ( which is also extended by TableCellBehavior), 
> and inherits inherits a getTableColumn() method that is overridden 
> with a covariant return type of TreeTableColumn.
>
> So option 2 is the one that will provide better consistency, in 
> addition to being less intrusive.
>
> Thus, the only change I am proposing to the public API is: 
> getTreeTableRow() -> getTableRow() -- which I will do by deprecating 
> (not for removal) the existing method and adding getTableRow() to 
> match the property name.
>
> -- Kevin
>
>
> On 7/12/2021 10:22 AM, Kevin Rushforth wrote:
>> While evaluating a javadoc fix [1] that removes spurious warnings for 
>> missing comments on JavaFX property methods, I looked at the 
>> remaining warnings, and discovered an inconsistency in the naming of 
>> two of the properties in the TreeTableCell class. I filed JDK-8270314 
>> [2] to track this.
>>
>> Before I submit a PR, I wanted to solicit comments.
>>
>> In TreeTableCell, there is a mismatch between name of the following 
>> property method vs the getter:
>>
>> ? tableRowProperty()
>> ? getTreeTableRow()
>>
>> the get method has "Tree" in the name while the property method does 
>> not.
>>
>> The corresponding methods for column are self-consistent, and are 
>> named without the "tree" in the name:
>>
>> ????? tableColumnProperty()
>> ????? getTableColumn()
>>
>> Given the type of the property -- TreeTableRow and TreeTableColumn, 
>> respectively -- the properties should have "Tree" in the name, but 
>> don't. Somewhat related is that the update methods for both row and 
>> column are updateTreeTableColumn? and updateTreeTableRow? which do 
>> have "TreeTable" in the name:
>>
>> There are two possible solutions that seem workable:
>>
>> Possible solutions:
>>
>> 1. Add Tree to all methods of the row and column properties
>>
>> ? tableRowProperty() --> treeTableRowProperty()
>>
>> ? tableColumnProperty() --> treeTableColumnProperty()
>> ? getTableColumn() --> getTreeTableColumn()
>>
>> This is the most consistent, but is slightly more intrusive in that 
>> changes 3 of the 4 public methods of the row and column properties.
>>
>>
>> 2. Remove Tree from all methods of these properties
>>
>> ? getTreeTableRow() -> getTableRow()
>>
>> This is a less intrusive change that only affects one method. While 
>> it makes the properties self-consistent and consistent with each 
>> other, the names are not what would be expected given the return type 
>> (TreeTableColumn and TreeTableRow), and are not consistent with the 
>> update methods. Also, for applications that don't use the property 
>> method, and only use the getter, it isn't any less change than the 
>> the first option.
>>
>>
>> I propose to go with option #1 for maximum consistency and further 
>> propose to deprecate *not for removal* the misnamed methods.
>>
>>
>> Comments?
>>
>> -- Kevin
>>
>> [1] https://github.com/openjdk/jdk/pull/4747
>> [2] https://bugs.openjdk.java.net/browse/JDK-8270314
>>
>

From kcr at openjdk.java.net  Tue Jul 13 17:49:14 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Jul 2021 17:49:14 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v2]
In-Reply-To: <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
References: 
 <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
Message-ID: 

On Mon, 12 Jul 2021 22:04:25 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Tue Jul 13 17:52:25 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Jul 2021 17:52:25 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v2]
In-Reply-To: <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
References: 
 <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
Message-ID: 

On Mon, 12 Jul 2021 22:04:25 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

@prsadhuk Can you be the second reviewer?

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From prr at openjdk.java.net  Tue Jul 13 18:48:21 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 13 Jul 2021 18:48:21 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v2]
In-Reply-To: <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
References: 
 <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
Message-ID: 

On Mon, 12 Jul 2021 22:04:25 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

The CSR has been created : https://bugs.openjdk.java.net/browse/JDK-8270381

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From psadhukhan at openjdk.java.net  Wed Jul 14 06:33:14 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 14 Jul 2021 06:33:14 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v2]
In-Reply-To: <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
References: 
 <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
Message-ID: 

On Mon, 12 Jul 2021 22:04:25 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

modules/javafx.graphics/src/main/java/javafx/print/PrinterJob.java line 212:

> 210: 
> 211:     /**
> 212:      * Property representing the {@code Printer} for this job.

I guess we normally used  throughout . Probably better to be consistent.

tests/manual/printing/JobSettingsInfo.java line 31:

> 29: import javafx.collections.FXCollections;
> 30: import javafx.collections.ObservableList;
> 31: import javafx.print.*;

Maybe we can do away with this wildcard and import explicit class.. Also, down below one more place...

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From jvos at openjdk.java.net  Wed Jul 14 09:57:22 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 14 Jul 2021 09:57:22 GMT
Subject: RFR: 8268849: Update to 612.1 version of WebKit [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 6 Jul 2021 10:39:40 GMT, Ambarish Rapte  wrote:

>> Update JavaFX WebKit to GTK WebKit 2.32 (612.1).
>> There are two separate commits:
>> 1. [commit](https://github.com/openjdk/jfx/commit/ed0baf5f23aed0d8aaa72645c8e03fde56d0f0cc) : includes only native changes
>> 2. [commit](https://github.com/openjdk/jfx/commit/b024c16551be7d929fa1d927d3be8f0fc75a64c3) : includes non native changes
>> 
>> This is change is targeted for JavaFX 18, shall be integrated after fork.
>
> Ambarish Rapte has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unwanted file
>  - comment failing test code

Works with the required toolchains

-------------

Marked as reviewed by jvos (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/560

From kcr at openjdk.java.net  Wed Jul 14 12:16:14 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Jul 2021 12:16:14 GMT
Subject: RFR: 8269374: Menu inoperable after setting stage to second
 monitor
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Jul 2021 12:46:10 GMT, Jose Pereda  wrote:

> On Windows, with two monitors with different DPI settings, if a JavaFX application changes screens (either by dragging or programmatically) there is a resize event to adjust the view to its new platform scale.
> 
> Note that there is already a [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java#L206) to `View::updateLocation` in WinWindow, right after `notifyMoveToAnotherScreen` and `notifyScaleChanged `. But this is done too soon, before the resize event. There are other MOVE events processed too (in a long complex chain of recursive calls to `WinWindow::setBounds`).
> 
> As a consequence, as commented in the issue [JDK-8269374](https://bugs.openjdk.java.net/browse/JDK-8269374), the view x/y coordinates are wrongly set using the _old_ X,Y values (from the previous screen) with the _new_ platform scale (from the new screen).
> 
> This PR adds an extra call to View::updateLocation` in WinWindow, forcing the view relocation on Windows after every resize event to fix the issue. With the correct location of the scene, the Menus are now perfectly aligned, and the mouse events are correctly processed. It doesn't have any side effect on other platforms.
> 
> There's a very small penalty, as this new relocation will be called whenever there is a resize event on Windows, but it simplifies the overhead of detecting when the change of screens is effectively done (including the chain of move/resize) events.
> 
> No tests are provided, since these would require a setup of two monitors with different DPI settings. However, the test case in the JBS issue can be used to validate the fix.

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/572

From kcr at openjdk.java.net  Wed Jul 14 12:33:19 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Jul 2021 12:33:19 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v2]
In-Reply-To: 
References: 
 <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>

Message-ID: 

On Wed, 14 Jul 2021 06:26:30 GMT, Prasanta Sadhukhan  wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8269638: Property methods, setters, and getters in printing API should be final
>
> modules/javafx.graphics/src/main/java/javafx/print/PrinterJob.java line 212:
> 
>> 210: 
>> 211:     /**
>> 212:      * Property representing the {@code Printer} for this job.
> 
> I guess we normally used  throughout . Probably better to be consistent.

Using `{@code xxx}` is preferred to `xxx` so for new fixes we might as well use the preferred pattern.

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From psadhukhan at openjdk.java.net  Wed Jul 14 12:39:13 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 14 Jul 2021 12:39:13 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v2]
In-Reply-To: <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
References: 
 <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>
Message-ID: 

On Mon, 12 Jul 2021 22:04:25 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

ok

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/574

From kevin.rushforth at oracle.com  Wed Jul 14 12:57:57 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 14 Jul 2021 05:57:57 -0700
Subject: TreeTableCell: Misnamed / inconsistent methods for row and column
 properties
In-Reply-To: <40de6e31-918d-cfbd-fc76-e7ea5779e321@oracle.com>
References: 
 <11600b45-031b-4900-d7e7-a581ef09eda6@oracle.com>
 <40de6e31-918d-cfbd-fc76-e7ea5779e321@oracle.com>
Message-ID: 

PR #575, which implements option 2, is now RFR.

-- Kevin

On 7/13/2021 7:58 AM, Kevin Rushforth wrote:
> Here is a Draft PR that implements option 2:
>
> https://github.com/openjdk/jfx/pull/575
>
> It also fixes two additional issues with the properties:
>
> * The docs for each property is on a private property field that does 
> have tree in the name, which results in no docs being generated for 
> either the tableRow or tableColumn property.
>
> * The implementation of the tableRowProperty() method returns the 
> writable property by mistake rather than the read-only property that 
> is specified by the method's return type.
>
> I will likely make it RFR tomorrow, and plan to target it to jfx17.
>
> -- Kevin
>
>
> On 7/12/2021 2:55 PM, Kevin Rushforth wrote:
>> In looking at this more closely, I now think that option 2 is the 
>> better approach for the following reasons:
>>
>> * TreeTablePosition extends TablePositionBase (which is also extended 
>> by TablePosition), and inherits a getTableColumn() method that is 
>> overridden with a covariant return type (using the type of the 
>> generic "TC" parameter) of TreeTableColumn.
>>
>> * Although not public API, TreeTableCellBehavior extends 
>> TableCellBehaviorBase ( which is also extended by TableCellBehavior), 
>> and inherits inherits a getTableColumn() method that is overridden 
>> with a covariant return type of TreeTableColumn.
>>
>> So option 2 is the one that will provide better consistency, in 
>> addition to being less intrusive.
>>
>> Thus, the only change I am proposing to the public API is: 
>> getTreeTableRow() -> getTableRow() -- which I will do by deprecating 
>> (not for removal) the existing method and adding getTableRow() to 
>> match the property name.
>>
>> -- Kevin
>>
>>
>> On 7/12/2021 10:22 AM, Kevin Rushforth wrote:
>>> While evaluating a javadoc fix [1] that removes spurious warnings 
>>> for missing comments on JavaFX property methods, I looked at the 
>>> remaining warnings, and discovered an inconsistency in the naming of 
>>> two of the properties in the TreeTableCell class. I filed 
>>> JDK-8270314 [2] to track this.
>>>
>>> Before I submit a PR, I wanted to solicit comments.
>>>
>>> In TreeTableCell, there is a mismatch between name of the following 
>>> property method vs the getter:
>>>
>>> ? tableRowProperty()
>>> ? getTreeTableRow()
>>>
>>> the get method has "Tree" in the name while the property method does 
>>> not.
>>>
>>> The corresponding methods for column are self-consistent, and are 
>>> named without the "tree" in the name:
>>>
>>> ????? tableColumnProperty()
>>> ????? getTableColumn()
>>>
>>> Given the type of the property -- TreeTableRow and TreeTableColumn, 
>>> respectively -- the properties should have "Tree" in the name, but 
>>> don't. Somewhat related is that the update methods for both row and 
>>> column are updateTreeTableColumn? and updateTreeTableRow? which do 
>>> have "TreeTable" in the name:
>>>
>>> There are two possible solutions that seem workable:
>>>
>>> Possible solutions:
>>>
>>> 1. Add Tree to all methods of the row and column properties
>>>
>>> ? tableRowProperty() --> treeTableRowProperty()
>>>
>>> ? tableColumnProperty() --> treeTableColumnProperty()
>>> ? getTableColumn() --> getTreeTableColumn()
>>>
>>> This is the most consistent, but is slightly more intrusive in that 
>>> changes 3 of the 4 public methods of the row and column properties.
>>>
>>>
>>> 2. Remove Tree from all methods of these properties
>>>
>>> ? getTreeTableRow() -> getTableRow()
>>>
>>> This is a less intrusive change that only affects one method. While 
>>> it makes the properties self-consistent and consistent with each 
>>> other, the names are not what would be expected given the return 
>>> type (TreeTableColumn and TreeTableRow), and are not consistent with 
>>> the update methods. Also, for applications that don't use the 
>>> property method, and only use the getter, it isn't any less change 
>>> than the the first option.
>>>
>>>
>>> I propose to go with option #1 for maximum consistency and further 
>>> propose to deprecate *not for removal* the misnamed methods.
>>>
>>>
>>> Comments?
>>>
>>> -- Kevin
>>>
>>> [1] https://github.com/openjdk/jdk/pull/4747
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8270314
>>>
>>
>

From kcr at openjdk.java.net  Wed Jul 14 12:58:32 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Jul 2021 12:58:32 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for tableRow
 and tableColumn property methods
Message-ID: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>

In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:

    public final ReadOnlyObjectProperty> tableRowProperty()
    public final TreeTableRow getTreeTableRow()

The get method has "Tree" in the name while the property method does not.

By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:

    public final ReadOnlyObjectProperty> tableColumnProperty()
    public final TreeTableColumn getTableColumn()

The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).

Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.

Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.

In summary, the following changes are made to `TreeTableCell`:

1. Deprecate the `getTreeTableRow` method.
2. Add a `getTableRow` method.
3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
4. Change the implementation of the tableRowProperty() method to return a read-only property.

In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.

NOTE: this is targeted to `jfx17`.

-------------

Commit messages:
 - 8270314: TreeTableCell: inconsistent naming for tableRow and tableColumn property methods

Changes: https://git.openjdk.java.net/jfx/pull/575/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=575&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270314
  Stats: 68 lines in 5 files changed: 36 ins; 0 del; 32 mod
  Patch: https://git.openjdk.java.net/jfx/pull/575.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/575/head:pull/575

PR: https://git.openjdk.java.net/jfx/pull/575

From kcr at openjdk.java.net  Wed Jul 14 12:58:32 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Jul 2021 12:58:32 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods
In-Reply-To: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
Message-ID: <9fU2qh5ZGtJrZulHvlguy065cvhvCEAMaCj9UJHA_YM=.a8c59f80-36a5-45b5-95fe-8992d63399fb@github.com>

On Tue, 13 Jul 2021 14:47:59 GMT, Kevin Rushforth  wrote:

> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
> 
> 
>     public final ReadOnlyObjectProperty> tableRowProperty()
>     public final TreeTableRow getTreeTableRow()
> 
> 
> The get method has "Tree" in the name while the property method does not.
> 
> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
> 
> 
>     public final ReadOnlyObjectProperty> tableColumnProperty()
>     public final TreeTableColumn getTableColumn()
> 
> 
> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
> 
> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
> 
> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
> 
> In summary, the following changes are made to `TreeTableCell`:
> 
> 1. Deprecate the `getTreeTableRow` method.
> 2. Add a `getTableRow` method.
> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
> 
> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
> 
> NOTE: this is targeted to `jfx17`.

This will need a CSR.

@kleopatra would you be willing to be a second reviewer?

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From arapte at openjdk.java.net  Wed Jul 14 13:15:31 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 14 Jul 2021 13:15:31 GMT
Subject: Integrated: 8268849: Update to 612.1 version of WebKit
In-Reply-To: 
References: 
Message-ID: 

On Thu, 1 Jul 2021 08:32:31 GMT, Ambarish Rapte  wrote:

> Update JavaFX WebKit to GTK WebKit 2.32 (612.1).
> There are two separate commits:
> 1. [commit](https://github.com/openjdk/jfx/commit/ed0baf5f23aed0d8aaa72645c8e03fde56d0f0cc) : includes only native changes
> 2. [commit](https://github.com/openjdk/jfx/commit/b024c16551be7d929fa1d927d3be8f0fc75a64c3) : includes non native changes
> 
> This is change is targeted for JavaFX 18, shall be integrated after fork.

This pull request has now been integrated.

Changeset: 948df324
Author:    Ambarish Rapte 
URL:       https://git.openjdk.java.net/jfx/commit/948df32448b71c4d6c10ccc4c125170dc68b0786
Stats:     286061 lines in 5711 files changed: 175196 ins; 68118 del; 42747 mod

8268849: Update to 612.1 version of WebKit

Co-authored-by: Arun Joseph 
Reviewed-by: kcr, jvos

-------------

PR: https://git.openjdk.java.net/jfx/pull/560

From nlisker at gmail.com  Wed Jul 14 19:49:49 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 14 Jul 2021 22:49:49 +0300
Subject: Fwd: Result: New Group: Client Libraries; Dissolved Groups: AWT, 2D,
 Swing, & Sound
In-Reply-To: <20210714171625.4EF3C3EBB54@eggemoggin.niobe.net>
References: <20210714171625.4EF3C3EBB54@eggemoggin.niobe.net>
Message-ID: 

Does this affect OpenJFX in any way?

---------- Forwarded message ---------
From: 
Date: Wed, Jul 14, 2021 at 8:17 PM
Subject: Result: New Group: Client Libraries; Dissolved Groups: AWT, 2D,
Swing, & Sound
To: 
Cc: 

The Governing Board has voted to approve the creation of the Client
Libraries Group, with Phil Race as the initial Lead, and to approve
the dissolution of the AWT, 2D, Swing, and Sound Groups [1][2][3].

The new Group will sponsor the OpenJFX and Lanai Projects.  The
Harfbuzz, Framebuffer Toolkit, and XRender Pipeline Projects are
dissolved by virtue of losing their sponsoring Groups.

Yes: 5
No: 0
Abstain: 0

According to the Bylaws definition of Two-Thirds Majority, this is
sufficient to approve the new Group and its initial Lead.

(Only a Simple Majority is required to approve the creation of the
 new Group, but a Two-Thirds Majority is required to dissolve the
 old Groups [4].)

- Mark

[1] https://mail.openjdk.java.net/pipermail/gb-discuss/2021-June/000358.html
[2] https://mail.openjdk.java.net/pipermail/gb-discuss/2021-July/000361.html
[3] https://mail.openjdk.java.net/pipermail/gb-discuss/2021-July/000363.html
[4] https://openjdk.java.net/bylaws#_4

From kevin.rushforth at oracle.com  Wed Jul 14 20:29:33 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 14 Jul 2021 13:29:33 -0700
Subject: Fwd: Result: New Group: Client Libraries; Dissolved Groups: AWT,
 2D, Swing, & Sound
In-Reply-To: 
References: <20210714171625.4EF3C3EBB54@eggemoggin.niobe.net>

Message-ID: 

No. The new Client group is the long-planned consolidation of 
2D/AWT/Swing (with Sound thrown in for good measure), mainly to get rid 
of the multiple mailing lists with frequent cross-posting. Phil can add 
more if he want to.

-- Kevin

On 7/14/2021 12:49 PM, Nir Lisker wrote:
> Does this affect OpenJFX in any way?
>
> ---------- Forwarded message ---------
> From: 
> Date: Wed, Jul 14, 2021 at 8:17 PM
> Subject: Result: New Group: Client Libraries; Dissolved Groups: AWT, 2D,
> Swing, & Sound
> To: 
> Cc: 
>
>
> The Governing Board has voted to approve the creation of the Client
> Libraries Group, with Phil Race as the initial Lead, and to approve
> the dissolution of the AWT, 2D, Swing, and Sound Groups [1][2][3].
>
> The new Group will sponsor the OpenJFX and Lanai Projects.  The
> Harfbuzz, Framebuffer Toolkit, and XRender Pipeline Projects are
> dissolved by virtue of losing their sponsoring Groups.
>
> Yes: 5
> No: 0
> Abstain: 0
>
> According to the Bylaws definition of Two-Thirds Majority, this is
> sufficient to approve the new Group and its initial Lead.
>
> (Only a Simple Majority is required to approve the creation of the
>   new Group, but a Two-Thirds Majority is required to dissolve the
>   old Groups [4].)
>
> - Mark
>
>
> [1] https://mail.openjdk.java.net/pipermail/gb-discuss/2021-June/000358.html
> [2] https://mail.openjdk.java.net/pipermail/gb-discuss/2021-July/000361.html
> [3] https://mail.openjdk.java.net/pipermail/gb-discuss/2021-July/000363.html
> [4] https://openjdk.java.net/bylaws#_4

From prr at openjdk.java.net  Wed Jul 14 20:44:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 14 Jul 2021 20:44:47 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v3]
In-Reply-To: 
References: 
Message-ID: 

> - Make various setters and getters and properties final as needed
> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
> 
> This will need a CSR but I won't create that until the review is done.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8269638: Property methods, setters, and getters in printing API should be final

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/574/files
  - new: https://git.openjdk.java.net/jfx/pull/574/files/380ad63f..6a84d1d9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=574&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=574&range=01-02

  Stats: 22 lines in 1 file changed: 12 ins; 9 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/574.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/574/head:pull/574

PR: https://git.openjdk.java.net/jfx/pull/574

From prr at openjdk.java.net  Wed Jul 14 20:44:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 14 Jul 2021 20:44:51 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v2]
In-Reply-To: 
References: 
 <3hxAi5G2EdFgVMK4vX35ZbDrzu6wIQIC2qCP0UNstO4=.c45f9877-b16f-4f85-94ee-c647324b893d@github.com>

Message-ID: 

On Wed, 14 Jul 2021 06:29:22 GMT, Prasanta Sadhukhan  wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8269638: Property methods, setters, and getters in printing API should be final
>
> tests/manual/printing/JobSettingsInfo.java line 31:
> 
>> 29: import javafx.collections.FXCollections;
>> 30: import javafx.collections.ObservableList;
>> 31: import javafx.print.*;
> 
> Maybe we can do away with this wildcard and import explicit class.. Also, down below one more place...

I have cleaned up wild card and unused imports.

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Wed Jul 14 20:54:18 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 14 Jul 2021 20:54:18 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v3]
In-Reply-To: 
References: 

Message-ID: <05BXB79Wln0C7-9YnAvlHGsDXpsPBr2qAhN54MsIRno=.e81fbcbf-af1d-4193-8bae-4969328dc903@github.com>

On Wed, 14 Jul 2021 20:44:47 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From psadhukhan at openjdk.java.net  Thu Jul 15 04:35:21 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 15 Jul 2021 04:35:21 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v3]
In-Reply-To: 
References: 

Message-ID: <6culXGo-966COQl0fsA8qZBJA7r7v6_OenbKXRvr_es=.8fc4554c-d471-4b60-afc0-3fcaa4afab09@github.com>

On Wed, 14 Jul 2021 20:44:47 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

modules/javafx.graphics/src/main/java/javafx/print/PrinterJob.java line 226:

> 224:      * Setting a null value for printer will install the default printer.
> 225:      * Setting the current printer has no effect.
> 226:      * @return the Printer for this job

If we are using {@code Printer} preferred pattern above for new addition, probably we should use here too, no?

tests/manual/printing/JobSettingsInfo.java line 45:

> 43: import javafx.scene.Scene;
> 44: import javafx.scene.control.TextArea;
> 45: import javafx.scene.layout.*;

One more place wildcard overlooked...Since we changed one case above, probably it can also be rectified..

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From pbansal at openjdk.java.net  Thu Jul 15 11:40:22 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Thu, 15 Jul 2021 11:40:22 GMT
Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window
 behaves correctly [v3]
In-Reply-To: 
References: 

Message-ID: 

On Sat, 10 Jul 2021 16:06:18 GMT, Thiago Milczarek Sayao  wrote:

>> The PR approach is to set  `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows.
>> 
>> This is passed on WindowStage.java:198 as a mask.
>> 
>> The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded test for modal

Marked as reviewed by pbansal (Committer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/551

From kcr at openjdk.java.net  Thu Jul 15 13:27:32 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 13:27:32 GMT
Subject: RFR: 8270479: WebKit 612.1 build fails with Visual Studio 2017
Message-ID: 

This fix allows the latest WebKit 612.1 to compile with Visual Studio 2017. For the jfx mainline, our current toolchain for Windows is VS2019 16.9.3, but we would like to continue to allow developers to build with VS 2017.

The JavaFX 11 code line still uses VS2017 (15.9.24), so we must fix this in the `jfx11u` code line in any case. Fixing it mainline first and then backporting it will allow the native WebKit code to remain in sync between mainline and jfx11u as well as keeping JavaFX buildable on VS2017 for a while longer.

As noted in the JBS bug report, eventually we will need to upgrade all code lines to a minimum of VS2019 for building WebKit, but this fix allows us to delay that for a while longer.

## Notes to Reviewers

There were two problems that needed to be fixed:

*  `WebCore/inspector/InspectorOverlay.cpp` fails to compile with an error that "conversion from 'const int' to 'float' requires a narrowing conversion". The fix is to initialize the two `constexpr` variables with float constants instead of integer constants.
* `jfxwebkit.dll` fails to link with 4 duplicate symbols due to VS2017's incomplete (or buggy) support for inline constant variables. The fix is to move the definition of those 4 constant variables from `Node.h` to `Node.cpp` and define them as runtime constants. 

I qualified both changes with `#if PLATFORM(JAVA)` so our local modifications are clearly identified. I could have further qualified the second of these two changes (there's no point in doing it for the first) with `&& OS(WINDOWS)` but chose to be consistent on all OS platforms.

-------------

Commit messages:
 - Minor cleanup to move comments within #if PLATFORM(JAVA) block
 - 8270479: WebKit 612.1 build fails with Visual Studio 2017

Changes: https://git.openjdk.java.net/jfx/pull/576/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=576&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/jfx/pull/576.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/576/head:pull/576

PR: https://git.openjdk.java.net/jfx/pull/576

From arapte at openjdk.java.net  Thu Jul 15 15:32:13 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 15 Jul 2021 15:32:13 GMT
Subject: [jfx17] RFR: 8270246: Deprecate for removal implementation
 methods in Scene
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Jul 2021 15:52:17 GMT, Kevin Rushforth  wrote:

> The following methods in Scene were former `impl_*` method that were intended to be encapsulated as part of [JDK-8157295](https://bugs.openjdk.java.net/browse/JDK-8157295) in JDK 9, but were mistakenly left as public:
> 
> 
>     public void disposePeer()
>     public void enableInputMethodEvents(boolean enable)
>     public void processKeyEvent(KeyEvent e)
> 
> 
> In the fix for [JDK-8157295](https://bugs.openjdk.java.net/browse/JDK-8157295), the `impl_` prefix was removed, and the necessary accessors were added, but the `public` modifier was not removed. See the diffs for these three methods in Scene.java: [`disposePeer`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL833), [`enableInputMethodEvents`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL2221), [`processKeyEvent`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL2129)
> 
> We will deprecate these methods for removal with the intention to remove them from the public API in a future version of JavaFX. This will need a CSR.
> 
> NOTE: this is targeted to `jfx17`.

Looks good to me.

-------------

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/573

From arapte at openjdk.java.net  Thu Jul 15 15:51:13 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 15 Jul 2021 15:51:13 GMT
Subject: RFR: 8269374: Menu inoperable after setting stage to second
 monitor
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Jul 2021 12:46:10 GMT, Jose Pereda  wrote:

> On Windows, with two monitors with different DPI settings, if a JavaFX application changes screens (either by dragging or programmatically) there is a resize event to adjust the view to its new platform scale.
> 
> Note that there is already a [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java#L206) to `View::updateLocation` in WinWindow, right after `notifyMoveToAnotherScreen` and `notifyScaleChanged `. But this is done too soon, before the resize event. There are other MOVE events processed too (in a long complex chain of recursive calls to `WinWindow::setBounds`).
> 
> As a consequence, as commented in the issue [JDK-8269374](https://bugs.openjdk.java.net/browse/JDK-8269374), the view x/y coordinates are wrongly set using the _old_ X,Y values (from the previous screen) with the _new_ platform scale (from the new screen).
> 
> This PR adds an extra call to View::updateLocation` in WinWindow, forcing the view relocation on Windows after every resize event to fix the issue. With the correct location of the scene, the Menus are now perfectly aligned, and the mouse events are correctly processed. It doesn't have any side effect on other platforms.
> 
> There's a very small penalty, as this new relocation will be called whenever there is a resize event on Windows, but it simplifies the overhead of detecting when the change of screens is effectively done (including the chain of move/resize) events.
> 
> No tests are provided, since these would require a setup of two monitors with different DPI settings. However, the test case in the JBS issue can be used to validate the fix.

I tested the fix with different scaling combinations, the issue reported in JBS does not occur with fix. But noticed a similar issue that occurs only if the primary screen is in landscape mode and external monitor is in portrait mode. This behavior is observed both with and without this change. The behavior may be unrelated to fix, in that it can be addressed separately. 
@kevinrushforth  request you to take look and call on this.

Steps:
1. Primary screen, 125%, Landscape mode
2. Secondary screen, 100%, Portrait mode
3. Run the program attached to JBS
4. Move the Stage to secondary screen
5. Maximize Stage
6. Keep focus on the Stage and press Windows + Shift + Left key
7. Stage will be moved to primary screen
8. Click on menu, observe that location is not correct. Below is screenshot.

![image](https://user-images.githubusercontent.com/11330676/125815141-5eeb3f3a-177f-4b09-b746-3a25f63bde44.png)

----
A slight different behavior can be observed with a change in step 6
Follow same steps as above except at step 6: Click 'Change screen' button. Below is the screenshot

![image](https://user-images.githubusercontent.com/11330676/125816635-27176ce3-923e-40f1-a632-8d7b4b30f1b5.png)

-------------

PR: https://git.openjdk.java.net/jfx/pull/572

From prr at openjdk.java.net  Thu Jul 15 18:06:44 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 15 Jul 2021 18:06:44 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v4]
In-Reply-To: 
References: 
Message-ID: 

> - Make various setters and getters and properties final as needed
> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
> 
> This will need a CSR but I won't create that until the review is done.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8269638: Property methods, setters, and getters in printing API should be final

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/574/files
  - new: https://git.openjdk.java.net/jfx/pull/574/files/6a84d1d9..3da5e4df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=574&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=574&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/574.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/574/head:pull/574

PR: https://git.openjdk.java.net/jfx/pull/574

From prr at openjdk.java.net  Thu Jul 15 18:06:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 15 Jul 2021 18:06:47 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v3]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 14 Jul 2021 20:44:47 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

uploaded new commit

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From prr at openjdk.java.net  Thu Jul 15 18:06:52 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 15 Jul 2021 18:06:52 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v3]
In-Reply-To: <6culXGo-966COQl0fsA8qZBJA7r7v6_OenbKXRvr_es=.8fc4554c-d471-4b60-afc0-3fcaa4afab09@github.com>
References: 

 <6culXGo-966COQl0fsA8qZBJA7r7v6_OenbKXRvr_es=.8fc4554c-d471-4b60-afc0-3fcaa4afab09@github.com>
Message-ID: <3WH47O6lbGkwbsSxkNXxHTNTG6SsOLY6oe-xciCaenQ=.62ecac72-659f-40dc-9c53-df359866255e@github.com>

On Thu, 15 Jul 2021 04:30:42 GMT, Prasanta Sadhukhan  wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8269638: Property methods, setters, and getters in printing API should be final
>
> modules/javafx.graphics/src/main/java/javafx/print/PrinterJob.java line 226:
> 
>> 224:      * Setting a null value for printer will install the default printer.
>> 225:      * Setting the current printer has no effect.
>> 226:      * @return the Printer for this job
> 
> If we are using {@code Printer} preferred pattern above for new addition, probably we should use here too, no?

done

> tests/manual/printing/JobSettingsInfo.java line 45:
> 
>> 43: import javafx.scene.Scene;
>> 44: import javafx.scene.control.TextArea;
>> 45: import javafx.scene.layout.*;
> 
> One more place wildcard overlooked...Since we changed one case above, probably it can also be rectified..

done

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Thu Jul 15 18:30:15 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 18:30:15 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 15 Jul 2021 18:06:44 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Thu Jul 15 20:20:41 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 20:20:41 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v2]
In-Reply-To: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
Message-ID: 

> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
> 
> 
>     public final ReadOnlyObjectProperty> tableRowProperty()
>     public final TreeTableRow getTreeTableRow()
> 
> 
> The get method has "Tree" in the name while the property method does not.
> 
> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
> 
> 
>     public final ReadOnlyObjectProperty> tableColumnProperty()
>     public final TreeTableColumn getTableColumn()
> 
> 
> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
> 
> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
> 
> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
> 
> In summary, the following changes are made to `TreeTableCell`:
> 
> 1. Deprecate the `getTreeTableRow` method.
> 2. Add a `getTableRow` method.
> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
> 
> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
> 
> NOTE: this is targeted to `jfx17`.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in javadoc comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/575/files
  - new: https://git.openjdk.java.net/jfx/pull/575/files/e34d6ff3..759d8890

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=575&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=575&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/575.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/575/head:pull/575

PR: https://git.openjdk.java.net/jfx/pull/575

From kcr at openjdk.java.net  Thu Jul 15 20:58:20 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 20:58:20 GMT
Subject: [jfx17] RFR: 8268642: Expand the javafx.beans.property.Property
 documentation [v2]
In-Reply-To: 
References: 

Message-ID: <7eWKnak3FCy0ZqvvM4uFJ1p0HA0Lmwo_v8fE9JNv37s=.f3684c4d-65f6-4ebb-88f4-09df85f352b3@github.com>

On Thu, 24 Jun 2021 01:53:53 GMT, Michael Strau?  wrote:

>> * Expand the `Property.bind` and `Property.bindBidirectional` documentation
>> * Change the name of the formal parameter of `Property.bind` to "source" (currently, it is inconsistently named "observable", "rawObservable" or "newObservable")
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes as per review

@mstr2 I'll re-review once you address the outstanding comments.

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From kcr at openjdk.java.net  Thu Jul 15 22:38:17 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 15 Jul 2021 22:38:17 GMT
Subject: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window
 behaves correctly [v3]
In-Reply-To: 
References: 

Message-ID: 

On Sat, 10 Jul 2021 16:06:18 GMT, Thiago Milczarek Sayao  wrote:

>> The PR approach is to set  `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows.
>> 
>> This is passed on WindowStage.java:198 as a mask.
>> 
>> The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded test for modal

I verified that this fixes the problem, but it also changes the behavior of `APPLICATION_MODAL` dialogs on Linux to be "Always on Top" -- not just on top of other application windows (which is fine), but on top of all other windows an application might create, which is not desirable as a default behavior. This also makes it behave differently than Mac or Windows.

I think we should look for a solution that doesn't rely on forcing a dialog to be on top of other (no app) windows.

-------------

PR: https://git.openjdk.java.net/jfx/pull/551

From psadhukhan at openjdk.java.net  Fri Jul 16 04:07:25 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 16 Jul 2021 04:07:25 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 15 Jul 2021 18:06:44 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

looks good..
However I have a different question...I was looking at printerProperty and I saw In l182, we are not checking for getDefaultPrinter() returns null or not but in l120, we do...Is it not required in l182?

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From aghaisas at openjdk.java.net  Fri Jul 16 04:53:12 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 16 Jul 2021 04:53:12 GMT
Subject: [jfx17] RFR: 8270246: Deprecate for removal implementation
 methods in Scene
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Jul 2021 15:52:17 GMT, Kevin Rushforth  wrote:

> The following methods in Scene were former `impl_*` method that were intended to be encapsulated as part of [JDK-8157295](https://bugs.openjdk.java.net/browse/JDK-8157295) in JDK 9, but were mistakenly left as public:
> 
> 
>     public void disposePeer()
>     public void enableInputMethodEvents(boolean enable)
>     public void processKeyEvent(KeyEvent e)
> 
> 
> In the fix for [JDK-8157295](https://bugs.openjdk.java.net/browse/JDK-8157295), the `impl_` prefix was removed, and the necessary accessors were added, but the `public` modifier was not removed. See the diffs for these three methods in Scene.java: [`disposePeer`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL833), [`enableInputMethodEvents`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL2221), [`processKeyEvent`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL2129)
> 
> We will deprecate these methods for removal with the intention to remove them from the public API in a future version of JavaFX. This will need a CSR.
> 
> NOTE: this is targeted to `jfx17`.

Marked as reviewed by aghaisas (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/573

From aghaisas at openjdk.java.net  Fri Jul 16 07:01:14 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 16 Jul 2021 07:01:14 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v2]
In-Reply-To: 
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>

Message-ID: 

On Thu, 15 Jul 2021 20:20:41 GMT, Kevin Rushforth  wrote:

>> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableRowProperty()
>>     public final TreeTableRow getTreeTableRow()
>> 
>> 
>> The get method has "Tree" in the name while the property method does not.
>> 
>> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableColumnProperty()
>>     public final TreeTableColumn getTableColumn()
>> 
>> 
>> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
>> 
>> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
>> 
>> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
>> 
>> In summary, the following changes are made to `TreeTableCell`:
>> 
>> 1. Deprecate the `getTreeTableRow` method.
>> 2. Add a `getTableRow` method.
>> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
>> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
>> 
>> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
>> 
>> NOTE: this is targeted to `jfx17`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in javadoc comment

Marked as reviewed by aghaisas (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From fastegal at openjdk.java.net  Fri Jul 16 08:18:24 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 16 Jul 2021 08:18:24 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods
In-Reply-To: <9fU2qh5ZGtJrZulHvlguy065cvhvCEAMaCj9UJHA_YM=.a8c59f80-36a5-45b5-95fe-8992d63399fb@github.com>
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
 <9fU2qh5ZGtJrZulHvlguy065cvhvCEAMaCj9UJHA_YM=.a8c59f80-36a5-45b5-95fe-8992d63399fb@github.com>
Message-ID: 

On Wed, 14 Jul 2021 12:54:27 GMT, Kevin Rushforth  wrote:

> 
> 
> @kleopatra would you be willing to be a second reviewer?

yeah sure - will do at the weekend. 

A quick question: why didn't you rename the updateTreeTableRow/Column as well? Pretending that the properties were writable and we had setters, these would follow the new names - regarding those update methods as expert setters, I would tend to rename them also.

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From fastegal at openjdk.java.net  Fri Jul 16 08:52:09 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 16 Jul 2021 08:52:09 GMT
Subject: RFR: 8188027: List/TableCell: must not fire event in startEdit if
 already editing
Message-ID: 

issue was a missing check in startEdit if already editing (as Tree- and TreeTableCell do)

fix was to add the check and backout if true, added tests to List/TableCell that fail/pass before/after the fix

-------------

Commit messages:
 - fixed trailing whitespace
 - 8188027: List/TableCell: must not fire event in startEdit if already

Changes: https://git.openjdk.java.net/jfx/pull/571/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=571&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8188027
  Stats: 35 lines in 4 files changed: 35 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/571.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/571/head:pull/571

PR: https://git.openjdk.java.net/jfx/pull/571

From alessandro.parisi406 at gmail.com  Fri Jul 16 11:15:34 2021
From: alessandro.parisi406 at gmail.com (Alessandro Parisi)
Date: Fri, 16 Jul 2021 13:15:34 +0200
Subject: RFR: 8263095: Provide a way for a custom control to indicate that its
 userAgentStyleSheet has changed
Message-ID: 

>
> The next steps would be to send an email (you can reply to this thread),
> with a clear description of your proposal.
>
> The focus should be on what problem you are solving and on the proposed
> public API and behavioral changes. I suggest not (yet) referring to code
> changes in your PR except for illustrative purposes. Start with what the
> current behavior is, what problem that is causing, and what your
> proposed solution is. By way of a counter-example, the "computeIfAbsent"
> code fragment you included in your email and PR description is an
> implementation detail; the concept that should be discussed is the
> presumed stability of a Region's userAgentStyleSheet. This presumed
> stability is documented in the spec, so start there, not with the code.
>
> If there is general agreement that this feature is a good thing to add
> to JavaFX as public API, meaning it is something that would benefit
> multiple app developers, the next step would be to review the proposed
> API and behavioral changes. This can be done in the context of reviewing
> the PR. The focus during this phase of review would be mainly on the
> specification changes that would need to go into the API docs and be
> included in the CSR.
>
> The above is good general guidance for getting any new non-trivial
> feature added to the JavaFX API.
>
> As for the specifics of what you are proposing, the main things I would
> like to see addressed during the initial discussion are:
>
> * When and why do custom controls typically want to provide a dynamic
> userAgentStylesheet?
> * How should a control indicate that its userAgentStyleSheet is dynamic?
> By a separate property (read-only?) that it provides as an override?
> Should it be dynamic by default (I am skeptical, myself)?
> * Does an application that uses a custom control need to know whether or
> not that control uses a dynamic userAgentStylesheet? Can it affect the
> answer (e.g., you mentioned theming, can you be more specific)?
>
> -- Kevin
>

So, without talking about code, I'm going to explain what I want to achieve
with this change.

As of now, custom controls  can specify their userAgentStylesheet by
overriding the getter inherited from Region. The documentation says:

> An implementation may specify its own user-agent styles for this Region,
> and its children, by overriding this method. Subclasses overriding this
> method should not assume any particular implementation approach as to the
> number and frequency with which it is called. For this reason, attempting
> any kind of dynamic implementation (i.e. returning different user agent
> stylesheet values) based on some state change is highly discouraged, as
> there is no guarantee when, or even if, this method will be called.
>

The issue there is that the current implementation is not dynamic.
To answer your first question:

> When and why do custom controls typically want to provide a dynamic
> userAgentStylesheet?
>

In my library, I currently have two custom controls. For each of them I
have three stylesheets and I want the user  to choose the style they
prefer. So, the control is one, but the styles are three, and I can only
provide one userAgentStylesheet because it is not dynamic. The solution
would be to create three different controls and each of them uses one of
the three stylesheets. However, this would lead to code duplication for
just a stylesheet change.

To answer the third question:

> Does an application that uses a custom control need to know whether or
> not that control uses a dynamic userAgentStylesheet? Can it affect the
> answer (e.g., you mentioned theming, can you be more specific)?
>

Keeping in mind what I said above, let's suppose the user is developing an
app with dark theme as default. With a dynamic implementation of the
userAgentStylesheet I could specify two or more stylesheets for my custom
controls, one or more for light and dark styles, the user would just need
to change the style. That's what I mean by theming. In my custom controls
then I could specify a way to change the style (an enumerator for example).
It's up to the user then to decide which style to use.
So the control needs to specify a way to change the style and that's up to
the library developer to decide how (like I said an enumerator would be a
way to do it), and JavaFX must allow the control to change the userAgent
dynamically and update the control on change.

To answer your second question:

> How should a control indicate that its userAgentStyleSheet is dynamic?
>

Using a property. Rather than just having a getter, we could introduce a
property to store the userAgent.
When the user changes the style, the property changes too. On change, the
StyleManager should also be notified about the change so that the CSS can
be recomputed

From kcr at openjdk.java.net  Fri Jul 16 11:34:59 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 11:34:59 GMT
Subject: [jfx17] Integrated: 8270246: Deprecate for removal implementation
 methods in Scene
In-Reply-To: 
References: 
Message-ID: <-7RhuOUA6WeSZQZ_HAXpUfxKwPVzdaDzrvklWnFAhjw=.73ff1771-b0cc-4d04-962f-e69dd37e2817@github.com>

On Mon, 12 Jul 2021 15:52:17 GMT, Kevin Rushforth  wrote:

> The following methods in Scene were former `impl_*` method that were intended to be encapsulated as part of [JDK-8157295](https://bugs.openjdk.java.net/browse/JDK-8157295) in JDK 9, but were mistakenly left as public:
> 
> 
>     public void disposePeer()
>     public void enableInputMethodEvents(boolean enable)
>     public void processKeyEvent(KeyEvent e)
> 
> 
> In the fix for [JDK-8157295](https://bugs.openjdk.java.net/browse/JDK-8157295), the `impl_` prefix was removed, and the necessary accessors were added, but the `public` modifier was not removed. See the diffs for these three methods in Scene.java: [`disposePeer`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL833), [`enableInputMethodEvents`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL2221), [`processKeyEvent`](https://github.com/openjdk/jfx/commit/d864a620dfc7631585872547b42dcf93e9d570e6#diff-72cb5f9e4cc8a3804417166fdef390361e82d5890603f4e5158c9fc70c22e9daL2129)
> 
> We will deprecate these methods for removal with the intention to remove them from the public API in a future version of JavaFX. This will need a CSR.
> 
> NOTE: this is targeted to `jfx17`.

This pull request has now been integrated.

Changeset: 85014165
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/85014165a6e65c2357df2a26a873e6a25a9e1668
Stats:     17 lines in 1 file changed: 17 ins; 0 del; 0 mod

8270246: Deprecate for removal implementation methods in Scene

Reviewed-by: arapte, aghaisas

-------------

PR: https://git.openjdk.java.net/jfx/pull/573

From arapte at openjdk.java.net  Fri Jul 16 11:53:52 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 16 Jul 2021 11:53:52 GMT
Subject: RFR: 8270479: WebKit 612.1 build fails with Visual Studio 2017
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Jul 2021 23:30:54 GMT, Kevin Rushforth  wrote:

> This fix allows the latest WebKit 612.1 to compile with Visual Studio 2017. For the jfx mainline, our current toolchain for Windows is VS2019 16.9.3, but we would like to continue to allow developers to build with VS 2017.
> 
> The JavaFX 11 code line still uses VS2017 (15.9.24), so we must fix this in the `jfx11u` code line in any case. Fixing it mainline first and then backporting it will allow the native WebKit code to remain in sync between mainline and jfx11u as well as keeping JavaFX buildable on VS2017 for a while longer.
> 
> As noted in the JBS bug report, eventually we will need to upgrade all code lines to a minimum of VS2019 for building WebKit, but this fix allows us to delay that for a while longer.
> 
> ## Notes to Reviewers
> 
> There were two problems that needed to be fixed:
> 
> *  `WebCore/inspector/InspectorOverlay.cpp` fails to compile with an error that "conversion from 'const int' to 'float' requires a narrowing conversion". The fix is to initialize the two `constexpr` variables with float constants instead of integer constants.
> * `jfxwebkit.dll` fails to link with 4 duplicate symbols due to VS2017's incomplete (or buggy) support for inline constant variables. The fix is to move the definition of those 4 constant variables from `Node.h` to `Node.cpp` and define them as runtime constants. 
> 
> I qualified both changes with `#if PLATFORM(JAVA)` so our local modifications are clearly identified. I could have further qualified the second of these two changes (there's no point in doing it for the first) with `&& OS(WINDOWS)` but chose to be consistent on all OS platforms.

Verified builds, looks good to me.

-------------

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/576

From kcr at openjdk.java.net  Fri Jul 16 12:23:53 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 12:23:53 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods
In-Reply-To: 
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
 <9fU2qh5ZGtJrZulHvlguy065cvhvCEAMaCj9UJHA_YM=.a8c59f80-36a5-45b5-95fe-8992d63399fb@github.com>

Message-ID: 

On Fri, 16 Jul 2021 08:14:12 GMT, Jeanette Winzenburg  wrote:

> A quick question: why didn't you rename the updateTreeTableRow/Column as well? Pretending that the properties were writable and we had setters, these would follow the new names - regarding those update methods as expert setters, I would tend to rename them also.

I didn't look at it too closely, but my thinking was to minimize the changes to those that were necessary. You are right, though, that they should follow the same naming convention since they are effectively expert-mode setters for those properties. I'll take a closer look at those, but it does seem consistent to rename them as well.

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From kcr at openjdk.java.net  Fri Jul 16 13:03:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 13:03:52 GMT
Subject: RFR: 8270479: WebKit 612.1 build fails with Visual Studio 2017
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Jul 2021 23:30:54 GMT, Kevin Rushforth  wrote:

> This fix allows the latest WebKit 612.1 to compile with Visual Studio 2017. For the jfx mainline, our current toolchain for Windows is VS2019 16.9.3, but we would like to continue to allow developers to build with VS 2017.
> 
> The JavaFX 11 code line still uses VS2017 (15.9.24), so we must fix this in the `jfx11u` code line in any case. Fixing it mainline first and then backporting it will allow the native WebKit code to remain in sync between mainline and jfx11u as well as keeping JavaFX buildable on VS2017 for a while longer.
> 
> As noted in the JBS bug report, eventually we will need to upgrade all code lines to a minimum of VS2019 for building WebKit, but this fix allows us to delay that for a while longer.
> 
> ## Notes to Reviewers
> 
> There were two problems that needed to be fixed:
> 
> *  `WebCore/inspector/InspectorOverlay.cpp` fails to compile with an error that "conversion from 'const int' to 'float' requires a narrowing conversion". The fix is to initialize the two `constexpr` variables with float constants instead of integer constants.
> * `jfxwebkit.dll` fails to link with 4 duplicate symbols due to VS2017's incomplete (or buggy) support for inline constant variables. The fix is to move the definition of those 4 constant variables from `Node.h` to `Node.cpp` and define them as runtime constants. 
> 
> I qualified both changes with `#if PLATFORM(JAVA)` so our local modifications are clearly identified. I could have further qualified the second of these two changes (there's no point in doing it for the first) with `&& OS(WINDOWS)` but chose to be consistent on all OS platforms.

@johanvos @tiainen Can one of you be the second reviewer?

-------------

PR: https://git.openjdk.java.net/jfx/pull/576

From kcr at openjdk.java.net  Fri Jul 16 13:30:28 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 13:30:28 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v3]
In-Reply-To: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
Message-ID: <0Wp2eQFYCkXpRNiLlsJFl7CvnpNNbOaPWFdtZnwvCII=.32a8cc13-3e49-42ef-9f6d-8620ff6b98b3@github.com>

> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
> 
> 
>     public final ReadOnlyObjectProperty> tableRowProperty()
>     public final TreeTableRow getTreeTableRow()
> 
> 
> The get method has "Tree" in the name while the property method does not.
> 
> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
> 
> 
>     public final ReadOnlyObjectProperty> tableColumnProperty()
>     public final TreeTableColumn getTableColumn()
> 
> 
> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
> 
> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
> 
> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
> 
> In summary, the following changes are made to `TreeTableCell`:
> 
> 1. Deprecate the `getTreeTableRow` method.
> 2. Add a `getTableRow` method.
> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
> 
> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
> 
> NOTE: this is targeted to `jfx17`.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Renamed updateTreeTable{Row,Column} to updateTable{Row,Column}

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/575/files
  - new: https://git.openjdk.java.net/jfx/pull/575/files/759d8890..5c519ed1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=575&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=575&range=01-02

  Stats: 84 lines in 11 files changed: 22 ins; 0 del; 62 mod
  Patch: https://git.openjdk.java.net/jfx/pull/575.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/575/head:pull/575

PR: https://git.openjdk.java.net/jfx/pull/575

From kcr at openjdk.java.net  Fri Jul 16 13:34:53 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 13:34:53 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v2]
In-Reply-To: 
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>

Message-ID: 

On Thu, 15 Jul 2021 20:20:41 GMT, Kevin Rushforth  wrote:

>> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableRowProperty()
>>     public final TreeTableRow getTreeTableRow()
>> 
>> 
>> The get method has "Tree" in the name while the property method does not.
>> 
>> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableColumnProperty()
>>     public final TreeTableColumn getTableColumn()
>> 
>> 
>> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
>> 
>> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
>> 
>> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
>> 
>> In summary, the following changes are made to `TreeTableCell`:
>> 
>> 1. Deprecate the `getTreeTableRow` method.
>> 2. Add a `getTableRow` method.
>> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
>> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
>> 
>> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
>> 
>> NOTE: this is targeted to `jfx17`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in javadoc comment

As suggested, I also renamed `updateTreeTable{Row,Column}` to `updateTable{Row,Column}` (by deprecating the existing methods and adding new methods).

I'll update the CSR to match after those new changes have been reviewed.

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From kcr at openjdk.java.net  Fri Jul 16 13:34:54 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 13:34:54 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v3]
In-Reply-To: <0Wp2eQFYCkXpRNiLlsJFl7CvnpNNbOaPWFdtZnwvCII=.32a8cc13-3e49-42ef-9f6d-8620ff6b98b3@github.com>
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
 <0Wp2eQFYCkXpRNiLlsJFl7CvnpNNbOaPWFdtZnwvCII=.32a8cc13-3e49-42ef-9f6d-8620ff6b98b3@github.com>
Message-ID: 

On Fri, 16 Jul 2021 13:30:28 GMT, Kevin Rushforth  wrote:

>> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableRowProperty()
>>     public final TreeTableRow getTreeTableRow()
>> 
>> 
>> The get method has "Tree" in the name while the property method does not.
>> 
>> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableColumnProperty()
>>     public final TreeTableColumn getTableColumn()
>> 
>> 
>> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
>> 
>> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
>> 
>> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
>> 
>> In summary, the following changes are made to `TreeTableCell`:
>> 
>> 1. Deprecate the `getTreeTableRow` method.
>> 2. Add a `getTableRow` method.
>> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
>> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
>> 
>> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
>> 
>> NOTE: this is targeted to `jfx17`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed updateTreeTable{Row,Column} to updateTable{Row,Column}

modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableCell.java line 724:

> 722:      * @param tv the {@code TreeTableView} associated with this {@code TreeTableCell}
> 723:      */
> 724:     public final void updateTreeTableView(TreeTableView tv) {

The changes to the docs for this method were just formatting changes to match the corresponding changes to row and column methods (I did the same thing earlier for the property methods).

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From kcr at openjdk.java.net  Fri Jul 16 13:43:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 13:43:52 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v4]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 16 Jul 2021 04:04:13 GMT, Prasanta Sadhukhan  wrote:

> looks good..
> However I have a different question...I was looking at printerProperty and I saw In l182, we are not checking for getDefaultPrinter() returns null or not but in l120, we do...Is it not required in l182?

It might be a good follow-on bug to skip lines 185-6 if `getDefaultPrinter()` is `null` (else it will NPE), but it's completely unrelated to this fix so wouldn't be done as part of this PR.

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Fri Jul 16 13:47:53 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 13:47:53 GMT
Subject: RFR: 8269374: Menu inoperable after setting stage to second
 monitor
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Jul 2021 12:46:10 GMT, Jose Pereda  wrote:

> On Windows, with two monitors with different DPI settings, if a JavaFX application changes screens (either by dragging or programmatically) there is a resize event to adjust the view to its new platform scale.
> 
> Note that there is already a [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java#L206) to `View::updateLocation` in WinWindow, right after `notifyMoveToAnotherScreen` and `notifyScaleChanged `. But this is done too soon, before the resize event. There are other MOVE events processed too (in a long complex chain of recursive calls to `WinWindow::setBounds`).
> 
> As a consequence, as commented in the issue [JDK-8269374](https://bugs.openjdk.java.net/browse/JDK-8269374), the view x/y coordinates are wrongly set using the _old_ X,Y values (from the previous screen) with the _new_ platform scale (from the new screen).
> 
> This PR adds an extra call to View::updateLocation` in WinWindow, forcing the view relocation on Windows after every resize event to fix the issue. With the correct location of the scene, the Menus are now perfectly aligned, and the mouse events are correctly processed. It doesn't have any side effect on other platforms.
> 
> There's a very small penalty, as this new relocation will be called whenever there is a resize event on Windows, but it simplifies the overhead of detecting when the change of screens is effectively done (including the chain of move/resize) events.
> 
> No tests are provided, since these would require a setup of two monitors with different DPI settings. However, the test case in the JBS issue can be used to validate the fix.

I'd be OK handling this as a follow-on bug.

@jperedadnr Can you take at least a quick look and see if you can spot why this case fails?  Maybe there is another place where we need to call `updateLocation`?

-------------

PR: https://git.openjdk.java.net/jfx/pull/572

From kcr at openjdk.java.net  Fri Jul 16 14:28:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 14:28:52 GMT
Subject: RFR: Merge jfx17
Message-ID: 

Merge jfx17 branch into master.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/jfx17' into merge-jfx17-2021-07-16
 - 8270246: Deprecate for removal implementation methods in Scene

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jfx/pull/577/files
  Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/577.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/577/head:pull/577

PR: https://git.openjdk.java.net/jfx/pull/577

From kcr at openjdk.java.net  Fri Jul 16 14:28:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 14:28:52 GMT
Subject: RFR: Merge jfx17
In-Reply-To: 
References: 
Message-ID: 

On Fri, 16 Jul 2021 14:24:17 GMT, Kevin Rushforth  wrote:

> Merge jfx17 branch into master.

No review needed. I'll integrate as soon as the GitHub actions run completes.

-------------

PR: https://git.openjdk.java.net/jfx/pull/577

From psadhukhan at openjdk.java.net  Fri Jul 16 14:36:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 16 Jul 2021 14:36:56 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 15 Jul 2021 18:06:44 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Fri Jul 16 14:55:48 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 14:55:48 GMT
Subject: Integrated: Merge jfx17
In-Reply-To: 
References: 
Message-ID: 

On Fri, 16 Jul 2021 14:24:17 GMT, Kevin Rushforth  wrote:

> Merge jfx17 branch into master.

This pull request has now been integrated.

Changeset: 1d97808f
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/1d97808f58aaf52c798437aff32c3efe22c4f1f5
Stats:     17 lines in 1 file changed: 17 ins; 0 del; 0 mod

Merge

-------------

PR: https://git.openjdk.java.net/jfx/pull/577

From kcr at openjdk.java.net  Fri Jul 16 14:55:48 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 14:55:48 GMT
Subject: RFR: Merge jfx17 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Merge jfx17 branch into master.

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 six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/jfx17' into merge-jfx17-2021-07-16
 - 8268849: Update to 612.1 version of WebKit

   Co-authored-by: Arun Joseph 
   Reviewed-by: kcr, jvos
 - 8269968: [REDO] Bump minimum version of macOS for x64 to 10.12

   Reviewed-by: jvos
 - 8269967: JavaFX should fail fast on macOS below minimum version

   Reviewed-by: jvos, arapte
 - 8268718: [macos] Video stops, but audio continues to play when stopTime is reached

   Reviewed-by: kcr, arapte
 - 8269597: Change JavaFX release version to 18

   Reviewed-by: pbansal, arapte

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/577/files
  - new: https://git.openjdk.java.net/jfx/pull/577/files/b37fc96f..b37fc96f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=577&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=577&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/577.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/577/head:pull/577

PR: https://git.openjdk.java.net/jfx/pull/577

From prr at openjdk.java.net  Fri Jul 16 15:50:59 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 16 Jul 2021 15:50:59 GMT
Subject: Integrated: 8269638: Property methods, setters,
 and getters in printing API should be final
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Jul 2021 18:50:34 GMT, Phil Race  wrote:

> - Make various setters and getters and properties final as needed
> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
> 
> This will need a CSR but I won't create that until the review is done.

This pull request has now been integrated.

Changeset: 8b8cea23
Author:    Phil Race 
URL:       https://git.openjdk.java.net/jfx/commit/8b8cea23d1fd5c1c149e0143e2f6bf3312b5ab2e
Stats:     433 lines in 4 files changed: 265 ins; 134 del; 34 mod

8269638: Property methods, setters, and getters in printing API should be final

Reviewed-by: kcr, psadhukhan

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From nlisker at openjdk.java.net  Fri Jul 16 17:24:27 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 16 Jul 2021 17:24:27 GMT
Subject: RFR: 8270838: Remove deprecated protected access members from
 DateTimeStringConverter
Message-ID: 

`protected` members were changed to package visibility.

-------------

Commit messages:
 - Removes deprecated memebers

Changes: https://git.openjdk.java.net/jfx/pull/578/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=578&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270838
  Stats: 31 lines in 1 file changed: 0 ins; 25 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/578.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/578/head:pull/578

PR: https://git.openjdk.java.net/jfx/pull/578

From kcr at openjdk.java.net  Fri Jul 16 18:00:06 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 18:00:06 GMT
Subject: RFR: 8270839: Remove deprecated implementation methods from Scene
Message-ID: 

This removes following implementation methods in Scene by making them package-scope. They were previously deprecated for removal by [JDK-8270246](https://bugs.openjdk.java.net/browse/JDK-8270246):

    public void disposePeer()
    public void enableInputMethodEvents(boolean enable)
    public void processKeyEvent(KeyEvent e) 

One of the test harness classes was calling `Scene::processKeyEvent` directly, so I changed it to call it via `SceneHelper`.

-------------

Commit messages:
 - 8270839: Remove deprecated implementation methods from Scene

Changes: https://git.openjdk.java.net/jfx/pull/579/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=579&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270839
  Stats: 25 lines in 2 files changed: 2 ins; 17 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/579.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/579/head:pull/579

PR: https://git.openjdk.java.net/jfx/pull/579

From kcr at openjdk.java.net  Fri Jul 16 18:06:54 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 18:06:54 GMT
Subject: RFR: 8270838: Remove deprecated protected access members from
 DateTimeStringConverter
In-Reply-To: 
References: 
Message-ID: 

On Fri, 16 Jul 2021 17:17:06 GMT, Nir Lisker  wrote:

> `protected` members were changed to package visibility.

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/578

From prr at openjdk.java.net  Fri Jul 16 21:12:55 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 16 Jul 2021 21:12:55 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v4]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 16 Jul 2021 13:41:15 GMT, Kevin Rushforth  wrote:

> > looks good..
> > However I have a different question...I was looking at printerProperty and I saw In l182, we are not checking for getDefaultPrinter() returns null or not but in l120, we do...Is it not required in l182?
> 
> It might be a good follow-on bug to skip lines 185-6 if `getDefaultPrinter()` is `null` (else it will NPE), but it's completely unrelated to this fix so wouldn't be done as part of this PR.

I don't think there's a problem here. 
Else we'd have had a thousand bug reports by now.
Printer can never be null. Its instaniated by the private PrinterJob constructor.
So perhaps more to the point is are the lines right before that necessary ?

              if (value == null) {
                    value = Printer.getDefaultPrinter();
                }

The public no-args factory method returns null if it can't find a printer and the one
where the app supplies the printer to the factory method that takes one it NPEs out in the internal constuctor
if you pass in the illegal value NULL as the printer.

There's a small issue there as the doc doesn't actually say that but anyone
who has tried it will have found out pretty quickly !

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Fri Jul 16 21:29:51 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 21:29:51 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v4]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 16 Jul 2021 21:09:45 GMT, Phil Race  wrote:

> Printer can never be null. Its instaniated by the private PrinterJob constructor.

If `Printer.getDefaultPrinter()` can never return null, then you are right that there is no bug here.

> So perhaps more to the point is are the lines right before that necessary ?
> 
>               if (value == null) {
>                     value = Printer.getDefaultPrinter();
>                 }

Yes, this null check is needed, since we specify that setting the `printer` property to `null` will use the default printer.

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From prr at openjdk.java.net  Fri Jul 16 21:39:53 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 16 Jul 2021 21:39:53 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v4]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 16 Jul 2021 21:26:52 GMT, Kevin Rushforth  wrote:

> Yes, this null check is needed, since we specify that setting the `printer` property to `null` will use the default printer.

oh yeah. So nothing to do here.

The only question is about the behaviour of
 public static final PrinterJob createPrinterJob(Printer printer)  {}
when called with null.

- Document the NPE
- Don't do anything 
-  Substitute the default printer and create the job and document this
- return null if there isn't one and document this.
-

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kcr at openjdk.java.net  Fri Jul 16 22:13:55 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Jul 2021 22:13:55 GMT
Subject: RFR: 8269638: Property methods, setters,
 and getters in printing API should be final [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 15 Jul 2021 18:06:44 GMT, Phil Race  wrote:

>> - Make various setters and getters and properties final as needed
>> - Move documentation to the property so the setters and getters inherit it, with an exception for the special case of JobSettings.setPageRanges()
>> - Override toString() on the properties in JobSettings so it doesn't delegate to the JobSettings class.
>> - Add a manual test program just so you can see what toString() does. No pass or fail, just informative.
>> 
>> This will need a CSR but I won't create that until the review is done.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269638: Property methods, setters, and getters in printing API should be final

I don't have a strong opinion on this one. I might lean toward the 3rd option, since it is consistent with calling `PrinterJob::setPrinter(null)` on an existing `PrinterJob`. It would also mean that `createPrinterJob(null)` and `createPrinterJob()` would be equivalent. Not sure how useful this equivalence would be.

-------------

PR: https://git.openjdk.java.net/jfx/pull/574

From kevin.rushforth at oracle.com  Fri Jul 16 22:36:39 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 16 Jul 2021 15:36:39 -0700
Subject: RFR: 8263095: Provide a way for a custom control to indicate that
 its userAgentStyleSheet has changed
In-Reply-To: 
References: 
Message-ID: 

OK, I think you've answered my first and third questions. The broader 
question then is whether this fills a general need, and if so, is 
allowing for a dynamic user agent style on a Control the best way to 
provide this feature? I'd like to hear from some of the other developers 
on this list.

As for the second question, I don't think the API you propose for 
dynamic user agent style-sheets is feasible in a way that maintains 
compatibility. The current API model is that the control itself provides 
its userAgentStylesheet by overriding the get method, returning a String 
specific to that control (or possibly a specific instance of that 
control, if the designer of that control wants to add such logic for 
some reason). You can't compatibly turn this API into a standard 
property. Our properties have final set/get/property methods for a 
reason. Namely, to satisfy the invariant that calling the set or get 
method is identical to calling the property method (this is key to 
allowing bindings and listeners to work in a consistent and predictable 
manner). Also, since existing controls that override the getter, they 
will know nothing about the setter. Applications may wonder why 
setUserAgentStylesheet(sheet) does not imply 
sheet.equals(getUserAgentStyleSheet()).

Off the top of my head I can think of three ways to resolve this 
depending on what app developers and custom controls developers would 
prefer to see:

A. Provide a property with some other name (i.e., not 
userAgentStylesheet). If the value of this new property is non-null it 
takes precedence over the userAgentStylesheet. When it changes, it 
causes the necessary reevaluation to happen. This is the closest to what 
you propose, but preserves backward compatibility. This add some 
additional complexity, which may or may not be justified.

B. Provide an "updateUserAgentStylesheet(String)" method that acts 
"like" a setter, but a control would be free to ignore (and a control 
that overrides the "getter" today would certainly ignore). This seems 
messy and has its own consistency issues. And it still doesn't solve the 
question of how the control indicates that it has change its user agent 
stylesheet.

C. Leave it up to the control to decide when and how to change the value 
of its userAgentStylesheet. Provide a boolean 
"dynamicUserAgentStylesheet" property indicating whether the 
userAgentStylesheet is dynamic (most likely likely the control would set 
it for itself). There might also need to be a way for a control to 
indicate that its value has changed. Given your use cases, this seems 
like a good fit.

There may be more options - e.g., a hybrid of B and C if setting this 
under app control is a thing many apps want to do (although in that 
case, why not just go with option A)? Maybe there something else I'm not 
thinking of right now that would work.

A follow-up question is whether and how this would interact with the 
proposed theming API that is also under discussion (maybe that 
discussion could be revived)?

Before we spend too much more time on the API discussion, I want to hear 
from other developers on the list as to the value proposition of doing 
this and how they would like to see it done.

-- Kevin

On 7/16/2021 4:15 AM, Alessandro Parisi wrote:
>> The next steps would be to send an email (you can reply to this thread),
>> with a clear description of your proposal.
>>
>> The focus should be on what problem you are solving and on the proposed
>> public API and behavioral changes. I suggest not (yet) referring to code
>> changes in your PR except for illustrative purposes. Start with what the
>> current behavior is, what problem that is causing, and what your
>> proposed solution is. By way of a counter-example, the "computeIfAbsent"
>> code fragment you included in your email and PR description is an
>> implementation detail; the concept that should be discussed is the
>> presumed stability of a Region's userAgentStyleSheet. This presumed
>> stability is documented in the spec, so start there, not with the code.
>>
>> If there is general agreement that this feature is a good thing to add
>> to JavaFX as public API, meaning it is something that would benefit
>> multiple app developers, the next step would be to review the proposed
>> API and behavioral changes. This can be done in the context of reviewing
>> the PR. The focus during this phase of review would be mainly on the
>> specification changes that would need to go into the API docs and be
>> included in the CSR.
>>
>> The above is good general guidance for getting any new non-trivial
>> feature added to the JavaFX API.
>>
>> As for the specifics of what you are proposing, the main things I would
>> like to see addressed during the initial discussion are:
>>
>> * When and why do custom controls typically want to provide a dynamic
>> userAgentStylesheet?
>> * How should a control indicate that its userAgentStyleSheet is dynamic?
>> By a separate property (read-only?) that it provides as an override?
>> Should it be dynamic by default (I am skeptical, myself)?
>> * Does an application that uses a custom control need to know whether or
>> not that control uses a dynamic userAgentStylesheet? Can it affect the
>> answer (e.g., you mentioned theming, can you be more specific)?
>>
>> -- Kevin
>>
> So, without talking about code, I'm going to explain what I want to achieve
> with this change.
>
> As of now, custom controls  can specify their userAgentStylesheet by
> overriding the getter inherited from Region. The documentation says:
>
>> An implementation may specify its own user-agent styles for this Region,
>> and its children, by overriding this method. Subclasses overriding this
>> method should not assume any particular implementation approach as to the
>> number and frequency with which it is called. For this reason, attempting
>> any kind of dynamic implementation (i.e. returning different user agent
>> stylesheet values) based on some state change is highly discouraged, as
>> there is no guarantee when, or even if, this method will be called.
>>
> The issue there is that the current implementation is not dynamic.
> To answer your first question:
>
>> When and why do custom controls typically want to provide a dynamic
>> userAgentStylesheet?
>>
> In my library, I currently have two custom controls. For each of them I
> have three stylesheets and I want the user  to choose the style they
> prefer. So, the control is one, but the styles are three, and I can only
> provide one userAgentStylesheet because it is not dynamic. The solution
> would be to create three different controls and each of them uses one of
> the three stylesheets. However, this would lead to code duplication for
> just a stylesheet change.
>
> To answer the third question:
>
>> Does an application that uses a custom control need to know whether or
>> not that control uses a dynamic userAgentStylesheet? Can it affect the
>> answer (e.g., you mentioned theming, can you be more specific)?
>>
> Keeping in mind what I said above, let's suppose the user is developing an
> app with dark theme as default. With a dynamic implementation of the
> userAgentStylesheet I could specify two or more stylesheets for my custom
> controls, one or more for light and dark styles, the user would just need
> to change the style. That's what I mean by theming. In my custom controls
> then I could specify a way to change the style (an enumerator for example).
> It's up to the user then to decide which style to use.
> So the control needs to specify a way to change the style and that's up to
> the library developer to decide how (like I said an enumerator would be a
> way to do it), and JavaFX must allow the control to change the userAgent
> dynamically and update the control on change.
>
> To answer your second question:
>
>> How should a control indicate that its userAgentStyleSheet is dynamic?
>>
> Using a property. Rather than just having a getter, we could introduce a
> property to store the userAgent.
> When the user changes the style, the property changes too. On change, the
> StyleManager should also be notified about the change so that the CSS can
> be recomputed

From jpereda at openjdk.java.net  Sat Jul 17 00:21:08 2021
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Sat, 17 Jul 2021 00:21:08 GMT
Subject: RFR: 8269639: [macos] Calling stage.setY(0) twice causes wrong popups
 location
Message-ID: 

As described in the issue, when the stage is moved to the screen top position, it is moved below the system menu bar. However, doing it twice doesn't trigger a native callback to the Java layer, and the stage yPosition doesn't get updated with the actual position of the application. This has several side effects, like the wrong popup control position.

This PR adds a callback in case set position doesn?t match actual position. 

It is only going to be called when the final position of the stage doesn't match the one that was set, which could happen in rare occasions, mainly due to constrains applied by the native layer, so it doesn't add any overhead.

A system test for MacOS is included.

-------------

Commit messages:
 - Add a callback in case set position doesn?t match actual position. Include test

Changes: https://git.openjdk.java.net/jfx/pull/580/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=580&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269639
  Stats: 136 lines in 2 files changed: 136 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/580.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/580/head:pull/580

PR: https://git.openjdk.java.net/jfx/pull/580

From jpereda at openjdk.java.net  Sat Jul 17 11:49:55 2021
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Sat, 17 Jul 2021 11:49:55 GMT
Subject: RFR: 8269374: Menu inoperable after setting stage to second
 monitor
In-Reply-To: 
References: 

Message-ID: 

On Thu, 15 Jul 2021 15:48:18 GMT, Ambarish Rapte  wrote:

>> On Windows, with two monitors with different DPI settings, if a JavaFX application changes screens (either by dragging or programmatically) there is a resize event to adjust the view to its new platform scale.
>> 
>> Note that there is already a [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java#L206) to `View::updateLocation` in WinWindow, right after `notifyMoveToAnotherScreen` and `notifyScaleChanged `. But this is done too soon, before the resize event. There are other MOVE events processed too (in a long complex chain of recursive calls to `WinWindow::setBounds`).
>> 
>> As a consequence, as commented in the issue [JDK-8269374](https://bugs.openjdk.java.net/browse/JDK-8269374), the view x/y coordinates are wrongly set using the _old_ X,Y values (from the previous screen) with the _new_ platform scale (from the new screen).
>> 
>> This PR adds an extra call to View::updateLocation` in WinWindow, forcing the view relocation on Windows after every resize event to fix the issue. With the correct location of the scene, the Menus are now perfectly aligned, and the mouse events are correctly processed. It doesn't have any side effect on other platforms.
>> 
>> There's a very small penalty, as this new relocation will be called whenever there is a resize event on Windows, but it simplifies the overhead of detecting when the change of screens is effectively done (including the chain of move/resize) events.
>> 
>> No tests are provided, since these would require a setup of two monitors with different DPI settings. However, the test case in the JBS issue can be used to validate the fix.
>
> I tested the fix with different scaling combinations, the issue reported in JBS does not occur with fix. But noticed a similar issue that occurs only if the primary screen is in landscape mode and external monitor is in portrait mode. This behavior is observed both with and without this change. The behavior may be unrelated to fix, in that it can be addressed separately. 
> @kevinrushforth  request you to take look and call on this.
> 
> Steps:
> 1. Primary screen, 125%, Landscape mode
> 2. Secondary screen, 100%, Portrait mode
> 3. Run the program attached to JBS
> 4. Move the Stage to secondary screen
> 5. Maximize Stage
> 6. Keep focus on the Stage and press Windows + Shift + Left key
> 7. Stage will be moved to primary screen
> 8. Click on menu, observe that location is not correct. Below is screenshot.
> 
> ![image](https://user-images.githubusercontent.com/11330676/125815141-5eeb3f3a-177f-4b09-b746-3a25f63bde44.png)
> 
> ----
> A slight different behavior can be observed with a change in step 6
> Follow same steps as above except at step 6: Click 'Change screen' button. Below is the screenshot
> 
> ![image](https://user-images.githubusercontent.com/11330676/125816635-27176ce3-923e-40f1-a632-8d7b4b30f1b5.png)

I can reproduce the issues mentioned by @arapte.

Even with two landscape screens, if you maximise (or just make it big enough) the app on the 100% monitor, and click the button to move it to the other, the app doesn't move correctly, stays more or less to the middle (with wrong scale), but menus location and scale are correct:

This issues probably require their own follow-up JBS?

-------------

PR: https://git.openjdk.java.net/jfx/pull/572

From kcr at openjdk.java.net  Sat Jul 17 12:25:49 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 17 Jul 2021 12:25:49 GMT
Subject: RFR: 8269374: Menu inoperable after setting stage to second
 monitor
In-Reply-To: 
References: 

Message-ID: 

On Sat, 17 Jul 2021 11:47:05 GMT, Jose Pereda  wrote:

> This issues probably require their own follow-up JBS?

Agreed. Can you file a new bug in JBS?

@arapte Unless you have any concerns, can you review / approve this fix now?

-------------

PR: https://git.openjdk.java.net/jfx/pull/572

From kcr at openjdk.java.net  Sat Jul 17 13:30:57 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 17 Jul 2021 13:30:57 GMT
Subject: RFR: 8269639: [macos] Calling stage.setY(0) twice causes wrong
 popups location
In-Reply-To: 
References: 
Message-ID: <3u5TN0fm2r1R0HJs7k_rGQD09fTHNdIdeaxgaPcu90Q=.ae06c34d-390b-419a-b67d-1f983efe3c21@github.com>

On Sat, 17 Jul 2021 00:15:48 GMT, Jose Pereda  wrote:

> As described in the issue, when the stage is moved to the screen top position, it is moved below the system menu bar. However, doing it twice doesn't trigger a native callback to the Java layer, and the stage yPosition doesn't get updated with the actual position of the application. This has several side effects, like the wrong popup control position.
> 
> This PR adds a callback in case set position doesn?t match actual position. 
> 
> It is only going to be called when the final position of the stage doesn't match the one that was set, which could happen in rare occasions, mainly due to constrains applied by the native layer, so it doesn't add any overhead.
> 
> A system test for MacOS is included.

The fix and the test looks good. I left one suggestion and two minor formatting comments on the test.

tests/system/src/test/java/test/javafx/stage/StageAtTopPositionTest.java line 25:

> 23:  * questions.
> 24:  */
> 25: package test.javafx.stage;

Minor: can you add a blank line before the `package` statement? (I realize we have a few existing classes that don't follow this)

tests/system/src/test/java/test/javafx/stage/StageAtTopPositionTest.java line 72:

> 70:             stage.setY(400);
> 71:             stage.addEventHandler(WindowEvent.WINDOW_SHOWN, e ->
> 72:                                     Platform.runLater(startupLatch::countDown));

Minor: indentation is a bit off if you intended to line it up.

tests/system/src/test/java/test/javafx/stage/StageAtTopPositionTest.java line 86:

> 84:             }
> 85:         } catch (InterruptedException ex) {
> 86:             fail("Unexpected exception: " + ex);

If you add `throws Exception` to the method, you can simplify this and replace the try/catch block with:

    assertTrue("Timeout waiting for FX runtime to start",
               startupLatch.await(15, TimeUnit.SECONDS));

(most of our newer tests do this)

-------------

PR: https://git.openjdk.java.net/jfx/pull/580

From kcr at openjdk.java.net  Sat Jul 17 14:19:49 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 17 Jul 2021 14:19:49 GMT
Subject: RFR: 8270838: Remove deprecated protected access members from
 DateTimeStringConverter
In-Reply-To: 
References: 
Message-ID: 

On Fri, 16 Jul 2021 17:17:06 GMT, Nir Lisker  wrote:

> `protected` members were changed to package visibility.

I just noticed that there are now a few place where the `@SuppressWarnings("removal")` annotation can be removed. See for example, [DateStringConverter.java#L130](https://github.com/openjdk/jfx/blob/70fc0da8d6912e00f3f18e010950b3a27c11ce99/modules/javafx.base/src/main/java/javafx/util/converter/DateStringConverter.java#L130). If you prefer, you can remove the now-unneeded annotations as part of [JDK-8250802](https://bugs.openjdk.java.net/browse/JDK-8250802).

-------------

PR: https://git.openjdk.java.net/jfx/pull/578

From fastegal at openjdk.java.net  Sat Jul 17 15:21:50 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Sat, 17 Jul 2021 15:21:50 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v3]
In-Reply-To: <0Wp2eQFYCkXpRNiLlsJFl7CvnpNNbOaPWFdtZnwvCII=.32a8cc13-3e49-42ef-9f6d-8620ff6b98b3@github.com>
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
 <0Wp2eQFYCkXpRNiLlsJFl7CvnpNNbOaPWFdtZnwvCII=.32a8cc13-3e49-42ef-9f6d-8620ff6b98b3@github.com>
Message-ID: 

On Fri, 16 Jul 2021 13:30:28 GMT, Kevin Rushforth  wrote:

>> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableRowProperty()
>>     public final TreeTableRow getTreeTableRow()
>> 
>> 
>> The get method has "Tree" in the name while the property method does not.
>> 
>> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableColumnProperty()
>>     public final TreeTableColumn getTableColumn()
>> 
>> 
>> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
>> 
>> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
>> 
>> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
>> 
>> In summary, the following changes are made to `TreeTableCell`:
>> 
>> 1. Deprecate the `getTreeTableRow` method.
>> 2. Add a `getTableRow` method.
>> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
>> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
>> 
>> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
>> 
>> NOTE: this is targeted to `jfx17`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Renamed updateTreeTable{Row,Column} to updateTable{Row,Column}

Looks good: verified failing/passing tests and that the deprecated methods are no longer used internally. 

left a single comment inline

modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableCell.java line 292:

> 290:             new ReadOnlyObjectWrapper>(this, "tableRow");
> 291:     private void setTableRow(TreeTableRow value) { tableRow.set(value); }
> 292:     public final TreeTableRow getTableRow() { return tableRow.get(); }

this method is new, so might need a since tag - don't know how to apply it, though (because the property itself is old)

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From nlisker at openjdk.java.net  Sat Jul 17 15:37:55 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Sat, 17 Jul 2021 15:37:55 GMT
Subject: RFR: 8270838: Remove deprecated protected access members from
 DateTimeStringConverter
In-Reply-To: 
References: 

Message-ID: 

On Sat, 17 Jul 2021 14:17:24 GMT, Kevin Rushforth  wrote:

> If you prefer, you can remove the now-unneeded annotations as part of [JDK-8250802](https://bugs.openjdk.java.net/browse/JDK-8250802).

That's preferred.

-------------

PR: https://git.openjdk.java.net/jfx/pull/578

From kcr at openjdk.java.net  Sat Jul 17 15:46:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 17 Jul 2021 15:46:52 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v3]
In-Reply-To: 
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
 <0Wp2eQFYCkXpRNiLlsJFl7CvnpNNbOaPWFdtZnwvCII=.32a8cc13-3e49-42ef-9f6d-8620ff6b98b3@github.com>

Message-ID: 

On Sat, 17 Jul 2021 15:14:41 GMT, Jeanette Winzenburg  wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Renamed updateTreeTable{Row,Column} to updateTable{Row,Column}
>
> modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableCell.java line 292:
> 
>> 290:             new ReadOnlyObjectWrapper>(this, "tableRow");
>> 291:     private void setTableRow(TreeTableRow value) { tableRow.set(value); }
>> 292:     public final TreeTableRow getTableRow() { return tableRow.get(); }
> 
> this method is new, so might need a since tag - don't know how to apply it, though (because the property itself is old)

I had briefly thought about this, but didn't try it because the docs are copied from the property itself, along with any `@since` tag. I can fix this by copying the docs for the property (which is only a single sentence, so there isn't much duplication), so I'll do that.

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From kcr at openjdk.java.net  Sat Jul 17 16:04:19 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 17 Jul 2021 16:04:19 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v4]
In-Reply-To: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>
Message-ID: 

> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
> 
> 
>     public final ReadOnlyObjectProperty> tableRowProperty()
>     public final TreeTableRow getTreeTableRow()
> 
> 
> The get method has "Tree" in the name while the property method does not.
> 
> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
> 
> 
>     public final ReadOnlyObjectProperty> tableColumnProperty()
>     public final TreeTableColumn getTableColumn()
> 
> 
> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
> 
> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
> 
> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
> 
> In summary, the following changes are made to `TreeTableCell`:
> 
> 1. Deprecate the `getTreeTableRow` method.
> 2. Add a `getTableRow` method.
> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
> 
> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
> 
> NOTE: this is targeted to `jfx17`.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Added javadoc comments for new getTableCell method so we can add an @since tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/575/files
  - new: https://git.openjdk.java.net/jfx/pull/575/files/5c519ed1..ffb85ca3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=575&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=575&range=02-03

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/575.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/575/head:pull/575

PR: https://git.openjdk.java.net/jfx/pull/575

From fastegal at openjdk.java.net  Sat Jul 17 16:07:56 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Sat, 17 Jul 2021 16:07:56 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v4]
In-Reply-To: 
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>

Message-ID: 

On Sat, 17 Jul 2021 16:04:19 GMT, Kevin Rushforth  wrote:

>> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableRowProperty()
>>     public final TreeTableRow getTreeTableRow()
>> 
>> 
>> The get method has "Tree" in the name while the property method does not.
>> 
>> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableColumnProperty()
>>     public final TreeTableColumn getTableColumn()
>> 
>> 
>> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
>> 
>> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
>> 
>> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
>> 
>> In summary, the following changes are made to `TreeTableCell`:
>> 
>> 1. Deprecate the `getTreeTableRow` method.
>> 2. Add a `getTableRow` method.
>> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
>> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
>> 
>> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
>> 
>> NOTE: this is targeted to `jfx17`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added javadoc comments for new getTableCell method so we can add an @since tag

Marked as reviewed by fastegal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From jpereda at openjdk.java.net  Sat Jul 17 20:47:57 2021
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Sat, 17 Jul 2021 20:47:57 GMT
Subject: RFR: 8269374: Menu inoperable after setting stage to second
 monitor
In-Reply-To: 
References: 

Message-ID: 

On Thu, 15 Jul 2021 15:48:18 GMT, Ambarish Rapte  wrote:

>> On Windows, with two monitors with different DPI settings, if a JavaFX application changes screens (either by dragging or programmatically) there is a resize event to adjust the view to its new platform scale.
>> 
>> Note that there is already a [call](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinWindow.java#L206) to `View::updateLocation` in WinWindow, right after `notifyMoveToAnotherScreen` and `notifyScaleChanged `. But this is done too soon, before the resize event. There are other MOVE events processed too (in a long complex chain of recursive calls to `WinWindow::setBounds`).
>> 
>> As a consequence, as commented in the issue [JDK-8269374](https://bugs.openjdk.java.net/browse/JDK-8269374), the view x/y coordinates are wrongly set using the _old_ X,Y values (from the previous screen) with the _new_ platform scale (from the new screen).
>> 
>> This PR adds an extra call to View::updateLocation` in WinWindow, forcing the view relocation on Windows after every resize event to fix the issue. With the correct location of the scene, the Menus are now perfectly aligned, and the mouse events are correctly processed. It doesn't have any side effect on other platforms.
>> 
>> There's a very small penalty, as this new relocation will be called whenever there is a resize event on Windows, but it simplifies the overhead of detecting when the change of screens is effectively done (including the chain of move/resize) events.
>> 
>> No tests are provided, since these would require a setup of two monitors with different DPI settings. However, the test case in the JBS issue can be used to validate the fix.
>
> I tested the fix with different scaling combinations, the issue reported in JBS does not occur with fix. But noticed a similar issue that occurs only if the primary screen is in landscape mode and external monitor is in portrait mode. This behavior is observed both with and without this change. The behavior may be unrelated to fix, in that it can be addressed separately. 
> @kevinrushforth  request you to take look and call on this.
> 
> Steps:
> 1. Primary screen, 125%, Landscape mode
> 2. Secondary screen, 100%, Portrait mode
> 3. Run the program attached to JBS
> 4. Move the Stage to secondary screen
> 5. Maximize Stage
> 6. Keep focus on the Stage and press Windows + Shift + Left key
> 7. Stage will be moved to primary screen
> 8. Click on menu, observe that location is not correct. Below is screenshot.
> 
> ![image](https://user-images.githubusercontent.com/11330676/125815141-5eeb3f3a-177f-4b09-b746-3a25f63bde44.png)
> 
> ----
> A slight different behavior can be observed with a change in step 6
> Follow same steps as above except at step 6: Click 'Change screen' button. Below is the screenshot
> 
> ![image](https://user-images.githubusercontent.com/11330676/125816635-27176ce3-923e-40f1-a632-8d7b4b30f1b5.png)

I've filed [JDK-8270868](https://bugs.openjdk.java.net/browse/JDK-8270868), and also investigated the possible root cause of the issue. It turns out there is a reason for the issues @arapte notified, as those happened with a full screen.

-------------

PR: https://git.openjdk.java.net/jfx/pull/572

From jpereda at openjdk.java.net  Sun Jul 18 11:01:30 2021
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Sun, 18 Jul 2021 11:01:30 GMT
Subject: RFR: 8269639: [macos] Calling stage.setY(0) twice causes wrong
 popups location [v2]
In-Reply-To: <3u5TN0fm2r1R0HJs7k_rGQD09fTHNdIdeaxgaPcu90Q=.ae06c34d-390b-419a-b67d-1f983efe3c21@github.com>
References: 
 <3u5TN0fm2r1R0HJs7k_rGQD09fTHNdIdeaxgaPcu90Q=.ae06c34d-390b-419a-b67d-1f983efe3c21@github.com>
Message-ID: 

On Sat, 17 Jul 2021 12:23:47 GMT, Kevin Rushforth  wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback from reviewer
>
> tests/system/src/test/java/test/javafx/stage/StageAtTopPositionTest.java line 25:
> 
>> 23:  * questions.
>> 24:  */
>> 25: package test.javafx.stage;
> 
> Minor: can you add a blank line before the `package` statement? (I realize we have a few existing classes that don't follow this)

Done

> tests/system/src/test/java/test/javafx/stage/StageAtTopPositionTest.java line 72:
> 
>> 70:             stage.setY(400);
>> 71:             stage.addEventHandler(WindowEvent.WINDOW_SHOWN, e ->
>> 72:                                     Platform.runLater(startupLatch::countDown));
> 
> Minor: indentation is a bit off if you intended to line it up.

Fixed

> tests/system/src/test/java/test/javafx/stage/StageAtTopPositionTest.java line 86:
> 
>> 84:             }
>> 85:         } catch (InterruptedException ex) {
>> 86:             fail("Unexpected exception: " + ex);
> 
> If you add `throws Exception` to the method, you can simplify this and replace the try/catch block with:
> 
> 
>     assertTrue("Timeout waiting for FX runtime to start",
>                startupLatch.await(15, TimeUnit.SECONDS));
> 
> 
> (most of our newer tests do this)

Done

-------------

PR: https://git.openjdk.java.net/jfx/pull/580

From jpereda at openjdk.java.net  Sun Jul 18 11:01:23 2021
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Sun, 18 Jul 2021 11:01:23 GMT
Subject: RFR: 8269639: [macos] Calling stage.setY(0) twice causes wrong
 popups location [v2]
In-Reply-To: 
References: 
Message-ID: 

> As described in the issue, when the stage is moved to the screen top position, it is moved below the system menu bar. However, doing it twice doesn't trigger a native callback to the Java layer, and the stage yPosition doesn't get updated with the actual position of the application. This has several side effects, like the wrong popup control position.
> 
> This PR adds a callback in case set position doesn?t match actual position. 
> 
> It is only going to be called when the final position of the stage doesn't match the one that was set, which could happen in rare occasions, mainly due to constrains applied by the native layer, so it doesn't add any overhead.
> 
> A system test for MacOS is included.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Address feedback from reviewer

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/580/files
  - new: https://git.openjdk.java.net/jfx/pull/580/files/fb07b048..bf35aac6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=580&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=580&range=00-01

  Stats: 12 lines in 1 file changed: 2 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/580.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/580/head:pull/580

PR: https://git.openjdk.java.net/jfx/pull/580

From aghaisas at openjdk.java.net  Mon Jul 19 05:31:53 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 19 Jul 2021 05:31:53 GMT
Subject: [jfx17] RFR: 8270314: TreeTableCell: inconsistent naming for
 tableRow and tableColumn property methods [v4]
In-Reply-To: 
References: <_r2DiXB1IifUe0aBOAA8z-l4XaJ3lxAvG81mv8mfDxk=.d637f752-3785-4b74-bff6-0f521bd65305@github.com>

Message-ID: 

On Sat, 17 Jul 2021 16:04:19 GMT, Kevin Rushforth  wrote:

>> In the `TreeTableCell` class there is a mismatch between name of the following property method vs the getter:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableRowProperty()
>>     public final TreeTableRow getTreeTableRow()
>> 
>> 
>> The get method has "Tree" in the name while the property method does not.
>> 
>> By contrast, the corresponding methods for column are self-consistent, and are named without "Tree" in the name:
>> 
>> 
>>     public final ReadOnlyObjectProperty> tableColumnProperty()
>>     public final TreeTableColumn getTableColumn()
>> 
>> 
>> The solution is to effectively change `getTreeTableRow()` to `getTableRow()`. In order to preserve source and binary compatibility, the method is copied rather than renamed. The existing `getTreeTableRow()` method is deprecated (not for removal).
>> 
>> Additionally, the docs for each property is on a private property field that *does* have tree in the name, which results in no docs being generated for either the `tableRow` or `tableColumn` property.
>> 
>> Finally, there is a problem with the implementation of the `tableRowProperty()` method in that it returns the writable property by mistake rather than the read-only property that is specified by the method's return type.
>> 
>> In summary, the following changes are made to `TreeTableCell`:
>> 
>> 1. Deprecate the `getTreeTableRow` method.
>> 2. Add a `getTableRow` method.
>> 3. Rename the (private) property object fields from `treeTableRow` and `treeTableColumn` to `tableRow` and `tableColumn`, including the name of the bean, so that they match the public property method names. This will allow API docs to be generated.
>> 4. Change the implementation of the tableRowProperty() method to return a read-only property.
>> 
>> In addition to changing the existing implementation and tests to call the new `getTableRow` method instead of the now-deprecated `getTreeTableRow` method, I added unit tests to validate changes 3 and 4.
>> 
>> NOTE: this is targeted to `jfx17`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added javadoc comments for new getTableCell method so we can add an @since tag

Marked as reviewed by aghaisas (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/575

From kevin.rushforth at oracle.com  Mon Jul 19 16:35:28 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 19 Jul 2021 09:35:28 -0700
Subject: Mailing list problems
Message-ID: 

We are seeing problems with mail being delivered to the openjdk mailing 
lists, including openjfx-dev. This means that while Skara is still 
processing PRs, there is no email notification sent for them.

Given the outage, I'm not sure whether this email will be delivered.

-- Kevin

From kevin.rushforth at oracle.com  Tue Jul 20 16:00:01 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 20 Jul 2021 09:00:01 -0700
Subject: [jfx17] RFR: Request to sync October July 2021 changes into jfx
Message-ID: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com>

Hi Johan,

I request approval to sync changes from to the just-released July 2021 
CPU release into the 'jfx17' branch of the 'jfx' repo. Here is the 
aggregate set of changes for the fixes:

https://github.com/kevinrushforth/jfx/compare/85014165a6...cpu-2107-sync

NOTE: Since this is an integration of already-reviewed fixes, I will 
push it directly to the jfx17 branch of the jfx repo rather than via a 
pull request.

-- Kevin

From kevin.rushforth at oracle.com  Tue Jul 20 16:00:13 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 20 Jul 2021 09:00:13 -0700
Subject: [jfx11u] RFR: Request to backport July 2021 CPU changes
Message-ID: <69f04003-0fdc-5ca8-d772-074c08e82833@oracle.com>

Hi Johan,

I request approval to backport the changes from the just-released July 
2021 CPU to jfx11u (for 11.0.12) .

https://github.com/kevinrushforth/jfx11u/compare/db9b1b7440...cpu-2107-sync

This is a straight backport (patch applies cleanly) of the one FX fix 
that went into the July CPU.

NOTE: Since this is an integration of already-reviewed fixes, I will 
push it directly to the master branch of the jfx11u repo rather than via 
a pull request.

Thanks.

-- Kevin

From kevin.rushforth at oracle.com  Tue Jul 20 16:12:45 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 20 Jul 2021 09:12:45 -0700
Subject: [jfx17] RFR: Request to sync July 2021 changes into jfx
In-Reply-To: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com>
References: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com>
Message-ID: <956ddd6d-d484-b73b-5dfc-7f23e32c3b50@oracle.com>

[Fixed subject line]

Hi Johan,

I request approval to sync changes from to the just-released July 2021 
CPU release into the 'jfx17' branch of the 'jfx' repo. Here is the 
aggregate set of changes for the fixes:

https://github.com/kevinrushforth/jfx/compare/85014165a6...cpu-2107-sync

NOTE: Since this is an integration of already-reviewed fixes, I will 
push it directly to the jfx17 branch of the jfx repo rather than via a 
pull request.

-- Kevin

From johan.vos at gluonhq.com  Tue Jul 20 16:20:02 2021
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 20 Jul 2021 18:20:02 +0200
Subject: [jfx17] RFR: Request to sync October July 2021 changes into jfx
In-Reply-To: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com>
References: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com>
Message-ID: 

Approved

On Tue, Jul 20, 2021 at 6:00 PM Kevin Rushforth 
wrote:

> Hi Johan,
>
> I request approval to sync changes from to the just-released July 2021
> CPU release into the 'jfx17' branch of the 'jfx' repo. Here is the
> aggregate set of changes for the fixes:
>
> https://github.com/kevinrushforth/jfx/compare/85014165a6...cpu-2107-sync
>
> NOTE: Since this is an integration of already-reviewed fixes, I will
> push it directly to the jfx17 branch of the jfx repo rather than via a
> pull request.
>
> -- Kevin
>
>

From johan.vos at gluonhq.com  Tue Jul 20 16:20:20 2021
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 20 Jul 2021 18:20:20 +0200
Subject: [jfx11u] RFR: Request to backport July 2021 CPU changes
In-Reply-To: <69f04003-0fdc-5ca8-d772-074c08e82833@oracle.com>
References: <69f04003-0fdc-5ca8-d772-074c08e82833@oracle.com>
Message-ID: 

Approved.

- Johan

On Tue, Jul 20, 2021 at 6:01 PM Kevin Rushforth 
wrote:

> Hi Johan,
>
> I request approval to backport the changes from the just-released July
> 2021 CPU to jfx11u (for 11.0.12) .
>
> https://github.com/kevinrushforth/jfx11u/compare/db9b1b7440...cpu-2107-sync
>
> This is a straight backport (patch applies cleanly) of the one FX fix
> that went into the July CPU.
>
> NOTE: Since this is an integration of already-reviewed fixes, I will
> push it directly to the master branch of the jfx11u repo rather than via
> a pull request.
>
> Thanks.
>
> -- Kevin
>
>

From johan.vos at gluonhq.com  Tue Jul 20 16:20:36 2021
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 20 Jul 2021 18:20:36 +0200
Subject: [jfx17] RFR: Request to sync July 2021 changes into jfx
In-Reply-To: <956ddd6d-d484-b73b-5dfc-7f23e32c3b50@oracle.com>
References: <2ad5d6d0-b3c5-75ac-1a04-5176292379fd@oracle.com>
 <956ddd6d-d484-b73b-5dfc-7f23e32c3b50@oracle.com>
Message-ID: 

Approved.

- Johan

On Tue, Jul 20, 2021 at 6:12 PM Kevin Rushforth 
wrote:

> [Fixed subject line]
>
> Hi Johan,
>
> I request approval to sync changes from to the just-released July 2021
> CPU release into the 'jfx17' branch of the 'jfx' repo. Here is the
> aggregate set of changes for the fixes:
>
> https://github.com/kevinrushforth/jfx/compare/85014165a6...cpu-2107-sync
>
> NOTE: Since this is an integration of already-reviewed fixes, I will
> push it directly to the jfx17 branch of the jfx repo rather than via a
> pull request.
>
> -- Kevin
>
>

From florian.kirmaier at gmail.com  Wed Jul 21 11:33:32 2021
From: florian.kirmaier at gmail.com (Florian Kirmaier)
Date: Wed, 21 Jul 2021 13:33:32 +0200
Subject: RFR: MemoryLeak: Scene.dirtyNodes and Parent.removed
Message-ID: 

Hi everyone,

I've now found a possible fix for a memory leak I discovered several weeks
ago.

Can someone take a look into it?

issue: https://bugs.openjdk.java.net/browse/JDK-8269907
PR: https://github.com/openjdk/jfx/pull/584

Greetings Florian

From arapte at openjdk.java.net  Thu Jul 22 10:03:49 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 22 Jul 2021 10:03:49 GMT
Subject: RFR: 8270839: Remove deprecated implementation methods from Scene
 [v2]
In-Reply-To: <9IflitN_wAkrobXkYNmm1olqOUbjEmy00YnNCH_k9yg=.5aacf10d-0e8a-4edf-aaf5-678b9e5560a0@github.com>
References: 
 <9IflitN_wAkrobXkYNmm1olqOUbjEmy00YnNCH_k9yg=.5aacf10d-0e8a-4edf-aaf5-678b9e5560a0@github.com>
Message-ID: 

On Tue, 20 Jul 2021 20:37:17 GMT, Kevin Rushforth  wrote:

>> This removes following implementation methods in Scene by making them package-scope. They were previously deprecated for removal by [JDK-8270246](https://bugs.openjdk.java.net/browse/JDK-8270246):
>> 
>> 
>>     public void disposePeer()
>>     public void enableInputMethodEvents(boolean enable)
>>     public void processKeyEvent(KeyEvent e) 
>> 
>> 
>> One of the test harness classes was calling `Scene::processKeyEvent` directly, so I changed it to call it via `SceneHelper`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Export com.sun.javafx.scene to system tests to fix test failure

Looks good to me.

-------------

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/579

From fkirmaier at openjdk.java.net  Thu Jul 22 11:50:11 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 22 Jul 2021 11:50:11 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v2]
In-Reply-To: 
References: 
Message-ID: 

> After thinking about this issue for some time, I've now got a solution.
> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. 
> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8269907
  The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks.

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/584/files
  - new: https://git.openjdk.java.net/jfx/pull/584/files/56c2c8dc..c603d2b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=584&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=584&range=00-01

  Stats: 42 lines in 2 files changed: 31 ins; 11 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/584.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/584/head:pull/584

PR: https://git.openjdk.java.net/jfx/pull/584

From fkirmaier at openjdk.java.net  Thu Jul 22 11:50:12 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 22 Jul 2021 11:50:12 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 Jul 2021 11:29:38 GMT, Florian Kirmaier  wrote:

> After thinking about this issue for some time, I've now got a solution.
> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. 
> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important.

During the past PRs the unit tests were quite unstable, but they seem to work.

I've reworked my fix. It now registers a pulseListener for the cleanup. The is also how i initially thought, the fix should look like. To do so, I've added the option to the Toolkit to register such listeners. 

The fix no longer has the drawback, of rerendering the whole window, when it's showing property is changed.

-------------

PR: https://git.openjdk.java.net/jfx/pull/584

From kcr at openjdk.java.net  Thu Jul 22 12:33:50 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 22 Jul 2021 12:33:50 GMT
Subject: [jfx17] RFR: 8270959: Update boot JDK to 16.0.2
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Jul 2021 18:58:08 GMT, Kevin Rushforth  wrote:

> Update boot JDK used to build JavaFX to JDK 16.0.2, which supersedes 16.0.1.
> 
> NOTE: this is targeted to `jfx17`.

@johanvos or @tiainen can one of you be the second reviewer for this?

-------------

PR: https://git.openjdk.java.net/jfx/pull/583

From kcr at openjdk.java.net  Thu Jul 22 12:42:47 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 22 Jul 2021 12:42:47 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v2]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 22 Jul 2021 11:50:11 GMT, Florian Kirmaier  wrote:

>> After thinking about this issue for some time, I've now got a solution.
>> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. 
>> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269907
>   The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks.

The revised approach doesn't appear to have the same threading issues that the first attempt did (good). I would have thought you could add some logic to the existing scene pulse listener instead of creating a new one. I'll take a closer look when I review this.

-------------

PR: https://git.openjdk.java.net/jfx/pull/584

From aghaisas at openjdk.java.net  Thu Jul 22 13:44:47 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 22 Jul 2021 13:44:47 GMT
Subject: RFR: 8270839: Remove deprecated implementation methods from Scene
 [v2]
In-Reply-To: <9IflitN_wAkrobXkYNmm1olqOUbjEmy00YnNCH_k9yg=.5aacf10d-0e8a-4edf-aaf5-678b9e5560a0@github.com>
References: 
 <9IflitN_wAkrobXkYNmm1olqOUbjEmy00YnNCH_k9yg=.5aacf10d-0e8a-4edf-aaf5-678b9e5560a0@github.com>
Message-ID: <9OExpLXpIVI85c-yeWyMbA0_kXTtY5ARP7797n4XjKI=.ad6c74f2-3e93-42aa-b50a-5f70f4f47ce9@github.com>

On Tue, 20 Jul 2021 20:37:17 GMT, Kevin Rushforth  wrote:

>> This removes following implementation methods in Scene by making them package-scope. They were previously deprecated for removal by [JDK-8270246](https://bugs.openjdk.java.net/browse/JDK-8270246):
>> 
>> 
>>     public void disposePeer()
>>     public void enableInputMethodEvents(boolean enable)
>>     public void processKeyEvent(KeyEvent e) 
>> 
>> 
>> One of the test harness classes was calling `Scene::processKeyEvent` directly, so I changed it to call it via `SceneHelper`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Export com.sun.javafx.scene to system tests to fix test failure

Marked as reviewed by aghaisas (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/579

From kevin.rushforth at oracle.com  Thu Jul 22 17:57:27 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 22 Jul 2021 10:57:27 -0700
Subject: RFR: 8270839: Remove deprecated implementation methods from Scene
 [v2]
In-Reply-To: <9OExpLXpIVI85c-yeWyMbA0_kXTtY5ARP7797n4XjKI=.ad6c74f2-3e93-42aa-b50a-5f70f4f47ce9@github.com>
References: 
 <9IflitN_wAkrobXkYNmm1olqOUbjEmy00YnNCH_k9yg=.5aacf10d-0e8a-4edf-aaf5-678b9e5560a0@github.com>
 <9OExpLXpIVI85c-yeWyMbA0_kXTtY5ARP7797n4XjKI=.ad6c74f2-3e93-42aa-b50a-5f70f4f47ce9@github.com>
Message-ID: <0b8cc614-6524-024c-20ab-64265aed9e73@oracle.com>

On 7/22/2021 6:44 AM, Ajit Ghaisas wrote:
>
> Marked as reviewed by aghaisas (Reviewer).

I'll integrate as soon as the CSR is approved (I've moved it to 
"Finalized").

(Btw, I'm replying directly to the email list to see whether Skara's 
`mlbridge` bot is working in this direction following the outage earlier 
in the week)

-- Kevin

From mhanl at openjdk.java.net  Thu Jul 22 19:19:06 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Thu, 22 Jul 2021 19:19:06 GMT
Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit
In-Reply-To: 
References: 

Message-ID: 

On Mon, 12 Jul 2021 12:49:15 GMT, Jeanette Winzenburg  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?

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()**.

-------------

PR: https://git.openjdk.java.net/jfx/pull/569

From jvos at openjdk.java.net  Thu Jul 22 19:29:09 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Thu, 22 Jul 2021 19:29:09 GMT
Subject: [jfx17] RFR: 8270959: Update boot JDK to 16.0.2
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Jul 2021 18:58:08 GMT, Kevin Rushforth  wrote:

> Update boot JDK used to build JavaFX to JDK 16.0.2, which supersedes 16.0.1.
> 
> NOTE: this is targeted to `jfx17`.

We'll check on all platforms.

-------------

PR: https://git.openjdk.java.net/jfx/pull/583

From mhanl at openjdk.java.net  Thu Jul 22 19:39:09 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Thu, 22 Jul 2021 19:39:09 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v4]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 7 Jul 2021 19:37:23 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()**
>> 
>> ~~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 two additional commits since the last revision:
> 
>  - Fixed NPE for setEditable() and layoutChildren()
>  - removed unneeded button cell in test

> Not aware of such a rule - if we fix code throwing an exception there is not much to assert, except that it fails before and passes after. And paddling back a bit, I think a separate test for the back switch would be overdoing it :)

There is no rule, but in my opinion it's simply better and more meaningful with an assert (maybe this also come's a bit from Sonar ?? ). But you are right, the checks are not really needed and thinking about it they can be confusing as well. So I will update the PR. 
But I'm also interested in other opinions. 
It would be perfect for me if we have a nice way to indicate, that a Unit test expects no exception. (I now wrote a comment on every method which triggers the NPE)

-------------

PR: https://git.openjdk.java.net/jfx/pull/557

From mhanl at openjdk.java.net  Thu Jul 22 19:49:44 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Thu, 22 Jul 2021 19:49:44 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v5]
In-Reply-To: 
References: 
Message-ID: 

> 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()**
> - 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 two additional commits since the last revision:

 - removed unneeded assert and added comment
 - removed unneeded asserts and added another NPE fix.

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/557/files
  - new: https://git.openjdk.java.net/jfx/pull/557/files/b064f61e..039b826b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=557&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=557&range=03-04

  Stats: 33 lines in 2 files changed: 20 ins; 11 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/557.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/557/head:pull/557

PR: https://git.openjdk.java.net/jfx/pull/557

From kcr at openjdk.java.net  Thu Jul 22 21:43:08 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 22 Jul 2021 21:43:08 GMT
Subject: Integrated: 8270839: Remove deprecated implementation methods from
 Scene
In-Reply-To: 
References: 
Message-ID: <6UYiplJ_lMaDCzQcCfx_4YsVj6q7asKs_TVZO9VLjog=.c8555ac8-7527-47d6-929b-14dca2d3b4cb@github.com>

On Fri, 16 Jul 2021 17:53:21 GMT, Kevin Rushforth  wrote:

> This removes following implementation methods in Scene by making them package-scope. They were previously deprecated for removal by [JDK-8270246](https://bugs.openjdk.java.net/browse/JDK-8270246):
> 
> 
>     public void disposePeer()
>     public void enableInputMethodEvents(boolean enable)
>     public void processKeyEvent(KeyEvent e) 
> 
> 
> One of the test harness classes was calling `Scene::processKeyEvent` directly, so I changed it to call it via `SceneHelper`.

This pull request has now been integrated.

Changeset: 97d70afb
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/97d70afb74c5a2599326796ccc9ce799d76e0b96
Stats:     26 lines in 3 files changed: 3 ins; 17 del; 6 mod

8270839: Remove deprecated implementation methods from Scene

Reviewed-by: arapte, aghaisas

-------------

PR: https://git.openjdk.java.net/jfx/pull/579

From kcr at openjdk.java.net  Thu Jul 22 22:13:38 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 22 Jul 2021 22:13:38 GMT
Subject: [jfx17] RFR: 8271086: Block comments of form '/***' are treated as
 javadoc comments
Message-ID: 

This fix for [JDK-8271086](https://bugs.openjdk.java.net/browse/JDK-8271086) is part of a larger cleanup effort to find and fix places where we have missing or redundant API comments. See [JDK-8271083](https://bugs.openjdk.java.net/browse/JDK-8271083).

This fixes a long-standing problem dating back to (at least) JavaFX 2 where block comments of the following form are sometimes treated as javadoc comments:

    /***************************************************************************
     * ...
     **************************************************************************/

There are several places where a block comment like this unintentionally shows up in our API documentation. For example, see the generated docs for [Node::getNodeOrientation](https://openjfx.io/javadoc/16/javafx.graphics/javafx/scene/Node.html#getNodeOrientation%28%29) where the literal string `* Component Orientation Properties * *` is presented in the docs.

The best solution is to simply eliminate this style of block comment as an anti-pattern everywhere it occurs in our Java code.

There are a total of 982 such occurrences (in 185 different files). All but 7 of these follow the pattern shown above, where the trimmed first line of the block is a single `/` followed by 4 or more `*` characters, and contains no other characters. Like this:

    /***************************************************************************

The remaining 7 are comments with some variation, either being an inline comment (starting with `//`) or having text in the middle, or in one case is intended to be a javadoc comment, but with an extra `*` -- `/***` rather than `/**`. I fixed those 7 manually and then ran a script to fix the remaining 975 comments, by replacing the 2nd `*` with a space (thus preserving the line length).

So:

    /***************************************************************************

becomes

    /* *************************************************************************

## Notes to Reviewers

1. The 7 manual changes are in the first commit, and the automated changes are in the second comment. I have run a build + sanity test, and I did a diff of the generated API docs generated by `gradle javadoc` and also visually inspected the docs (spot checked), and confirmed that it fixes the problem.
2. This is targeted to `jfx17`.

-------------

Commit messages:
 - (automated) 8271086: Block comments of form '/***' are treated as javadoc comments
 - (manual) 8271086: Block comments of form '/***' are treated as javadoc comments

Changes: https://git.openjdk.java.net/jfx/pull/585/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=585&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271086
  Stats: 982 lines in 185 files changed: 0 ins; 0 del; 982 mod
  Patch: https://git.openjdk.java.net/jfx/pull/585.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/585/head:pull/585

PR: https://git.openjdk.java.net/jfx/pull/585

From kcr at openjdk.java.net  Fri Jul 23 00:19:13 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 23 Jul 2021 00:19:13 GMT
Subject: [jfx17] RFR: 8240640: [macos] Wrong focus behaviour with multiple
 Alerts
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Jul 2021 19:52:05 GMT, Pankaj Bansal  wrote:

> The bug is a regression as a result of fix done for JDK-8227366 and is reproducible on Linux and Mac. This fix is being reverted in this change and a new bug (JDK-8271054) has been created to redo the JDK-8227366
> 
> An automated testcase is being added to make sure similar regression is not introduced when working on the redo bug. The automated testcase fails without the current change and passes after the change.
> 
> The testcase works fine on Mac and Linux, but I see some issues in windows. The stage is minimised after calling stage.show without calling stage.setAlwaysOnTop(true). I see that there are other tests like DualWindowsTest.java which are failing for same reason. Also, if I remove the stage.setAlwaysOnTop(true) from tests like FocusParentWindowOnChildCloseTest.java,  the stage remains minimised there as well. This seems wrong as calling stage.setAlwaysOnTop(true) should not be required to bring stage window in focus on running the test. This may be an issue on my Window machine or something similar. I hope reviewers can shed some light on this.

The fix (reverting the earlier fix for JDK-8227366) looks fine to me. The test runs fine on Mac (and mostly fine on Linux, but I need to test a couple more things).

I also see the failure on Windows frequently depending on whether the Window initially gets focus. One thing you might try is to call `stage.toFront()` and `stage.requestFocus()` before showing the Alerts, although I'm not sure that will help. For other tests like this we do set the primary stage to be always on top, so that's probably the easiest. Failing that you could mark the test as unstable on Windows.

Btw, on my slow Linux VM, it occasionally fails because the window takes a bit too long to come up. I'll do some more testing once you fix the Windows issue.

I left a couple formatting comments on the test inline.

tests/system/src/test/java/test/robot/javafx/stage/WrongStageFocusWithApplicationModalityTest.java line 104:

> 102:         }
> 103: 
> 104:         private void showAlert(String title)

Minor: curly brace on same line as method.

tests/system/src/test/java/test/robot/javafx/stage/WrongStageFocusWithApplicationModalityTest.java line 114:

> 112:         }
> 113:     }
> 114: }

Minor: add missing newline.

-------------

PR: https://git.openjdk.java.net/jfx/pull/581

From sykora at openjdk.java.net  Fri Jul 23 11:17:01 2021
From: sykora at openjdk.java.net (Joeri Sykora)
Date: Fri, 23 Jul 2021 11:17:01 GMT
Subject: [jfx17] RFR: 8270959: Update boot JDK to 16.0.2
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Jul 2021 18:58:08 GMT, Kevin Rushforth  wrote:

> Update boot JDK used to build JavaFX to JDK 16.0.2, which supersedes 16.0.1.
> 
> NOTE: this is targeted to `jfx17`.

Build succeeded on all platforms.

-------------

Marked as reviewed by sykora (Author).

PR: https://git.openjdk.java.net/jfx/pull/583

From mhanl at openjdk.java.net  Fri Jul 23 11:33:08 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Fri, 23 Jul 2021 11:33:08 GMT
Subject: RFR: 8240506: TextFieldSkin/Behavior: misbehavior on switching
 skin [v2]
In-Reply-To: 
References: 

Message-ID: <8k7Q6S8hMhxKhQd3_Bnzr1RZfIaehgVKUhe-fpvmknQ=.8ed9e254-0b11-451e-b136-850a16930a7f@github.com>

On Wed, 7 Jul 2021 09:48:20 GMT, Jeanette Winzenburg  wrote:

>> The issue is about memory leaks and side-effects (like NPEs) when switching skins. 
>> 
>> Details (copied from issue for convenience):
>> 
>> memory leak in TextInputControlBehavior:
>> - listener accidentally added twice (removed once)
>> - keyPad mappings not properly installed/disposed
>> 
>> memory leak TextFieldBehavior:
>> - listeners to scene/focusOwner property not removed,
>> 
>> memory leak in TextInputControlSkin:
>> - event handlers related to inputMethods not removed
>> 
>> issues in TextFieldSkin:
>> - memory leak due to behavior leaking
>> - memory leaks due to manually added change/invalidation listeners that are not removed
>> - memory leaks due to not removing children with strong references to skin
>> - side-effects (f.i. NPEs) due to listeners/bindings that are still active after dispose
>> 
>> Fix was to properly install/remove those listeners/handlers. Added tests that failed/passed before/after the fix, respectively, also added tests passing before that must pass after the fix.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed review issues

Sorry for the delay. Looks good to me. :)

-------------

Marked as reviewed by mhanl (Author).

PR: https://git.openjdk.java.net/jfx/pull/534

From kcr at openjdk.java.net  Fri Jul 23 11:44:08 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 23 Jul 2021 11:44:08 GMT
Subject: [jfx17] Integrated: 8270959: Update boot JDK to 16.0.2
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Jul 2021 18:58:08 GMT, Kevin Rushforth  wrote:

> Update boot JDK used to build JavaFX to JDK 16.0.2, which supersedes 16.0.1.
> 
> NOTE: this is targeted to `jfx17`.

This pull request has now been integrated.

Changeset: d5401095
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/d5401095f7655f281e9cb5006caf95bc6d0695d5
Stats:     11 lines in 2 files changed: 0 ins; 0 del; 11 mod

8270959: Update boot JDK to 16.0.2

Reviewed-by: arapte, sykora

-------------

PR: https://git.openjdk.java.net/jfx/pull/583

From kcr at openjdk.java.net  Fri Jul 23 13:04:05 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 23 Jul 2021 13:04:05 GMT
Subject: [jfx17] RFR: 8240640: [macos] Wrong focus behaviour with multiple
 Alerts
In-Reply-To: 
References: 
Message-ID: 

On Mon, 19 Jul 2021 19:52:05 GMT, Pankaj Bansal  wrote:

> The bug is a regression as a result of fix done for JDK-8227366 and is reproducible on Linux and Mac. This fix is being reverted in this change and a new bug (JDK-8271054) has been created to redo the JDK-8227366
> 
> An automated testcase is being added to make sure similar regression is not introduced when working on the redo bug. The automated testcase fails without the current change and passes after the change.
> 
> The testcase works fine on Mac and Linux, but I see some issues in windows. The stage is minimised after calling stage.show without calling stage.setAlwaysOnTop(true). I see that there are other tests like DualWindowsTest.java which are failing for same reason. Also, if I remove the stage.setAlwaysOnTop(true) from tests like FocusParentWindowOnChildCloseTest.java,  the stage remains minimised there as well. This seems wrong as calling stage.setAlwaysOnTop(true) should not be required to bring stage window in focus on running the test. This may be an issue on my Window machine or something similar. I hope reviewers can shed some light on this.

tests/system/src/test/java/test/robot/javafx/stage/WrongStageFocusWithApplicationModalityTest.java line 59:

> 57:     @Test(timeout = 25000)
> 58:     public void testWindowFocusByClosingAlerts() throws Exception {
> 59:         Thread.sleep(1000);

On my slower Linux machine if I change this to `sleep(3000)` it passes reliably. Given that you are opening up multiple dialogs, this seems like a reasonable change.

-------------

PR: https://git.openjdk.java.net/jfx/pull/581

From pbansal at openjdk.java.net  Fri Jul 23 15:24:35 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 23 Jul 2021 15:24:35 GMT
Subject: [jfx17] RFR: 8240640: [macos] Wrong focus behaviour with multiple
 Alerts [v2]
In-Reply-To: 
References: 
Message-ID: 

> The bug is a regression as a result of fix done for JDK-8227366 and is reproducible on Linux and Mac. This fix is being reverted in this change and a new bug (JDK-8271054) has been created to redo the JDK-8227366
> 
> An automated testcase is being added to make sure similar regression is not introduced when working on the redo bug. The automated testcase fails without the current change and passes after the change.
> 
> The testcase works fine on Mac and Linux, but I see some issues in windows. The stage is minimised after calling stage.show without calling stage.setAlwaysOnTop(true). I see that there are other tests like DualWindowsTest.java which are failing for same reason. Also, if I remove the stage.setAlwaysOnTop(true) from tests like FocusParentWindowOnChildCloseTest.java,  the stage remains minimised there as well. This seems wrong as calling stage.setAlwaysOnTop(true) should not be required to bring stage window in focus on running the test. This may be an issue on my Window machine or something similar. I hope reviewers can shed some light on this.

Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:

  Fixed review comments 1) Increase delay 2) Fix Formatting 3) Make test stable on Windows according to suggestions

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/581/files
  - new: https://git.openjdk.java.net/jfx/pull/581/files/6d727cd4..623c3930

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=581&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=581&range=00-01

  Stats: 20 lines in 1 file changed: 16 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/581.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/581/head:pull/581

PR: https://git.openjdk.java.net/jfx/pull/581

From kcr at openjdk.java.net  Fri Jul 23 16:40:07 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 23 Jul 2021 16:40:07 GMT
Subject: [jfx17] RFR: 8240640: [macos] Wrong focus behaviour with multiple
 Alerts [v2]
In-Reply-To: 
References: 

Message-ID: <7p7aX1Y6yHCqcpCT0k6UUXGUc01nFksqnzVQbOuz5fQ=.5fc29d81-be77-424b-8608-d0c616cf1d4d@github.com>

On Fri, 23 Jul 2021 15:24:35 GMT, Pankaj Bansal  wrote:

>> The bug is a regression as a result of fix done for JDK-8227366 and is reproducible on Linux and Mac. This fix is being reverted in this change and a new bug (JDK-8271054) has been created to redo the JDK-8227366
>> 
>> An automated testcase is being added to make sure similar regression is not introduced when working on the redo bug. The automated testcase fails without the current change and passes after the change.
>> 
>> The testcase works fine on Mac and Linux, but I see some issues in windows. The stage is minimised after calling stage.show without calling stage.setAlwaysOnTop(true). I see that there are other tests like DualWindowsTest.java which are failing for same reason. Also, if I remove the stage.setAlwaysOnTop(true) from tests like FocusParentWindowOnChildCloseTest.java,  the stage remains minimised there as well. This seems wrong as calling stage.setAlwaysOnTop(true) should not be required to bring stage window in focus on running the test. This may be an issue on my Window machine or something similar. I hope reviewers can shed some light on this.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed review comments 1) Increase delay 2) Fix Formatting 3) Make test stable on Windows according to suggestions

The test changes look good (one minor formatting comment), and it now runs reliably for me on all three platforms.

tests/system/src/test/java/test/robot/javafx/stage/WrongStageFocusWithApplicationModalityTest.java line 95:

> 93:         Util.runAndWait(() -> {
> 94:             robot.mouseMove((int) (alert.getX()+alert.getWidth()/2),
> 95:                     (int) (alert.getY()+alert.getHeight()/2));

Minor: we usually put spaces around binary operators.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/581

From pbansal at openjdk.java.net  Fri Jul 23 17:33:12 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 23 Jul 2021 17:33:12 GMT
Subject: [jfx17] RFR: 8240640: [macos] Wrong focus behaviour with multiple
 Alerts [v2]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 23 Jul 2021 00:16:33 GMT, Kevin Rushforth  wrote:

> The fix (reverting the earlier fix for JDK-8227366) looks fine to me. The test runs fine on Mac (and mostly fine on Linux, but I need to test a couple more things).
> 
> I also see the failure on Windows frequently depending on whether the Window initially gets focus. One thing you might try is to call `stage.toFront()` and `stage.requestFocus()` before showing the Alerts, although I'm not sure that will help. For other tests like this we do set the primary stage to be always on top, so that's probably the easiest. Failing that you could mark the test as unstable on Windows.
> 
> Btw, on my slow Linux VM, it occasionally fails because the window takes a bit too long to come up. I'll do some more testing once you fix the Windows issue.
> 
> I left a couple formatting comments on the test inline.

I tried the stage.toFront or stage.requestFocus, they did not work. So I added the stage.setAlwaysOnTop(true). Along with that, I also added functionality to do mouse click at centre of alert to make sure keyboard focus is present on the alert. I have verified that the updated test fails before the fix and passes with the fix. I have tried multiple iterations of the test on all platforms (Mac 10.15, Ubuntu 20.04 and Windows 10) and test looks stable.

-------------

PR: https://git.openjdk.java.net/jfx/pull/581

From pbansal at openjdk.java.net  Fri Jul 23 17:40:32 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 23 Jul 2021 17:40:32 GMT
Subject: [jfx17] RFR: 8240640: [macos] Wrong focus behaviour with multiple
 Alerts [v3]
In-Reply-To: 
References: 
Message-ID: <-9weiCbmn5Q86vGomMswhPLOtvwWrgQ11ikU-1ZwJvQ=.45971ac9-bca4-4273-8904-edddf44c6169@github.com>

> The bug is a regression as a result of fix done for JDK-8227366 and is reproducible on Linux and Mac. This fix is being reverted in this change and a new bug (JDK-8271054) has been created to redo the JDK-8227366
> 
> An automated testcase is being added to make sure similar regression is not introduced when working on the redo bug. The automated testcase fails without the current change and passes after the change.
> 
> The testcase works fine on Mac and Linux, but I see some issues in windows. The stage is minimised after calling stage.show without calling stage.setAlwaysOnTop(true). I see that there are other tests like DualWindowsTest.java which are failing for same reason. Also, if I remove the stage.setAlwaysOnTop(true) from tests like FocusParentWindowOnChildCloseTest.java,  the stage remains minimised there as well. This seems wrong as calling stage.setAlwaysOnTop(true) should not be required to bring stage window in focus on running the test. This may be an issue on my Window machine or something similar. I hope reviewers can shed some light on this.

Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:

  Fix formatting for binary operators

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/581/files
  - new: https://git.openjdk.java.net/jfx/pull/581/files/623c3930..58a62caf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=581&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=581&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/581.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/581/head:pull/581

PR: https://git.openjdk.java.net/jfx/pull/581

From pbansal at openjdk.java.net  Fri Jul 23 17:40:33 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 23 Jul 2021 17:40:33 GMT
Subject: [jfx17] RFR: 8240640: [macos] Wrong focus behaviour with multiple
 Alerts [v2]
In-Reply-To: <7p7aX1Y6yHCqcpCT0k6UUXGUc01nFksqnzVQbOuz5fQ=.5fc29d81-be77-424b-8608-d0c616cf1d4d@github.com>
References: 

 <7p7aX1Y6yHCqcpCT0k6UUXGUc01nFksqnzVQbOuz5fQ=.5fc29d81-be77-424b-8608-d0c616cf1d4d@github.com>
Message-ID: 

On Fri, 23 Jul 2021 16:35:58 GMT, Kevin Rushforth  wrote:

>> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed review comments 1) Increase delay 2) Fix Formatting 3) Make test stable on Windows according to suggestions
>
> tests/system/src/test/java/test/robot/javafx/stage/WrongStageFocusWithApplicationModalityTest.java line 95:
> 
>> 93:         Util.runAndWait(() -> {
>> 94:             robot.mouseMove((int) (alert.getX()+alert.getWidth()/2),
>> 95:                     (int) (alert.getY()+alert.getHeight()/2));
> 
> Minor: we usually put spaces around binary operators.

Fixed

-------------

PR: https://git.openjdk.java.net/jfx/pull/581

From kcr at openjdk.java.net  Fri Jul 23 18:02:16 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 23 Jul 2021 18:02:16 GMT
Subject: [jfx17] RFR: 8240640: [macos] Wrong focus behaviour with multiple
 Alerts [v3]
In-Reply-To: <-9weiCbmn5Q86vGomMswhPLOtvwWrgQ11ikU-1ZwJvQ=.45971ac9-bca4-4273-8904-edddf44c6169@github.com>
References: 
 <-9weiCbmn5Q86vGomMswhPLOtvwWrgQ11ikU-1ZwJvQ=.45971ac9-bca4-4273-8904-edddf44c6169@github.com>
Message-ID: <5aJVJIKKyZ0HBcnW1JSYPuyHpIObwoBwPvfy036YvN4=.8cc35446-1248-4138-997c-8898746cf604@github.com>

On Fri, 23 Jul 2021 17:40:32 GMT, Pankaj Bansal  wrote:

>> The bug is a regression as a result of fix done for JDK-8227366 and is reproducible on Linux and Mac. This fix is being reverted in this change and a new bug (JDK-8271054) has been created to redo the JDK-8227366
>> 
>> An automated testcase is being added to make sure similar regression is not introduced when working on the redo bug. The automated testcase fails without the current change and passes after the change.
>> 
>> The testcase works fine on Mac and Linux, but I see some issues in windows. The stage is minimised after calling stage.show without calling stage.setAlwaysOnTop(true). I see that there are other tests like DualWindowsTest.java which are failing for same reason. Also, if I remove the stage.setAlwaysOnTop(true) from tests like FocusParentWindowOnChildCloseTest.java,  the stage remains minimised there as well. This seems wrong as calling stage.setAlwaysOnTop(true) should not be required to bring stage window in focus on running the test. This may be an issue on my Window machine or something similar. I hope reviewers can shed some light on this.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting for binary operators

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.java.net/jfx/pull/581

From almatvee at openjdk.java.net  Sat Jul 24 03:05:12 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 24 Jul 2021 03:05:12 GMT
Subject: RFR: 8253351: MediaPlayer does not display an mp4 if there no
 speakers connected to the PC's
Message-ID: 

Fixed by not failing initialization if DSERR_NODRIVER is returned, which will be return if device is not present at all. Fixed format initialization even if DirectSound device was not created in case if audio device will arrive after playback started. Since we already handle correctly device arrival after playback started, audio will resume if device is enabled or USB audio card is plugged back. Due to lack of access to USB audio device, it was tested by disabling sound card via Device Manager, then starting playback (video plays, but not audio) and then enabling device and once enabled audio will start playing.

-------------

Commit messages:
 - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's

Changes: https://git.openjdk.java.net/jfx/pull/586/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=586&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253351
  Stats: 27 lines in 1 file changed: 18 ins; 7 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/586.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/586/head:pull/586

PR: https://git.openjdk.java.net/jfx/pull/586

From kcr at openjdk.java.net  Sat Jul 24 12:49:14 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 24 Jul 2021 12:49:14 GMT
Subject: [jfx17] RFR: 8271230: Remove obsolete test classes and data files
 from 3DViewer sample
Message-ID: <0O__icKHGOp_LvbQaHNoeBRKZhoYeGUj-IQDiu01LVQ=.320176ce-17f2-4e4c-973e-79fbc62b3d28@github.com>

Remove the obsolete `apps/samples/3DViewer/src/test` directory from the 3DViewer sample, including two test classes that don't run and a set of data files that won't load. This is a follow-on cleanup bug to [JDK-8269259](https://bugs.openjdk.java.net/browse/JDK-8269259).

NOTE: this is targeted to `jfx17`.

-------------

Commit messages:
 - 8271230: Remove obsolete test classes and data files from 3DViewer sample

Changes: https://git.openjdk.java.net/jfx/pull/587/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=587&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271230
  Stats: 7167 lines in 16 files changed: 0 ins; 7167 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/587.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/587/head:pull/587

PR: https://git.openjdk.java.net/jfx/pull/587

From mstrauss at openjdk.java.net  Sat Jul 24 12:59:05 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 24 Jul 2021 12:59:05 GMT
Subject: [jfx17] RFR: 8268642: Expand the javafx.beans.property.Property
 documentation [v2]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 24 Jun 2021 01:53:53 GMT, Michael Strau?  wrote:

>> * Expand the `Property.bind` and `Property.bindBidirectional` documentation
>> * Change the name of the formal parameter of `Property.bind` to "source" (currently, it is inconsistently named "observable", "rawObservable" or "newObservable")
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes as per review

I think it might be better to expand the scope of the issue to not only include the documentation changes, but also the implementation changes as discussed in this PR. In this case, I will mark this as a Draft PR and target it to `master` instead.

I think content bindings should also be addressed, because the problem is basically the same as for regular bindings.

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From kcr at openjdk.java.net  Sat Jul 24 13:12:09 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 24 Jul 2021 13:12:09 GMT
Subject: [jfx17] RFR: 8268642: Expand the javafx.beans.property.Property
 documentation [v2]
In-Reply-To: 
References: 

Message-ID: 

On Sat, 24 Jul 2021 12:56:32 GMT, Michael Strau?  wrote:

> I think it might be better to expand the scope of the issue to not only include the documentation changes, but also the implementation changes as discussed in this PR. In this case, I will mark this as a Draft PR and target it to `master` instead.

I think there is some benefit in getting the documentation changes done earlier (in 17), but if you prefer to do the implementation at the same time, then go ahead and retarget this to `master` for 18 and move it to Draft. Or you can create a new Draft PR if you prefer. Since this PR was marked as `rfr` it will continue to send RFR emails to the alias (which is fine, but if you prefer to avoid the noise then creating a new Draft PR will avoid that).

The title and description of the bug will need to change, since it will no longer be just a documentation bug.

> I think content bindings should also be addressed, because the problem is basically the same as for regular bindings.

Yes, that's a good point. In which case that's another argument for addressing both documentation and implementation for both regular and content bindings in 18.

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From kcr at openjdk.java.net  Sat Jul 24 13:18:08 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 24 Jul 2021 13:18:08 GMT
Subject: Integrated: Merge jfx17
Message-ID: 

Merge `jfx17` branch into `master`.

-------------

Commit messages:
 - Merge jfx17
 - 8270839: Remove deprecated implementation methods from Scene
 - 8269374: Menu inoperable after setting stage to second monitor
 - Merge
 - 8270838: Remove deprecated protected access members from DateTimeStringConverter
 - 8270479: WebKit 612.1 build fails with Visual Studio 2017
 - 8188027: List/TableCell: must not fire event in startEdit if already editing
 - 8269639: [macos] Calling stage.setY(0) twice causes wrong popups location
 - 8269638: Property methods, setters, and getters in printing API should be final
 - Merge
 - ... and 5 more: https://git.openjdk.java.net/jfx/compare/d5401095...d433bcde

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jfx/pull/588/files
  Stats: 286793 lines in 5731 files changed: 175700 ins; 68294 del; 42799 mod
  Patch: https://git.openjdk.java.net/jfx/pull/588.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/588/head:pull/588

PR: https://git.openjdk.java.net/jfx/pull/588

From kcr at openjdk.java.net  Sat Jul 24 13:18:08 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 24 Jul 2021 13:18:08 GMT
Subject: Integrated: Merge jfx17
In-Reply-To: 
References: 
Message-ID: <7lwe_TTwtq3wNJ7I8VhLKQwRF01yzlK0G-hJw7-CsFA=.753718de-e184-44c4-b154-92c57277198e@github.com>

On Sat, 24 Jul 2021 13:10:30 GMT, Kevin Rushforth  wrote:

> Merge `jfx17` branch into `master`.

This pull request has now been integrated.

Changeset: 071828a2
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/071828a200faa9fc1bf22ff6098e5892e6426aa7
Stats:     165 lines in 16 files changed: 63 ins; 0 del; 102 mod

Merge

-------------

PR: https://git.openjdk.java.net/jfx/pull/588

From michaelstrau2 at gmail.com  Sat Jul 24 14:02:40 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 24 Jul 2021 16:02:40 +0200
Subject: Content binding API
Message-ID: 

There has been some discussion in this PR
https://github.com/openjdk/jfx/pull/533 on the semantics of
unidirectional and bidirectional bindings.

I think we've come to the understanding that unidirectional and
bidirectional bindings cannot be meaningfully used at the same time,
and such usage should be specified to be illegal and fail fast.

I think the same argument is true for content bindings, which should
mirror the semantics of regular bindings.

1. Let's look at the API of regular bindings:

void bind(ObservableValue)
void unbind()

void bindBidirectional(Property)
void unbindBidirectional(Property)

It makes intuitive sense that unbind() does not take an argument,
because there can only be a single unidirectional binding at a time,
while unbindBidirectional(Property) needs to know which bidirectional
binding should be unbound.

2. Now let's look at the API of content bindings:

void bindContent(ObservableList)
void unbindContent(Object)

void bindContentBidirectional(ObservableList)
void unbindContentBidirectional(Object)

It's a bit unclear why unbindContent(Object) requires an argument, let
alone of type Object. Mirroring regular bindings, we could potentially
introduce a new method unbindContent() without an argument, and
deprecate the other method not for removal.

In the case of unbindContentBidirectional(Object), I'm not sure why
the method doesn't accept an argument of type ObservableList. Can
someone educate me if there is a reason for this seeming inconsistency
with bindContentBidirectional(ObservableList)?`

If there is no reason for the Object argument, "fixing" this would
obviously be more problematic because it would be a
binary-incompatible change.

From perini.davide at dpsoftware.org  Sat Jul 24 16:14:04 2021
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Sat, 24 Jul 2021 18:14:04 +0200
Subject: Java FX dark theme
Message-ID: <54d6974a-40d6-9267-b281-9e05a815b8d5@dpsoftware.org>

Hi all,
I am using some CSS rules to create a "dark theme".

Is it possible to change the color of the window?

As you can see in this picture I have a dark theme but the window border 
is white. can I change that color?

Thank you.
Davide

From perini.davide at dpsoftware.org  Sat Jul 24 16:50:50 2021
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Sat, 24 Jul 2021 18:50:50 +0200
Subject: JavaFX tray icon.
Message-ID: <5518e8fe-ecd5-0278-96ff-9906ad51dec6@dpsoftware.org>

Hi guys,
will we ever see a tray icon support in JavaFX?

I'm trying to style my tray icon PopupMenu with AWT but sincerely I'm 
not able to do it.

Hope that JavaFX will support tray icon soon.

Is there some hope to see tray icon in Java FX?

Thanks
Davide

From tom.schindl at bestsolution.at  Sat Jul 24 17:14:27 2021
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sat, 24 Jul 2021 19:14:27 +0200
Subject: Java FX dark theme
In-Reply-To: <54d6974a-40d6-9267-b281-9e05a815b8d5@dpsoftware.org>
References: <54d6974a-40d6-9267-b281-9e05a815b8d5@dpsoftware.org>
Message-ID: <7DC3458C-5D50-464D-993F-EDC37ED4E3EB@bestsolution.at>

Hi,

As the picture did not made it through i can only guess that we talk about the window trim who is controlled by the OS and so JavaFX has no control how it is drawn.

So the ?solution? is to use a StageStyle.UNDECORATED and draw a trim with min/max/close yourself, implement window resizer,...

 I?ve put the word solution in quotes because once you do that you loose many native festures like snapping to other windows or desktop edges.

I gave a talk last year where i talk a bit about this stuff - https://m.youtube.com/watch?v=NusKg2ZWnrg the stuff you are interested in starts around minute 9:20

Tom

Von meinem iPhone gesendet

> Am 24.07.2021 um 18:14 schrieb Davide Perini :
> 
> ?Hi all,
> I am using some CSS rules to create a "dark theme".
> 
> Is it possible to change the color of the window?
> 
> 
> 
> As you can see in this picture I have a dark theme but the window border is white. can I change that color?
> 
> Thank you.
> Davide

From jvos at openjdk.java.net  Sat Jul 24 18:55:59 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Sat, 24 Jul 2021 18:55:59 GMT
Subject: RFR: 8253351: MediaPlayer does not display an mp4 if there no
 speakers connected to the PC's
In-Reply-To: 
References: 
Message-ID: 

On Sat, 24 Jul 2021 02:59:52 GMT, Alexander Matveev  wrote:

> Fixed by not failing initialization if DSERR_NODRIVER is returned, which will be return if device is not present at all. Fixed format initialization even if DirectSound device was not created in case if audio device will arrive after playback started. Since we already handle correctly device arrival after playback started, audio will resume if device is enabled or USB audio card is plugged back. Due to lack of access to USB audio device, it was tested by disabling sound card via Device Manager, then starting playback (video plays, but not audio) and then enabling device and once enabled audio will start playing.

The linux test fails since https://github.com/openjdk/jfx/commit/b0d158629ed5f9c92cbcc39a7099f2d37e34ecf7 doesn't seem to be applied to this branch.

-------------

PR: https://git.openjdk.java.net/jfx/pull/586

From kcr at openjdk.java.net  Sat Jul 24 20:01:07 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 24 Jul 2021 20:01:07 GMT
Subject: RFR: 8253351: MediaPlayer does not display an mp4 if there no
 speakers connected to the PC's
In-Reply-To: 
References: 
Message-ID: 

On Sat, 24 Jul 2021 02:59:52 GMT, Alexander Matveev  wrote:

> Fixed by not failing initialization if DSERR_NODRIVER is returned, which will be return if device is not present at all. Fixed format initialization even if DirectSound device was not created in case if audio device will arrive after playback started. Since we already handle correctly device arrival after playback started, audio will resume if device is enabled or USB audio card is plugged back. Due to lack of access to USB audio device, it was tested by disabling sound card via Device Manager, then starting playback (video plays, but not audio) and then enabling device and once enabled audio will start playing.

@sashamatveev Can you merge in the latest upstream master into your branch? That should fix the test failures as well as being easier to test.

-------------

PR: https://git.openjdk.java.net/jfx/pull/586

From nlisker at gmail.com  Sun Jul 25 07:03:27 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 25 Jul 2021 10:03:27 +0300
Subject: Possible mistake in DateStringConverterTest
Message-ID: 

Hi,

DateStringConverter (and TimeStringConverter and DateTimeStringConverter)
calls setLenient(false) on the date format it creates, however, the tests
do not and I suspect they pass due to "luck".
Similarly, the tests don't treat a null Locale in the constructor like the
actual class does. None of the tests actually pass a null locale to the
constructor, so this was never noticed.

I assume that the classes behave correctly and the tests need to be fixed,
is this the correct behavior?

- Nir

From fastegal at openjdk.java.net  Sun Jul 25 11:38:19 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Sun, 25 Jul 2021 11:38:19 GMT
Subject: Integrated: 8240506: TextFieldSkin/Behavior: misbehavior on switching
 skin
In-Reply-To: 
References: 
Message-ID: 

On Thu, 17 Jun 2021 12:41:56 GMT, Jeanette Winzenburg  wrote:

> The issue is about memory leaks and side-effects (like NPEs) when switching skins. 
> 
> Details (copied from issue for convenience):
> 
> memory leak in TextInputControlBehavior:
> - listener accidentally added twice (removed once)
> - keyPad mappings not properly installed/disposed
> 
> memory leak TextFieldBehavior:
> - listeners to scene/focusOwner property not removed,
> 
> memory leak in TextInputControlSkin:
> - event handlers related to inputMethods not removed
> 
> issues in TextFieldSkin:
> - memory leak due to behavior leaking
> - memory leaks due to manually added change/invalidation listeners that are not removed
> - memory leaks due to not removing children with strong references to skin
> - side-effects (f.i. NPEs) due to listeners/bindings that are still active after dispose
> 
> Fix was to properly install/remove those listeners/handlers. Added tests that failed/passed before/after the fix, respectively, also added tests passing before that must pass after the fix.

This pull request has now been integrated.

Changeset: 653e24ba
Author:    Jeanette Winzenburg 
URL:       https://git.openjdk.java.net/jfx/commit/653e24baef01c52ec11efab255bf506ee55e4d2a
Stats:     752 lines in 10 files changed: 686 ins; 38 del; 28 mod

8240506: TextFieldSkin/Behavior: misbehavior on switching skin

Reviewed-by: mhanl, arapte

-------------

PR: https://git.openjdk.java.net/jfx/pull/534

From perini.davide at dpsoftware.org  Sun Jul 25 11:39:34 2021
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Sun, 25 Jul 2021 13:39:34 +0200
Subject: Java FX dark theme
In-Reply-To: <7DC3458C-5D50-464D-993F-EDC37ED4E3EB@bestsolution.at>
References: <54d6974a-40d6-9267-b281-9e05a815b8d5@dpsoftware.org>
 <7DC3458C-5D50-464D-993F-EDC37ED4E3EB@bestsolution.at>
Message-ID: 

Subscribed to the channel, very interesting chanenel congrats.
I'll do the way you suggested, thanks!

Do you have some tips on how to style the tray icon?
I have implemented a tray icon following this tutorial
https://docs.oracle.com/javase/tutorial/uiswing/misc/systemtray.html
but styling a popup menu seems impossible...

Tanks you
Davide

Il 24/07/2021 19:14, Tom Schindl ha scritto:
> Hi,
>
> As the picture did not made it through i can only guess that we talk 
> about the window trim who is controlled by the OS and so JavaFX has no 
> control how it is drawn.
>
> So the ?solution? is to use a StageStyle.UNDECORATED and draw a trim 
> with min/max/close yourself, implement window resizer,...
>
> ?I?ve put the word solution in quotes because once you do that you 
> loose many native festures like snapping to other windows or desktop 
> edges.
>
> I gave a talk last year where i talk a bit about this stuff - 
> https://m.youtube.com/watch?v=NusKg2ZWnrg 
> ?the stuff you are 
> interested in starts around minute 9:20
>
> Tom
>
> Von meinem iPhone gesendet
>
>> Am 24.07.2021 um 18:14 schrieb Davide Perini 
>> :
>>
>> ?Hi all,
>> I am using some CSS rules to create a "dark theme".
>>
>> Is it possible to change the color of the window?
>>
>>
>>
>> As you can see in this picture I have a dark theme but the window 
>> border is white. can I change that color?
>>
>> Thank you.
>> Davide

From sebastian.stenzel at gmail.com  Sun Jul 25 13:43:38 2021
From: sebastian.stenzel at gmail.com (Sebastian Stenzel)
Date: Sun, 25 Jul 2021 15:43:38 +0200
Subject: Java FX dark theme
In-Reply-To: 
References: 
Message-ID: <716E194D-B358-456E-B9DE-9B1772A07EAA@gmail.com>

The tray icon is (imho) the last important components that is missing in OpenJFX for desktop applications. At the moment you need to use AWT or native libs.

You can of course create the icon without a menu and implement an undecorated stage with custom styling that you position next to the icon when the user clicks it.

> Am 25.07.2021 um 13:39 schrieb Davide Perini :
> 
> ?Subscribed to the channel, very interesting chanenel congrats.
> I'll do the way you suggested, thanks!
> 
> Do you have some tips on how to style the tray icon?
> I have implemented a tray icon following this tutorial
> https://docs.oracle.com/javase/tutorial/uiswing/misc/systemtray.html
> but styling a popup menu seems impossible...
> 
> Tanks you
> Davide
> 
> 
> Il 24/07/2021 19:14, Tom Schindl ha scritto:
>> Hi,
>> 
>> As the picture did not made it through i can only guess that we talk about the window trim who is controlled by the OS and so JavaFX has no control how it is drawn.
>> 
>> So the ?solution? is to use a StageStyle.UNDECORATED and draw a trim with min/max/close yourself, implement window resizer,...
>> 
>>  I?ve put the word solution in quotes because once you do that you loose many native festures like snapping to other windows or desktop edges.
>> 
>> I gave a talk last year where i talk a bit about this stuff - https://m.youtube.com/watch?v=NusKg2ZWnrg  the stuff you are interested in starts around minute 9:20
>> 
>> Tom
>> 
>> Von meinem iPhone gesendet
>> 
>>>> Am 24.07.2021 um 18:14 schrieb Davide Perini :
>>> 
>>> ?Hi all,
>>> I am using some CSS rules to create a "dark theme".
>>> 
>>> Is it possible to change the color of the window?
>>> 
>>> 
>>> 
>>> As you can see in this picture I have a dark theme but the window border is white. can I change that color?
>>> 
>>> Thank you.
>>> Davide
> 
> 

From arapte at openjdk.java.net  Mon Jul 26 12:12:10 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Mon, 26 Jul 2021 12:12:10 GMT
Subject: [jfx17] RFR: 8271230: Remove obsolete test classes and data files
 from 3DViewer sample
In-Reply-To: <0O__icKHGOp_LvbQaHNoeBRKZhoYeGUj-IQDiu01LVQ=.320176ce-17f2-4e4c-973e-79fbc62b3d28@github.com>
References: <0O__icKHGOp_LvbQaHNoeBRKZhoYeGUj-IQDiu01LVQ=.320176ce-17f2-4e4c-973e-79fbc62b3d28@github.com>
Message-ID: 

On Sat, 24 Jul 2021 12:45:04 GMT, Kevin Rushforth  wrote:

> Remove the obsolete `apps/samples/3DViewer/src/test` directory from the 3DViewer sample, including two test classes that don't run and a set of data files that won't load. This is a follow-on cleanup bug to [JDK-8269259](https://bugs.openjdk.java.net/browse/JDK-8269259).
> 
> NOTE: this is targeted to `jfx17`.

Looks good, verified that 3DViewer test builds and runs properly after removing these files.

-------------

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/587

From pbansal at openjdk.java.net  Mon Jul 26 12:56:05 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Mon, 26 Jul 2021 12:56:05 GMT
Subject: [jfx17] RFR: 8271230: Remove obsolete test classes and data files
 from 3DViewer sample
In-Reply-To: <0O__icKHGOp_LvbQaHNoeBRKZhoYeGUj-IQDiu01LVQ=.320176ce-17f2-4e4c-973e-79fbc62b3d28@github.com>
References: <0O__icKHGOp_LvbQaHNoeBRKZhoYeGUj-IQDiu01LVQ=.320176ce-17f2-4e4c-973e-79fbc62b3d28@github.com>
Message-ID: 

On Sat, 24 Jul 2021 12:45:04 GMT, Kevin Rushforth  wrote:

> Remove the obsolete `apps/samples/3DViewer/src/test` directory from the 3DViewer sample, including two test classes that don't run and a set of data files that won't load. This is a follow-on cleanup bug to [JDK-8269259](https://bugs.openjdk.java.net/browse/JDK-8269259).
> 
> NOTE: this is targeted to `jfx17`.

Marked as reviewed by pbansal (Committer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/587

From kcr at openjdk.java.net  Mon Jul 26 13:25:06 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 26 Jul 2021 13:25:06 GMT
Subject: [jfx17] Integrated: 8271230: Remove obsolete test classes and data
 files from 3DViewer sample
In-Reply-To: <0O__icKHGOp_LvbQaHNoeBRKZhoYeGUj-IQDiu01LVQ=.320176ce-17f2-4e4c-973e-79fbc62b3d28@github.com>
References: <0O__icKHGOp_LvbQaHNoeBRKZhoYeGUj-IQDiu01LVQ=.320176ce-17f2-4e4c-973e-79fbc62b3d28@github.com>
Message-ID: <_JASf0IJeRbuR1rkLkCdrQ0HLhLTnLNDxI9iGNwCccs=.64e20e37-8432-470c-a518-afc186c5f25b@github.com>

On Sat, 24 Jul 2021 12:45:04 GMT, Kevin Rushforth  wrote:

> Remove the obsolete `apps/samples/3DViewer/src/test` directory from the 3DViewer sample, including two test classes that don't run and a set of data files that won't load. This is a follow-on cleanup bug to [JDK-8269259](https://bugs.openjdk.java.net/browse/JDK-8269259).
> 
> NOTE: this is targeted to `jfx17`.

This pull request has now been integrated.

Changeset: 0e5b7887
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/0e5b7887075e8cbe4d2b332c9021ec997f567ed7
Stats:     7167 lines in 16 files changed: 0 ins; 7167 del; 0 mod

8271230: Remove obsolete test classes and data files from 3DViewer sample

Reviewed-by: arapte, pbansal

-------------

PR: https://git.openjdk.java.net/jfx/pull/587

From aghaisas at openjdk.java.net  Mon Jul 26 14:01:29 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 26 Jul 2021 14:01:29 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css package
 are missing documentation
Message-ID: 

This PR corrects/adds missing documentation for classes in javafx.css package.

-------------

Commit messages:
 - 8250590 - CSS Javadoc corrections

Changes: https://git.openjdk.java.net/jfx/pull/589/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250590
  Stats: 494 lines in 29 files changed: 443 ins; 4 del; 47 mod
  Patch: https://git.openjdk.java.net/jfx/pull/589.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/589/head:pull/589

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Mon Jul 26 20:09:38 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 26 Jul 2021 20:09:38 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation
In-Reply-To: 
References: 
Message-ID: 

On Mon, 26 Jul 2021 13:55:45 GMT, Ajit Ghaisas  wrote:

> This PR corrects/adds missing documentation for classes in javafx.css package.

I applied the patch and confirm that there are no more "missing comments" warnings for the `javafx.css` package.

The docs look reasonable in general. I did note a few examples of usage patterns that should be fixed globally. Most of these fell into the following general categories.

1. The body of the javadoc comments for a class, method, etc., should be one or more complete sentences starting with a capital letter and ending with a period.
2. The text following `@return` and `@param` typically starts with a lower-case letter and does not end with a period.
3. When referring to a class name, method name, or formal parameter name, we usually use `{@code ... }` style or else separate words that are all lower-case. For example, either `{@code ParsedValue}` or `parsed value` is fine (but not `ParsedValue`).

In addition to noting one or two examples of each of the above, I left a few random inline comments.

A second pair of eyes would be good for these changes.

modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4724:

> 4722: 
> 4723:     /**
> 4724:      * List of errors that may have occurred during css processing.

Maybe `Returns a list of errors...`? Also, CSS should probably be all-caps for consistency.

modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4725:

> 4723:     /**
> 4724:      * List of errors that may have occurred during css processing.
> 4725:      * @return An {@code ObservableList} of {@code ParseError}

We typically start the text following `@return` or `@param` with a lower-case letter. So: `an ...`

modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4739:

> 4737:     public static class ParseError {
> 4738: 
> 4739:         /**

Can you also add a one-sentence description, something like: `Returns the error message.`?

modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4740:

> 4738: 
> 4739:         /**
> 4740:          * @return The error message from the CSS code.

We typically start with a lower can letter and omit the period at the end of `@return` or `@param`. Also, I'm not sure that "from the CSS code" is needed. So maybe:

    * @return the error message

modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4748:

> 4746:         /**
> 4747:          * Constructs a {@code ParseError} object with given message.
> 4748:          * @param message message

Maybe "the message"?

modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4835:

> 4833:             /**
> 4834:              * Constructs a {@code PropertySetError} object.
> 4835:              * @param styleableProperty css meta data

css -> CSS

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 36:

> 34: 
> 35: /**
> 36:  * This class serves as a container of CSS-property and it's value.

`CSS-property` should not be hyphenated, and it should be _a_ CSS property. Also: `it's` --> `its`.

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 67:

> 65:     /**
> 66:      * Get the parsed value
> 67:      * @return ParsedValue

Either `@return the {@code ParsedValue}` or `@return the parsed value`

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 74:

> 72: 
> 73:     /**
> 74:      * Get the CSS property name

End with a period. And we usually would say "Gets" rather than "Get" here.

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 75:

> 73:     /**
> 74:      * Get the CSS property name
> 75:      * @return css-property

For consistency, I'd say: `@return the CSS property name`

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 108:

> 106:     }
> 107:     /**
> 108:      * One declaration is equal to another regardless of the {@code Rule} to which

This is a good second sentence. The first sentence should probably be copied from the `Object::equals` method:

Indicates whether some other object is "equal to" this one.

Since this is pre-existing, it would be fine to not do this as part of this bug.

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 140:

> 138:     /**
> 139:      * Returns the hash code of this {@code Declaration}
> 140:      */

Since there is nothing extra to say beyond what the superclass says, you can instead replace this with:

/** {@inheritDoc} */

If you do want to add an explicit javadoc comment here, you need an `@return` tag.

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 151:

> 149:     /**
> 150:      * Returns a String version of this {@code Declaration}
> 151:      */

Same comment as for `hashCode`. Probably best to use use:

/** {@inheritDoc} */

modules/javafx.graphics/src/main/java/javafx/css/PseudoClass.java line 85:

> 83:     /**
> 84:      * Gets the {@code PseudoClass} instance for a given pseudo class name.
> 85:      * Note : There is only one PseudoClass instance for a given pseudo class name.

Maybe put this in a new paragraph? Also, can you remove the space before the `:`?

modules/javafx.graphics/src/main/java/javafx/css/SizeUnits.java line 38:

> 36: 
> 37:     /**
> 38:      * Percentage

Maybe make this a complete sentence by saying something like `Represents a size as a percentage.` for this one? For the concrete units, something like `Represents a size in inches.` (for example).

modules/javafx.graphics/src/main/java/javafx/css/SizeUnits.java line 138:

> 136: 
> 137:     /**
> 138:      * EX

What does "EX" specify? Since it isn't an obvious unit type, it would be good to define it.

modules/javafx.graphics/src/main/java/javafx/css/StyleClass.java line 28:

> 26: 
> 27: /**
> 28:  * A class that contains StyleClass information

Best to use `{@code StyleClass}`. Also needs to end with a period.

modules/javafx.graphics/src/main/java/javafx/css/StyleClass.java line 45:

> 43:     /**
> 44:      * Returns the name of StyleClass.
> 45:      * @return the style-class

`StyleClass` --> `the {@code StyleClass)` or `the style-class`.

modules/javafx.graphics/src/main/java/javafx/css/StyleClass.java line 60:

> 58: 
> 59:     /**
> 60:      * Returns the index of this StyleClass in styleClasses list.

Where is the `styleClasses` list defined? This may be beyond the scope of this fix, so a follow-on issue could be filed. At the least, you should add "the" before "styleClasses".

modules/javafx.graphics/src/main/java/javafx/css/converter/EffectConverter.java line 83:

> 81:     /**
> 82:      * Converter to convert DropShadow {@code Effect}
> 83:      * @since 9

Good catch on the `@since 9` tag. I'm a little surprised it doesn't inherit the `@since` from the enclosing class if not present in the nested class, but I can see that it doesn't. So we'll to check the docs of all nested classes to make sure that there aren't any missing.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Mon Jul 26 20:38:40 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 26 Jul 2021 20:38:40 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation
In-Reply-To: 
References: 

Message-ID: 

On Mon, 26 Jul 2021 18:04:22 GMT, Kevin Rushforth  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4724:
> 
>> 4722: 
>> 4723:     /**
>> 4724:      * List of errors that may have occurred during css processing.
> 
> Maybe `Returns a list of errors...`? Also, CSS should probably be all-caps for consistency.

Oops. Ignore the part about "returns a list...". I see that it is a property so what you have is fine (once you make `css` all-caps).

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From almatvee at openjdk.java.net  Mon Jul 26 22:23:20 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 26 Jul 2021 22:23:20 GMT
Subject: RFR: 8253351: MediaPlayer does not display an mp4 if there no
 speakers connected to the PC's [v2]
In-Reply-To: 
References: 
Message-ID: <5xMIQRF9jBWNmL4TS68IMgFPjj4652m5c8_DknwFBgw=.395ba7c6-5bc7-49db-bcd2-5129087b5edb@github.com>

> Fixed by not failing initialization if DSERR_NODRIVER is returned, which will be return if device is not present at all. Fixed format initialization even if DirectSound device was not created in case if audio device will arrive after playback started. Since we already handle correctly device arrival after playback started, audio will resume if device is enabled or USB audio card is plugged back. Due to lack of access to USB audio device, it was tested by disabling sound card via Device Manager, then starting playback (video plays, but not audio) and then enabling device and once enabled audio will start playing.

Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8253351
 - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/586/files
  - new: https://git.openjdk.java.net/jfx/pull/586/files/731b4cd6..2b06faed

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=586&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=586&range=00-01

  Stats: 326714 lines in 6075 files changed: 179112 ins; 103349 del; 44253 mod
  Patch: https://git.openjdk.java.net/jfx/pull/586.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/586/head:pull/586

PR: https://git.openjdk.java.net/jfx/pull/586

From mhanl at openjdk.java.net  Tue Jul 27 05:45:50 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Tue, 27 Jul 2021 05:45:50 GMT
Subject: RFR: 8231644: TreeTableView Regression: Indentation wrong using
 Label as column content type [v3]
In-Reply-To: <44hbYPKwJb2SX19CjpWQT7Lz64EQzz8o3znV6m5VDcQ=.3eb1a2de-d633-4547-aeee-279757cce7f1@github.com>
References: <44hbYPKwJb2SX19CjpWQT7Lz64EQzz8o3znV6m5VDcQ=.3eb1a2de-d633-4547-aeee-279757cce7f1@github.com>
Message-ID: <24XaRxgrUri2EYi_cdS5y1i3BljInwnBafxkvC7EgLg=.bd3b0dc8-c70b-49b9-a2d5-d1dc9aa3eb9f@github.com>

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

-------------

Changes: https://git.openjdk.java.net/jfx/pull/568/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=568&range=02
  Stats: 211 lines in 2 files changed: 197 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jfx/pull/568.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/568/head:pull/568

PR: https://git.openjdk.java.net/jfx/pull/568

From jvos at openjdk.java.net  Tue Jul 27 07:41:38 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Tue, 27 Jul 2021 07:41:38 GMT
Subject: RFR: 8253351: MediaPlayer does not display an mp4 if there no
 speakers connected to the PC's [v2]
In-Reply-To: <5xMIQRF9jBWNmL4TS68IMgFPjj4652m5c8_DknwFBgw=.395ba7c6-5bc7-49db-bcd2-5129087b5edb@github.com>
References: 
 <5xMIQRF9jBWNmL4TS68IMgFPjj4652m5c8_DknwFBgw=.395ba7c6-5bc7-49db-bcd2-5129087b5edb@github.com>
Message-ID: 

On Mon, 26 Jul 2021 22:23:20 GMT, Alexander Matveev  wrote:

>> Fixed by not failing initialization if DSERR_NODRIVER is returned, which will be return if device is not present at all. Fixed format initialization even if DirectSound device was not created in case if audio device will arrive after playback started. Since we already handle correctly device arrival after playback started, audio will resume if device is enabled or USB audio card is plugged back. Due to lack of access to USB audio device, it was tested by disabling sound card via Device Manager, then starting playback (video plays, but not audio) and then enabling device and once enabled audio will start playing.
>
> Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8253351
>  - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's

Looks good. I will do builds and tests, but the idea seems ok. I can imagine it's very hard to have a unit or even system test for this.

-------------

PR: https://git.openjdk.java.net/jfx/pull/586

From aghaisas at openjdk.java.net  Tue Jul 27 09:56:32 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 27 Jul 2021 09:56:32 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation
In-Reply-To: 
References: 

Message-ID: 

On Mon, 26 Jul 2021 18:58:59 GMT, Kevin Rushforth  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> modules/javafx.graphics/src/main/java/javafx/css/StyleClass.java line 60:
> 
>> 58: 
>> 59:     /**
>> 60:      * Returns the index of this StyleClass in styleClasses list.
> 
> Where is the `styleClasses` list defined? This may be beyond the scope of this fix, so a follow-on issue could be filed. At the least, you should add "the" before "styleClasses".

Added "the" as suggested.
I have reused the text existing near private member. Hence, do not know the exact context. I have filed [JDK-8271326](https://bugs.openjdk.java.net/browse/JDK-8271326) for this.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From fastegal at openjdk.java.net  Tue Jul 27 10:01:36 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 27 Jul 2021 10:01:36 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v5]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 22 Jul 2021 19:49:44 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()**
>> - 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 two additional commits since the last revision:
> 
>  - removed unneeded assert and added comment
>  - removed unneeded asserts and added another NPE fix.

there were two NPEs in createLists - one is fixed, the other not yet :) See the failing test in my comment

copying the comment, don't know if you could find it otherwise (any way to un-resolve a review conversation?)

>````
>  // another test, exposing one of the NPEs in createList
>  ComboBox comboBox = new ComboBox<>(items);
>  comboBox.setSelectionModel(null);
>  installDefaultSkin(comboBox);
> 

> the difference is that setup already installs a skin - so at the time of init the selectionModel still is available ;)

still failing 

> 
> The other access is in the listener to listView's selectedIndex .. it might be a bit tricky to expose in a test, I would go for a combo in a stage/loader, access the list and change its selectedIndex (maybe needs the popup open and/or firing a key onto it)

good fix and test :)

-------------

Changes requested by fastegal (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/557

From fastegal at openjdk.java.net  Tue Jul 27 10:01:36 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 27 Jul 2021 10:01:36 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v3]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 9 Jul 2021 09:46:04 GMT, Jeanette Winzenburg  wrote:

>````
>  // another test, exposing one of the NPEs in createList
>  ComboBox comboBox = new ComboBox<>(items);
>  comboBox.setSelectionModel(null);
>  installDefaultSkin(comboBox);
> 

> the difference is that setup already installs a skin - so at the time of init the selectionModel still is available ;)

still failing 

> 
> The other access is in the listener to listView's selectedIndex .. it might be a bit tricky to expose in a test, I would go for a combo in a stage/loader, access the list and change its selectedIndex (maybe needs the popup open and/or firing a key onto it)

good fix and test :)

-------------

PR: https://git.openjdk.java.net/jfx/pull/557

From aghaisas at openjdk.java.net  Tue Jul 27 10:02:35 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 27 Jul 2021 10:02:35 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation
In-Reply-To: 
References: 

Message-ID: 

On Mon, 26 Jul 2021 19:05:51 GMT, Kevin Rushforth  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> modules/javafx.graphics/src/main/java/javafx/css/converter/EffectConverter.java line 83:
> 
>> 81:     /**
>> 82:      * Converter to convert DropShadow {@code Effect}
>> 83:      * @since 9
> 
> Good catch on the `@since 9` tag. I'm a little surprised it doesn't inherit the `@since` from the enclosing class if not present in the nested class, but I can see that it doesn't. So we'll to check the docs of all nested classes to make sure that there aren't any missing.

This can only be checked manually.
I have checked and added the @since tag to these *Converter nested classes.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Tue Jul 27 10:14:00 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 27 Jul 2021 10:14:00 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v2]
In-Reply-To: 
References: 
Message-ID: 

> This PR corrects/adds missing documentation for classes in javafx.css package.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  8250590 - address review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/589/files
  - new: https://git.openjdk.java.net/jfx/pull/589/files/2feb4d5d..426863c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=00-01

  Stats: 177 lines in 26 files changed: 30 ins; 0 del; 147 mod
  Patch: https://git.openjdk.java.net/jfx/pull/589.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/589/head:pull/589

PR: https://git.openjdk.java.net/jfx/pull/589

From fastegal at swingempire.de  Tue Jul 27 11:15:20 2021
From: fastegal at swingempire.de (Jeanette Winzenburg)
Date: Tue, 27 Jul 2021 13:15:20 +0200
Subject: Eclipse: any way to checkout a PR for review?
Message-ID: <20210727131520.Horde.RiLYb6lVYFStPI5RWZD-dQ9@webmail.df.eu>

when reviewing a PR with only a few files changed, I simply create a  
local branch and c&p the changes (*cough, pretty sure there's a better  
way, but then that's the most simple ;).

With changes to many files (like f.i.  
https://github.com/openjdk/jfx/pull/569) that still would be doable,  
but rather cumbersome - so looking for something like "gh pr checkout  
569" (not that I ever tried that, just copied from the doc :) inside  
Eclipse.

An alternative might be to fork-the-fork .. ?

-- Jeanette

From kevin.rushforth at oracle.com  Tue Jul 27 11:23:34 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 27 Jul 2021 04:23:34 -0700
Subject: Eclipse: any way to checkout a PR for review?
In-Reply-To: <20210727131520.Horde.RiLYb6lVYFStPI5RWZD-dQ9@webmail.df.eu>
References: <20210727131520.Horde.RiLYb6lVYFStPI5RWZD-dQ9@webmail.df.eu>
Message-ID: <15ae3afc-ae59-37dc-d593-24b9afb186c4@oracle.com>

I do something like this:

git fetch upstream pull/569/head:pr_569

Then you can checkout the "pr_569" branch. I typically will then merge 
in the current upstream/master to test. If you don't have an "upstream" 
remote you can instead:

git fetch https://github.com/openjdk/jfx pull/569/head:pr_569

-- Kevin

On 7/27/2021 4:15 AM, Jeanette Winzenburg wrote:
>
> when reviewing a PR with only a few files changed, I simply create a 
> local branch and c&p the changes (*cough, pretty sure there's a better 
> way, but then that's the most simple ;).
>
> With changes to many files (like f.i. 
> https://github.com/openjdk/jfx/pull/569) that still would be doable, 
> but rather cumbersome - so looking for something like "gh pr checkout 
> 569" (not that I ever tried that, just copied from the doc :) inside 
> Eclipse.
>
> An alternative might be to fork-the-fork .. ?
>
> -- Jeanette
>

From fastegal at swingempire.de  Tue Jul 27 11:35:14 2021
From: fastegal at swingempire.de (Jeanette Winzenburg)
Date: Tue, 27 Jul 2021 13:35:14 +0200
Subject: Eclipse: any way to checkout a PR for review?
In-Reply-To: <15ae3afc-ae59-37dc-d593-24b9afb186c4@oracle.com>
References: <20210727131520.Horde.RiLYb6lVYFStPI5RWZD-dQ9@webmail.df.eu>
 <15ae3afc-ae59-37dc-d593-24b9afb186c4@oracle.com>
Message-ID: <20210727133514.Horde.UQx2sNBkK0sc_WmxLg37yQ4@webmail.df.eu>

ahh .. yeah, that looks doable - had hoped to get away without  
installing git and frickle with commandlines ;)

thanks

Zitat von Kevin Rushforth :

> I do something like this:
>
> git fetch upstream pull/569/head:pr_569
>
> Then you can checkout the "pr_569" branch. I typically will then  
> merge in the current upstream/master to test. If you don't have an  
> "upstream" remote you can instead:
>
> git fetch https://github.com/openjdk/jfx pull/569/head:pr_569
>
> -- Kevin
>
> On 7/27/2021 4:15 AM, Jeanette Winzenburg wrote:
>>
>> when reviewing a PR with only a few files changed, I simply create  
>> a local branch and c&p the changes (*cough, pretty sure there's a  
>> better way, but then that's the most simple ;).
>>
>> With changes to many files (like f.i.  
>> https://github.com/openjdk/jfx/pull/569) that still would be  
>> doable, but rather cumbersome - so looking for something like "gh  
>> pr checkout 569" (not that I ever tried that, just copied from the  
>> doc :) inside Eclipse.
>>
>> An alternative might be to fork-the-fork .. ?
>>
>> -- Jeanette
>>

From kcr at openjdk.java.net  Tue Jul 27 12:05:36 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 27 Jul 2021 12:05:36 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Jul 2021 10:00:10 GMT, Ajit Ghaisas  wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/converter/EffectConverter.java line 83:
>> 
>>> 81:     /**
>>> 82:      * Converter to convert DropShadow {@code Effect}
>>> 83:      * @since 9
>> 
>> Good catch on the `@since 9` tag. I'm a little surprised it doesn't inherit the `@since` from the enclosing class if not present in the nested class, but I can see that it doesn't. So we'll to check the docs of all nested classes to make sure that there aren't any missing.
>
> This can only be checked manually.
> I have checked and added the @since tag to these *Converter nested classes.

I ran a script to check for missing `@since` tags. The following class are still missing them:

DeriveColorConverter
DeriveSizeConverter
StopConverter
StringConverter.SequenceConverter

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Tue Jul 27 12:28:33 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 27 Jul 2021 12:28:33 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Jul 2021 12:03:02 GMT, Kevin Rushforth  wrote:

>> This can only be checked manually.
>> I have checked and added the `@since` tag to these *Converter nested classes.
>
> I ran a script to check for missing `@since` tags. The following class are still missing them:
> 
> 
> DeriveColorConverter
> DeriveSizeConverter
> StopConverter
> StringConverter.SequenceConverter

Ah.. Thanks for running the script. It is tough to find it manually. I will fix these soon.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From mhanl at openjdk.java.net  Tue Jul 27 12:41:03 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Tue, 27 Jul 2021 12:41:03 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v5]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Jul 2021 09:55:47 GMT, Jeanette Winzenburg  wrote:

>  ComboBox comboBox = new ComboBox<>(items);
>  comboBox.setSelectionModel(null);
>  installDefaultSkin(comboBox);

Ahh yes, I see, nice catch. I will fix it and update this PR. 

But I'm wondering, this might require more as we don't set this dirty flag anymore as soon as we install a selection model again.
But thinking about this more, this would be a general problem as soon as we switch the combox selection model.
EDIT: Or maybe there is no issue at all and this listener can be removed.

-------------

PR: https://git.openjdk.java.net/jfx/pull/557

From mhanl at openjdk.java.net  Tue Jul 27 12:41:00 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Tue, 27 Jul 2021 12:41:00 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v6]
In-Reply-To: 
References: 
Message-ID: 

> 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()**
> - 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

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/557/files
  - new: https://git.openjdk.java.net/jfx/pull/557/files/039b826b..40a30e08

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=557&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=557&range=04-05

  Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/557.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/557/head:pull/557

PR: https://git.openjdk.java.net/jfx/pull/557

From aghaisas at openjdk.java.net  Tue Jul 27 12:44:58 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 27 Jul 2021 12:44:58 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 
Message-ID: 

> This PR corrects/adds missing documentation for classes in javafx.css package.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  8250590 - add missing @since tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/589/files
  - new: https://git.openjdk.java.net/jfx/pull/589/files/426863c8..76439ae4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=01-02

  Stats: 8 lines in 4 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/589.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/589/head:pull/589

PR: https://git.openjdk.java.net/jfx/pull/589

From arapte at openjdk.java.net  Tue Jul 27 12:47:34 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 27 Jul 2021 12:47:34 GMT
Subject: [jfx17] RFR: 8240640: [macos] Wrong focus behaviour with multiple
 Alerts [v3]
In-Reply-To: <-9weiCbmn5Q86vGomMswhPLOtvwWrgQ11ikU-1ZwJvQ=.45971ac9-bca4-4273-8904-edddf44c6169@github.com>
References: 
 <-9weiCbmn5Q86vGomMswhPLOtvwWrgQ11ikU-1ZwJvQ=.45971ac9-bca4-4273-8904-edddf44c6169@github.com>
Message-ID: 

On Fri, 23 Jul 2021 17:40:32 GMT, Pankaj Bansal  wrote:

>> The bug is a regression as a result of fix done for JDK-8227366 and is reproducible on Linux and Mac. This fix is being reverted in this change and a new bug (JDK-8271054) has been created to redo the JDK-8227366
>> 
>> An automated testcase is being added to make sure similar regression is not introduced when working on the redo bug. The automated testcase fails without the current change and passes after the change.
>> 
>> The testcase works fine on Mac and Linux, but I see some issues in windows. The stage is minimised after calling stage.show without calling stage.setAlwaysOnTop(true). I see that there are other tests like DualWindowsTest.java which are failing for same reason. Also, if I remove the stage.setAlwaysOnTop(true) from tests like FocusParentWindowOnChildCloseTest.java,  the stage remains minimised there as well. This seems wrong as calling stage.setAlwaysOnTop(true) should not be required to bring stage window in focus on running the test. This may be an issue on my Window machine or something similar. I hope reviewers can shed some light on this.
>
> Pankaj Bansal has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix formatting for binary operators

looks good to me.

Marked as reviewed by arapte (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/581

From pbansal at openjdk.java.net  Tue Jul 27 13:25:31 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 27 Jul 2021 13:25:31 GMT
Subject: [jfx17] Integrated: 8240640: [macos] Wrong focus behaviour with
 multiple Alerts
In-Reply-To: 
References: 
Message-ID: <0F9oQQ6BXfsPruVX6Uh4MUBKdvPmF-C34WxVx2nhAHI=.baf9df98-65c7-4c61-8ee1-8c8b0fa50b71@github.com>

On Mon, 19 Jul 2021 19:52:05 GMT, Pankaj Bansal  wrote:

> The bug is a regression as a result of fix done for JDK-8227366 and is reproducible on Linux and Mac. This fix is being reverted in this change and a new bug (JDK-8271054) has been created to redo the JDK-8227366
> 
> An automated testcase is being added to make sure similar regression is not introduced when working on the redo bug. The automated testcase fails without the current change and passes after the change.
> 
> The testcase works fine on Mac and Linux, but I see some issues in windows. The stage is minimised after calling stage.show without calling stage.setAlwaysOnTop(true). I see that there are other tests like DualWindowsTest.java which are failing for same reason. Also, if I remove the stage.setAlwaysOnTop(true) from tests like FocusParentWindowOnChildCloseTest.java,  the stage remains minimised there as well. This seems wrong as calling stage.setAlwaysOnTop(true) should not be required to bring stage window in focus on running the test. This may be an issue on my Window machine or something similar. I hope reviewers can shed some light on this.

This pull request has now been integrated.

Changeset: 2cd5d1fd
Author:    Pankaj Bansal 
URL:       https://git.openjdk.java.net/jfx/commit/2cd5d1fd0fd3e7d974b46bd43a6f98dbca6f28c0
Stats:     135 lines in 2 files changed: 134 ins; 0 del; 1 mod

8240640: [macos] Wrong focus behaviour with multiple Alerts

Reviewed-by: kcr, arapte

-------------

PR: https://git.openjdk.java.net/jfx/pull/581

From fastegal at openjdk.java.net  Tue Jul 27 13:39:33 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 27 Jul 2021 13:39:33 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v6]
In-Reply-To: 
References: 

Message-ID: <86PyGHHG-LpFJgGu6tT_klQrjy2d_FwfPL2DwEkMozA=.d96d63f3-2cba-4118-acc3-d2bc9a68c9af@github.com>

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()**
>> - 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

looks good :)

-------------

Marked as reviewed by fastegal (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/557

From fastegal at openjdk.java.net  Tue Jul 27 13:43:29 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 27 Jul 2021 13:43:29 GMT
Subject: RFR: 8089398: [ChoiceBox,
 ComboBox] throws NPE on setting value on null selectionModel [v5]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Jul 2021 12:36:52 GMT, Marius Hanl  wrote:

> But I'm wondering, this might require more as we don't set this dirty flag anymore as soon as we install a selection model again.
> But thinking about this even more, this would be a general problem as soon as we switch the combobox selection model.
> EDIT: Or maybe there is no issue at all and this listener can be removed.

the interaction of selection listener wiring in combo skin is complex and buggy (there are many issues already reported, work started, work aborted ..) - off scope for this PR, IMO

-------------

PR: https://git.openjdk.java.net/jfx/pull/557

From nlisker at gmail.com  Tue Jul 27 13:52:21 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 27 Jul 2021 16:52:21 +0300
Subject: Eclipse: any way to checkout a PR for review?
In-Reply-To: <20210727131520.Horde.RiLYb6lVYFStPI5RWZD-dQ9@webmail.df.eu>
References: <20210727131520.Horde.RiLYb6lVYFStPI5RWZD-dQ9@webmail.df.eu>
Message-ID: 

I'm not really sure what you mean. If you pull from the remote that the PR
is on and checkout the remote branch, is it not good enough for a review?

On Tue, Jul 27, 2021 at 2:16 PM Jeanette Winzenburg 
wrote:

>
> when reviewing a PR with only a few files changed, I simply create a
> local branch and c&p the changes (*cough, pretty sure there's a better
> way, but then that's the most simple ;).
>
> With changes to many files (like f.i.
> https://github.com/openjdk/jfx/pull/569) that still would be doable,
> but rather cumbersome - so looking for something like "gh pr checkout
> 569" (not that I ever tried that, just copied from the doc :) inside
> Eclipse.
>
> An alternative might be to fork-the-fork .. ?
>
> -- Jeanette
>
>

From mstrauss at openjdk.java.net  Tue Jul 27 19:47:46 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 27 Jul 2021 19:47:46 GMT
Subject: [jfx17] Withdrawn: 8268642: Expand the javafx.beans.property.Property
 documentation
In-Reply-To: 
References: 
Message-ID: 

On Mon, 14 Jun 2021 17:06:34 GMT, Michael Strau?  wrote:

> * Expand the `Property.bind` and `Property.bindBidirectional` documentation
> * Change the name of the formal parameter of `Property.bind` to "source" (currently, it is inconsistently named "observable", "rawObservable" or "newObservable")

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jfx/pull/533

From michaelstrau2 at gmail.com  Tue Jul 27 23:23:12 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 28 Jul 2021 01:23:12 +0200
Subject: Improve property system to facilitate correct usage
Message-ID: 

I propose a set of changes to the JavaFX property system that I've
outlined in this PR: https://github.com/openjdk/jfx/pull/590

The changes fall into two categories: enforcement of correct usage
(there are several cases listed in the PR), and deprecating untyped
APIs (for removal in a future version) so as to make the intent of the
API more clear to developers.

Even though there are breaking changes, the impact on application code
should be minimal. I'd welcome any comments on this proposal.

From kevin.rushforth at oracle.com  Tue Jul 27 23:33:33 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 27 Jul 2021 16:33:33 -0700
Subject: Content binding API
In-Reply-To: 
References: 
Message-ID: 

Looking at content bindings at the same time as regular bindings makes a 
lot of sense, as long as the proposed changes don't result in the loss 
of any well-defined, workable functionality (e.g., tightening the 
restriction that a property P1 that is unidirectionally bound to another 
property P2 cannot also be bound bidirectionally to a property P3 is not 
a loss of any "workable" functionality).

I'll need a little more time to look at the API implications of your 
proposed changes (and questions) for content bindings. One thing to keep 
in mind is that content bindings are often created via the "Bindings" 
utility class, for which the object to be bound is a plain List or Map 
(not an Observable). That likely has something to do with the reason for 
the unbind methods in the properties taking an Object rather than an 
observable.

-- Kevin

On 7/24/2021 7:02 AM, Michael Strau? wrote:
> There has been some discussion in this PR
> https://github.com/openjdk/jfx/pull/533 on the semantics of
> unidirectional and bidirectional bindings.
>
> I think we've come to the understanding that unidirectional and
> bidirectional bindings cannot be meaningfully used at the same time,
> and such usage should be specified to be illegal and fail fast.
>
> I think the same argument is true for content bindings, which should
> mirror the semantics of regular bindings.
>
> 1. Let's look at the API of regular bindings:
>
> void bind(ObservableValue)
> void unbind()
>
> void bindBidirectional(Property)
> void unbindBidirectional(Property)
>
> It makes intuitive sense that unbind() does not take an argument,
> because there can only be a single unidirectional binding at a time,
> while unbindBidirectional(Property) needs to know which bidirectional
> binding should be unbound.
>
> 2. Now let's look at the API of content bindings:
>
> void bindContent(ObservableList)
> void unbindContent(Object)
>
> void bindContentBidirectional(ObservableList)
> void unbindContentBidirectional(Object)
>
> It's a bit unclear why unbindContent(Object) requires an argument, let
> alone of type Object. Mirroring regular bindings, we could potentially
> introduce a new method unbindContent() without an argument, and
> deprecate the other method not for removal.
>
> In the case of unbindContentBidirectional(Object), I'm not sure why
> the method doesn't accept an argument of type ObservableList. Can
> someone educate me if there is a reason for this seeming inconsistency
> with bindContentBidirectional(ObservableList)?`
>
> If there is no reason for the Object argument, "fixing" this would
> obviously be more problematic because it would be a
> binary-incompatible change.

From kevin.rushforth at oracle.com  Tue Jul 27 23:39:05 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 27 Jul 2021 16:39:05 -0700
Subject: Improve property system to facilitate correct usage
In-Reply-To: 
References: 
Message-ID: <550a6b83-8cdc-e1f0-1348-3d76239cb8d5@oracle.com>

This will take a while to work through, and we will need to get general 
consensus on the API changes.

I doubt I can support incompatible breaking changes in this area, given 
how fundamental property and bindings are to JavaFX. I'll take a look, 
but it is likely that the incompatible API changes part of your proposed 
change will not be accepted.

The changes enforcing correct usage should be a lot less controversial 
and easier to get through.

-- Kevin

On 7/27/2021 4:23 PM, Michael Strau? wrote:
> I propose a set of changes to the JavaFX property system that I've
> outlined in this PR: https://github.com/openjdk/jfx/pull/590
>
> The changes fall into two categories: enforcement of correct usage
> (there are several cases listed in the PR), and deprecating untyped
> APIs (for removal in a future version) so as to make the intent of the
> API more clear to developers.
>
> Even though there are breaking changes, the impact on application code
> should be minimal. I'd welcome any comments on this proposal.

From michaelstrau2 at gmail.com  Wed Jul 28 01:09:20 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 28 Jul 2021 03:09:20 +0200
Subject: Improve property system to facilitate correct usage
In-Reply-To: <550a6b83-8cdc-e1f0-1348-3d76239cb8d5@oracle.com>
References: 
 <550a6b83-8cdc-e1f0-1348-3d76239cb8d5@oracle.com>
Message-ID: 

I should point out that the rest of the JavaFX framework did not
require a single code change as a result of the API changes. So while
some changes are binary incompatible, they are syntactically
transparent.

Am Mi., 28. Juli 2021 um 01:39 Uhr schrieb Kevin Rushforth
:
>
> This will take a while to work through, and we will need to get general
> consensus on the API changes.
>
> I doubt I can support incompatible breaking changes in this area, given
> how fundamental property and bindings are to JavaFX. I'll take a look,
> but it is likely that the incompatible API changes part of your proposed
> change will not be accepted.
>
> The changes enforcing correct usage should be a lot less controversial
> and easier to get through.
>
> -- Kevin
>
>
> On 7/27/2021 4:23 PM, Michael Strau? wrote:
> > I propose a set of changes to the JavaFX property system that I've
> > outlined in this PR: https://github.com/openjdk/jfx/pull/590
> >
> > The changes fall into two categories: enforcement of correct usage
> > (there are several cases listed in the PR), and deprecating untyped
> > APIs (for removal in a future version) so as to make the intent of the
> > API more clear to developers.
> >
> > Even though there are breaking changes, the impact on application code
> > should be minimal. I'd welcome any comments on this proposal.
>

From kevin.rushforth at oracle.com  Wed Jul 28 01:13:30 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 27 Jul 2021 18:13:30 -0700
Subject: [External] : Re: Improve property system to facilitate correct
 usage
In-Reply-To: 
References: 
 <550a6b83-8cdc-e1f0-1348-3d76239cb8d5@oracle.com>

Message-ID: <48d9ad67-9b9e-2a80-67ca-299e87f83187@oracle.com>

> some changes are binary incompatible, they are syntactically
> transparent.

Yes, that's the big problem. Binary compatibility is very important. The 
value proposition of making the types a bit more clear doesn't justify 
breaking binary compatibility.

-- Kevin

On 7/27/2021 6:09 PM, Michael Strau? wrote:
> I should point out that the rest of the JavaFX framework did not
> require a single code change as a result of the API changes. So while
> some changes are binary incompatible, they are syntactically
> transparent.
>
> Am Mi., 28. Juli 2021 um 01:39 Uhr schrieb Kevin Rushforth
> :
>> This will take a while to work through, and we will need to get general
>> consensus on the API changes.
>>
>> I doubt I can support incompatible breaking changes in this area, given
>> how fundamental property and bindings are to JavaFX. I'll take a look,
>> but it is likely that the incompatible API changes part of your proposed
>> change will not be accepted.
>>
>> The changes enforcing correct usage should be a lot less controversial
>> and easier to get through.
>>
>> -- Kevin
>>
>>
>> On 7/27/2021 4:23 PM, Michael Strau? wrote:
>>> I propose a set of changes to the JavaFX property system that I've
>>> outlined in this PR: https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/590__;!!ACWV5N9M2RV99hQ!egor-rENORC_wn09Va7FeNBmsgCGsCm3yzccC3yvO_x-wuuyMXrzpE_OplPNe2pJWeue$
>>>
>>> The changes fall into two categories: enforcement of correct usage
>>> (there are several cases listed in the PR), and deprecating untyped
>>> APIs (for removal in a future version) so as to make the intent of the
>>> API more clear to developers.
>>>
>>> Even though there are breaking changes, the impact on application code
>>> should be minimal. I'd welcome any comments on this proposal.

From pbansal at openjdk.java.net  Wed Jul 28 07:50:36 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 28 Jul 2021 07:50:36 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 26 Jul 2021 18:15:04 GMT, Kevin Rushforth  wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8250590 - add missing @since tag
>
> modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 4748:
> 
>> 4746:         /**
>> 4747:          * Constructs a {@code ParseError} object with given message.
>> 4748:          * @param message message
> 
> Maybe "the message"?

Minor: I think Kevin meant @param message the message

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From nlisker at openjdk.java.net  Wed Jul 28 09:40:33 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 28 Jul 2021 09:40:33 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Jul 2021 12:44:58 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - add missing @since tag

I have spotted some missing docs:

* `CompoundSelector` missing docs for methods overriden from `Object`.
* `CssMetaData` is missing docs for methods `hashCode()`, `getConverter()` and `getProperty()`.
* `CssParser.ParseError` for `toString()`.

I stopped checking at this point. It seems that the the script warning for missing docs isn't looking at overriden methods. `getProperty()` and `getConverter()` were not caught since they have an `@return` doc, but no method summary.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From pbansal at openjdk.java.net  Wed Jul 28 09:40:34 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 28 Jul 2021 09:40:34 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Jul 2021 12:44:58 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - add missing @since tag

modules/javafx.graphics/src/main/java/javafx/css/Rule.java line 141:

> 139: 
> 140:     /**
> 141:      * The {@code Stylesheet} this {@code Selector} belongs to.

Should not this be "The {@code Stylesheet} this {@code Rule} belongs to" ?

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From fastegal at swingempire.de  Wed Jul 28 09:45:21 2021
From: fastegal at swingempire.de (Jeanette Winzenburg)
Date: Wed, 28 Jul 2021 11:45:21 +0200
Subject: Eclipse: any way to checkout a PR for review?
In-Reply-To: 
References: <20210727131520.Horde.RiLYb6lVYFStPI5RWZD-dQ9@webmail.df.eu>

Message-ID: <20210728114521.Horde.dPyL__f6r7isWMlzkJf-kw2@webmail.df.eu>

Zitat von Nir Lisker :

> I'm not really sure what you mean. If you pull from the remote that the PR
> is on and checkout the remote branch, is it not good enough for a review?
>

yeah, that's what I meant - without having been too clear - with  
fork-the-fork :) What I had hoped for was some hidden eclipse magic to  
directly access a PR as branch (from jfx) - something like the Pull  
requests tab in GitHub Desktop. Which under the hood adds a new remote  
to the fork that created the pr. And that's what I ended up with: add  
that remote manually and checkout the branch.

Thanks for your input!

-- Jeanette

> On Tue, Jul 27, 2021 at 2:16 PM Jeanette Winzenburg 
> wrote:
>
>>
>> when reviewing a PR with only a few files changed, I simply create a
>> local branch and c&p the changes (*cough, pretty sure there's a better
>> way, but then that's the most simple ;).
>>
>> With changes to many files (like f.i.
>> https://github.com/openjdk/jfx/pull/569) that still would be doable,
>> but rather cumbersome - so looking for something like "gh pr checkout
>> 569" (not that I ever tried that, just copied from the doc :) inside
>> Eclipse.
>>
>> An alternative might be to fork-the-fork .. ?
>>
>> -- Jeanette
>>
>>

From nlisker at gmail.com  Wed Jul 28 10:03:58 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 28 Jul 2021 13:03:58 +0300
Subject: Eclipse: any way to checkout a PR for review?
In-Reply-To: <20210728114521.Horde.dPyL__f6r7isWMlzkJf-kw2@webmail.df.eu>
References: <20210727131520.Horde.RiLYb6lVYFStPI5RWZD-dQ9@webmail.df.eu>

 <20210728114521.Horde.dPyL__f6r7isWMlzkJf-kw2@webmail.df.eu>
Message-ID: 

A Pull Request is a GitHub feature, it doesn't exist in Git generally, so
EGit (I assume that's what you also use) is oblivious to PRs. Maybe there
is a special plugin for GitHubs or PRs.

Also, adding a remote is a one-time operation. Most contributors are
recurring, so for me reviewing amounts to a right click > pull on the
remote and a double click on the branch to check it out. I don't see any
inconvenience.

On Wed, Jul 28, 2021 at 12:45 PM Jeanette Winzenburg <
fastegal at swingempire.de> wrote:

>
> Zitat von Nir Lisker :
>
> > I'm not really sure what you mean. If you pull from the remote that the
> PR
> > is on and checkout the remote branch, is it not good enough for a review?
> >
>
> yeah, that's what I meant - without having been too clear - with
> fork-the-fork :) What I had hoped for was some hidden eclipse magic to
> directly access a PR as branch (from jfx) - something like the Pull
> requests tab in GitHub Desktop. Which under the hood adds a new remote
> to the fork that created the pr. And that's what I ended up with: add
> that remote manually and checkout the branch.
>
> Thanks for your input!
>
> -- Jeanette
>
>
>
> > On Tue, Jul 27, 2021 at 2:16 PM Jeanette Winzenburg <
> fastegal at swingempire.de>
> > wrote:
> >
> >>
> >> when reviewing a PR with only a few files changed, I simply create a
> >> local branch and c&p the changes (*cough, pretty sure there's a better
> >> way, but then that's the most simple ;).
> >>
> >> With changes to many files (like f.i.
> >> https://github.com/openjdk/jfx/pull/569) that still would be doable,
> >> but rather cumbersome - so looking for something like "gh pr checkout
> >> 569" (not that I ever tried that, just copied from the doc :) inside
> >> Eclipse.
> >>
> >> An alternative might be to fork-the-fork .. ?
> >>
> >> -- Jeanette
> >>
> >>
>
>
>
>

From alessandro.parisi406 at gmail.com  Wed Jul 28 10:19:34 2021
From: alessandro.parisi406 at gmail.com (Alessandro Parisi)
Date: Wed, 28 Jul 2021 12:19:34 +0200
Subject: [External] : Re: Improve property system to facilitate correct usage
Message-ID: 

>
> Yes, that's the big problem. Binary compatibility is very important. The
> value proposition of making the types a bit more clear doesn't justify
> breaking binary compatibility.

Binary compatibility certainly is a valid point, but I disagree. I think
consistency is more important. Users and devs will have to cope with the
changes. It is important, but we can't always think about
binary compatibility, "breaking" changes are sometimes needed

From pbansal at openjdk.java.net  Wed Jul 28 13:11:34 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 28 Jul 2021 13:11:34 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Jul 2021 12:44:58 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - add missing @since tag

I understand we discussed this in the meeting, but I am surprised that this does not need a CSR. It looks like too much bigger documentation change for not needing a CSR. Besides this, I have given some minor comments, otherwise it looks fine to me.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From fastegal at openjdk.java.net  Wed Jul 28 15:12:32 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 28 Jul 2021 15:12:32 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:

> 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()**.

thinking about it again: for a fully configured cell, there is no difference in behaviour before/after the fix - so the fix should be fine :) I'll start a review next week or so (after tax deadline ;) - for now will just add a suggestion for the tests.

-------------

PR: https://git.openjdk.java.net/jfx/pull/569

From kevin.rushforth at oracle.com  Wed Jul 28 15:24:23 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 28 Jul 2021 08:24:23 -0700
Subject: REMINDER: JavaFX 17 RDP2 starts tomorrow [was: Proposed schedule for
 JavaFX 17]
In-Reply-To: <88e02367-1438-57e5-b243-578feb74ad8e@oracle.com>
References: 
 <88e02367-1438-57e5-b243-578feb74ad8e@oracle.com>
Message-ID: <2250acc4-84f3-855b-0615-75ee38c6a013@oracle.com>

As a reminder, RDP2 for JavaFX 17 starts tomorrow, July 29, 2021 at 
16:00 UTC (09:00 Pacific time).

P1-P2 bugs can still be fixed during RDP2 with explicit approval, 
although the bar will be appropriately high. Test or doc bugs of any 
priority can still be fixed without explicit approval (beyond the code 
review). I'll send details tomorrow once RDP2 starts.

-- Kevin

On 3/30/2021 7:30 AM, Kevin Rushforth wrote:
> I just noticed a copy/paste error:
>
> > We plan to fork a jfx16 stabilization branch at RDP1.
>
> That should be a "jfx17" branch.
>
> -- Kevin
>
>
> On 3/30/2021 7:28 AM, Kevin Rushforth wrote:
>> ?Here is the proposed schedule for JavaFX 17.
>>
>> RDP1: Jul 8, 2021 (aka ?feature freeze?)
>> RDP2: Jul 29, 2021
>> Freeze: Aug 19, 2021
>> GA: Sep 7, 2021
>>
>> We plan to fork a jfx16 stabilization branch at RDP1. The GA date is 
>> expected to be one week ahead of JDK 17, matching what we did for 16.
>>
>> As was done for the previous release, the start of RDP1, the start of 
>> RDP2, and the code freeze will be 16:00 UTC on the respective dates.
>>
>> Please let Johan or me know if you have any questions.
>>
>> -- Kevin
>>
>

From fastegal at openjdk.java.net  Wed Jul 28 15:29:30 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 28 Jul 2021 15:29:30 GMT
Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v3]
In-Reply-To: 
References: 

Message-ID: <7mEujwJqKovdWM1oXwgi3fOiGXfLMTdypdszr5Y7QH4=.2d74d22a-5c3f-460e-9e45-de4f231523f2@github.com>

On Thu, 8 Jul 2021 21:15:29 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:
> 
>   Reordered commit

will take a closer look next week or so, for now just a starter: fix looks fine, verified test failing/passing before/after :)

As to the tests, left a couple of inline comments to ListCellStartEditTest - others should be changed in the same way.

modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellStartEditTest.java line 75:

> 73:         this.listCell = listCell;
> 74:     }
> 75: 

this hit me when trying separate out the (accidentally?) single test method: all tests work on the same instance of the cell, so its state is unpredictable. Instead, parameterize on a supplier and let it provide a new cell in setup.

modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellStartEditTest.java line 88:

> 86: 
> 87:         listCell.updateIndex(0);
> 88: 

for my taste, this method is doing too much: the first line is the real subject of the issue (throwing an NPE), the rest of the method is testing the other issue (make sure that editability constraints are respected for all combinations). 

My suggestion: separate them out into different methods, f.i. 

- testStartEditMustNotThrowNPE (containing only the single offending line)
- testStartEditRespectsEditable (containing the rest)
- not yet covered: sanity test that startEdit really installs the editing visuals - f.i. by checking that its graphic is null before/ not-null after startEdit

-------------

Changes requested by fastegal (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/569

From kcr at openjdk.java.net  Wed Jul 28 16:01:41 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 16:01:41 GMT
Subject: RFR: 8253351: MediaPlayer does not display an mp4 if there no
 speakers connected to the PC's [v2]
In-Reply-To: <5xMIQRF9jBWNmL4TS68IMgFPjj4652m5c8_DknwFBgw=.395ba7c6-5bc7-49db-bcd2-5129087b5edb@github.com>
References: 
 <5xMIQRF9jBWNmL4TS68IMgFPjj4652m5c8_DknwFBgw=.395ba7c6-5bc7-49db-bcd2-5129087b5edb@github.com>
Message-ID: 

On Mon, 26 Jul 2021 22:23:20 GMT, Alexander Matveev  wrote:

>> Fixed by not failing initialization if DSERR_NODRIVER is returned, which will be return if device is not present at all. Fixed format initialization even if DirectSound device was not created in case if audio device will arrive after playback started. Since we already handle correctly device arrival after playback started, audio will resume if device is enabled or USB audio card is plugged back. Due to lack of access to USB audio device, it was tested by disabling sound card via Device Manager, then starting playback (video plays, but not audio) and then enabling device and once enabled audio will start playing.
>
> Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8253351
>  - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's

Looks good to me. I didn't fully verify the fix on a system without speakers (although I did some limited testing), but did run a set of regression tests.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/586

From arapte at openjdk.java.net  Wed Jul 28 17:22:32 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 28 Jul 2021 17:22:32 GMT
Subject: [jfx17] RFR: 8271086: Block comments of form '/***' are treated
 as javadoc comments
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 Jul 2021 22:07:34 GMT, Kevin Rushforth  wrote:

> This fix for [JDK-8271086](https://bugs.openjdk.java.net/browse/JDK-8271086) is part of a larger cleanup effort to find and fix places where we have missing or redundant API comments. See [JDK-8271083](https://bugs.openjdk.java.net/browse/JDK-8271083).
> 
> This fixes a long-standing problem dating back to (at least) JavaFX 2 where block comments of the following form are sometimes treated as javadoc comments:
> 
> 
>     /***************************************************************************
>      * ...
>      **************************************************************************/
> 
> 
> There are several places where a block comment like this unintentionally shows up in our API documentation. For example, see the generated docs for [Node::getNodeOrientation](https://openjfx.io/javadoc/16/javafx.graphics/javafx/scene/Node.html#getNodeOrientation%28%29) where the literal string `* Component Orientation Properties * *` is presented in the docs.
> 
> The best solution is to simply eliminate this style of block comment as an anti-pattern everywhere it occurs in our Java code.
> 
> There are a total of 982 such occurrences (in 185 different files). All but 7 of these follow the pattern shown above, where the trimmed first line of the block is a single `/` followed by 4 or more `*` characters, and contains no other characters. Like this:
> 
> 
>     /***************************************************************************
> 
> 
> The remaining 7 are comments with some variation, either being an inline comment (starting with `//`) or having text in the middle, or in one case is intended to be a javadoc comment, but with an extra `*` -- `/***` rather than `/**`. I fixed those 7 manually and then ran a script to fix the remaining 975 comments, by replacing the 2nd `*` with a space (thus preserving the line length).
> 
> So:
> 
> 
>     /***************************************************************************
> 
> 
> becomes
> 
> 
>     /* *************************************************************************
> 
> 
> ## Notes to Reviewers
> 
> 1. The 7 manual changes are in the first commit, and the automated changes are in the second comment. I have run a build + sanity test, and I did a diff of the generated API docs generated by `gradle javadoc` and also visually inspected the docs (spot checked), and confirmed that it fixes the problem.
> 2. This is targeted to `jfx17`.

Looks good to me, verified javadoc build and doc. This is correcting plenty wrong docs.

-------------

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/585

From kcr at openjdk.java.net  Wed Jul 28 17:26:34 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 17:26:34 GMT
Subject: [jfx17] Integrated: 8271086: Block comments of form '/***' are
 treated as javadoc comments
In-Reply-To: 
References: 
Message-ID: 

On Thu, 22 Jul 2021 22:07:34 GMT, Kevin Rushforth  wrote:

> This fix for [JDK-8271086](https://bugs.openjdk.java.net/browse/JDK-8271086) is part of a larger cleanup effort to find and fix places where we have missing or redundant API comments. See [JDK-8271083](https://bugs.openjdk.java.net/browse/JDK-8271083).
> 
> This fixes a long-standing problem dating back to (at least) JavaFX 2 where block comments of the following form are sometimes treated as javadoc comments:
> 
> 
>     /***************************************************************************
>      * ...
>      **************************************************************************/
> 
> 
> There are several places where a block comment like this unintentionally shows up in our API documentation. For example, see the generated docs for [Node::getNodeOrientation](https://openjfx.io/javadoc/16/javafx.graphics/javafx/scene/Node.html#getNodeOrientation%28%29) where the literal string `* Component Orientation Properties * *` is presented in the docs.
> 
> The best solution is to simply eliminate this style of block comment as an anti-pattern everywhere it occurs in our Java code.
> 
> There are a total of 982 such occurrences (in 185 different files). All but 7 of these follow the pattern shown above, where the trimmed first line of the block is a single `/` followed by 4 or more `*` characters, and contains no other characters. Like this:
> 
> 
>     /***************************************************************************
> 
> 
> The remaining 7 are comments with some variation, either being an inline comment (starting with `//`) or having text in the middle, or in one case is intended to be a javadoc comment, but with an extra `*` -- `/***` rather than `/**`. I fixed those 7 manually and then ran a script to fix the remaining 975 comments, by replacing the 2nd `*` with a space (thus preserving the line length).
> 
> So:
> 
> 
>     /***************************************************************************
> 
> 
> becomes
> 
> 
>     /* *************************************************************************
> 
> 
> ## Notes to Reviewers
> 
> 1. The 7 manual changes are in the first commit, and the automated changes are in the second comment. I have run a build + sanity test, and I did a diff of the generated API docs generated by `gradle javadoc` and also visually inspected the docs (spot checked), and confirmed that it fixes the problem.
> 2. This is targeted to `jfx17`.

This pull request has now been integrated.

Changeset: 78a3721a
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/78a3721a2b126e174b5fd94ea1d15ccdbe6d3624
Stats:     982 lines in 185 files changed: 0 ins; 0 del; 982 mod

8271086: Block comments of form '/***' are treated as javadoc comments

Reviewed-by: arapte

-------------

PR: https://git.openjdk.java.net/jfx/pull/585

From kcr at openjdk.java.net  Wed Jul 28 17:39:56 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 17:39:56 GMT
Subject: [jfx17] RFR: 8212088: Missing copyright notices for property files
Message-ID: 

This PR adds missing copyright header blocks for several properties files, script files, and textual data files (e.g., fxml, css) that do not have them. Where feasible, all non-trivial textual files in the repo should have a proper copyright header.

## Notes to Reviewers

* This PR is targeted to the `jfx17` branch.
* There are two commits that can be reviewed separately, if you  prefer. The first covers most of the files, and adds a copyright header with a GPL v2 + classpath license. The second is for the `apps/samples` only, which adds a copyright header with a BSD-style license.

-------------

Commit messages:
 - 8212088: Missing copyright notices for property files (samples)
 - 8212088: Missing copyright notices for property files

Changes: https://git.openjdk.java.net/jfx/pull/591/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=591&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8212088
  Stats: 1712 lines in 66 files changed: 1702 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jfx/pull/591.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/591/head:pull/591

PR: https://git.openjdk.java.net/jfx/pull/591

From jvos at openjdk.java.net  Wed Jul 28 18:31:44 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 28 Jul 2021 18:31:44 GMT
Subject: RFR: 8253351: MediaPlayer does not display an mp4 if there no
 speakers connected to the PC's [v2]
In-Reply-To: <5xMIQRF9jBWNmL4TS68IMgFPjj4652m5c8_DknwFBgw=.395ba7c6-5bc7-49db-bcd2-5129087b5edb@github.com>
References: 
 <5xMIQRF9jBWNmL4TS68IMgFPjj4652m5c8_DknwFBgw=.395ba7c6-5bc7-49db-bcd2-5129087b5edb@github.com>
Message-ID: <7GrI_LzQgxauPN1SIYngkDgK88SaFyqV7Lui4Rn9q5U=.dea31825-89f2-42f1-a8a1-8c89d3111274@github.com>

On Mon, 26 Jul 2021 22:23:20 GMT, Alexander Matveev  wrote:

>> Fixed by not failing initialization if DSERR_NODRIVER is returned, which will be return if device is not present at all. Fixed format initialization even if DirectSound device was not created in case if audio device will arrive after playback started. Since we already handle correctly device arrival after playback started, audio will resume if device is enabled or USB audio card is plugged back. Due to lack of access to USB audio device, it was tested by disabling sound card via Device Manager, then starting playback (video plays, but not audio) and then enabling device and once enabled audio will start playing.
>
> Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8253351
>  - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's

Looks good. In the old and new code, there are some memory operations that I'm a little worried about, but as far as I can tell there are no changes related to that between the old and the new code -- at least I don't see a scenario where a free occurs now while it didn't occur before.

-------------

Marked as reviewed by jvos (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/586

From jvos at openjdk.java.net  Wed Jul 28 18:35:36 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 28 Jul 2021 18:35:36 GMT
Subject: [jfx17] RFR: 8212088: Missing copyright notices for property files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 28 Jul 2021 17:34:32 GMT, Kevin Rushforth  wrote:

> This PR adds missing copyright header blocks for several properties files, script files, and textual data files (e.g., fxml, css) that do not have them. Where feasible, all non-trivial textual files in the repo should have a proper copyright header.
> 
> ## Notes to Reviewers
> 
> * This PR is targeted to the `jfx17` branch.
> * There are two commits that can be reviewed separately, if you  prefer. The first covers most of the files, and adds a copyright header with a GPL v2 + classpath license. The second is for the `apps/samples` only, which adds a copyright header with a BSD-style license.

Is there a reason why the samples have a BSD license while the others have GPL + CPE? (not that I'm against BSD, just wondering)

-------------

PR: https://git.openjdk.java.net/jfx/pull/591

From kcr at openjdk.java.net  Wed Jul 28 18:49:36 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 18:49:36 GMT
Subject: [jfx17] RFR: 8212088: Missing copyright notices for property files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 28 Jul 2021 17:34:32 GMT, Kevin Rushforth  wrote:

> This PR adds missing copyright header blocks for several properties files, script files, and textual data files (e.g., fxml, css) that do not have them. Where feasible, all non-trivial textual files in the repo should have a proper copyright header.
> 
> ## Notes to Reviewers
> 
> * This PR is targeted to the `jfx17` branch.
> * There are two commits that can be reviewed separately, if you  prefer. The first covers most of the files, and adds a copyright header with a GPL v2 + classpath license. The second is for the `apps/samples` only, which adds a copyright header with a BSD-style license.

Yes. All of JavaFX is licensed under GPL except for the sample applications under `apps/samples`, which are licensed under BSD (`apps/scenebuilder` was similarly licensed under BSD before it was removed from the repo).

-------------

PR: https://git.openjdk.java.net/jfx/pull/591

From jvos at openjdk.java.net  Wed Jul 28 18:56:31 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 28 Jul 2021 18:56:31 GMT
Subject: [jfx17] RFR: 8212088: Missing copyright notices for property files
In-Reply-To: 
References: 
Message-ID: <9aD0rGm1ndWRaGOjQGc3BH_SPtuMuhVncp9fnoCqRW4=.98305c31-9c71-46b5-9ccb-e96979f35cd1@github.com>

On Wed, 28 Jul 2021 17:34:32 GMT, Kevin Rushforth  wrote:

> This PR adds missing copyright header blocks for several properties files, script files, and textual data files (e.g., fxml, css) that do not have them. Where feasible, all non-trivial textual files in the repo should have a proper copyright header.
> 
> ## Notes to Reviewers
> 
> * This PR is targeted to the `jfx17` branch.
> * There are two commits that can be reviewed separately, if you  prefer. The first covers most of the files, and adds a copyright header with a GPL v2 + classpath license. The second is for the `apps/samples` only, which adds a copyright header with a BSD-style license.

Marked as reviewed by jvos (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/591

From kcr at openjdk.java.net  Wed Jul 28 18:56:32 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 18:56:32 GMT
Subject: [jfx17] RFR: 8212088: Missing copyright notices for property files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 28 Jul 2021 17:34:32 GMT, Kevin Rushforth  wrote:

> This PR adds missing copyright header blocks for several properties files, script files, and textual data files (e.g., fxml, css) that do not have them. Where feasible, all non-trivial textual files in the repo should have a proper copyright header.
> 
> ## Notes to Reviewers
> 
> * This PR is targeted to the `jfx17` branch.
> * There are two commits that can be reviewed separately, if you  prefer. The first covers most of the files, and adds a copyright header with a GPL v2 + classpath license. The second is for the `apps/samples` only, which adds a copyright header with a BSD-style license.

I should add, that the JDK samples are similarly licensed under BSD, so JavaFX followed suit (the JavaFX samples are bundled with the JDK samples in JDK 8).

-------------

PR: https://git.openjdk.java.net/jfx/pull/591

From arapte at openjdk.java.net  Wed Jul 28 21:03:31 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 28 Jul 2021 21:03:31 GMT
Subject: [jfx17] RFR: 8212088: Missing copyright notices for property files
In-Reply-To: 
References: 
Message-ID: <9oF47rQNAMZtRNyNcU5A_sXSibCo8wOtcXUkIpo9_Cs=.2b53f38f-13bd-4f7e-8cd4-2df8a7c2543e@github.com>

On Wed, 28 Jul 2021 17:34:32 GMT, Kevin Rushforth  wrote:

> This PR adds missing copyright header blocks for several properties files, script files, and textual data files (e.g., fxml, css) that do not have them. Where feasible, all non-trivial textual files in the repo should have a proper copyright header.
> 
> ## Notes to Reviewers
> 
> * This PR is targeted to the `jfx17` branch.
> * There are two commits that can be reviewed separately, if you  prefer. The first covers most of the files, and adds a copyright header with a GPL v2 + classpath license. The second is for the `apps/samples` only, which adds a copyright header with a BSD-style license.

Looks good to me.

-------------

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/591

From kcr at openjdk.java.net  Wed Jul 28 21:22:34 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 21:22:34 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: <-3kQ6O1bd547-jkHMsHHV_i5-GqLljoIXJ-kl1TSuiY=.a964456f-ca7a-4f0b-9b9e-91f98ab62413@github.com>

On Wed, 28 Jul 2021 13:08:28 GMT, Pankaj Bansal  wrote:

> I am surprised that this does not need a CSR. It looks like too much bigger documentation change for not needing a CSR.

JavaFX doesn't impose the same requirement of needing a CSR for everything that touches API documentation as does the JDK. In this case, it is just adding obvious and missing API docs without any changes in documented behavior or any additional conditions in the specification. While it wouldn't hurt to have a CSR, I'm not sure I see the need.

Btw, the number of lines of documentation added isn't really the question. A one-line change can end up needing a CSR if there are changes to the specified semantics.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Wed Jul 28 21:56:37 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 21:56:37 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 28 Jul 2021 09:34:33 GMT, Nir Lisker  wrote:

> I have spotted some missing docs:
> 
> * `CompoundSelector` missing docs for methods overriden from `Object`.

I'm not too worried about the missing docs for overridden methods. Unless we are overriding it in a way that needs to be documented, we don't want or need to add any explicit documentation. We could add `/** {@inheritDoc} */` for those (and it seems a good idea), but it turns out that when overriding JDK methods such as `toString()`, the generated docs are the same with or without `{@inheritDoc}`. We could consider a follow-on issue (not limited to `javafx.css`) to address this, which might involve changes to options that we pass to the `javadoc` tool.

> * `CssMetaData` is missing docs for methods `hashCode()`, `getConverter()` and `getProperty()`.

I think `getProperty()` and `getConverter()` should be fixed in this PR.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From nlisker at openjdk.java.net  Wed Jul 28 22:07:32 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 28 Jul 2021 22:07:32 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 28 Jul 2021 21:53:38 GMT, Kevin Rushforth  wrote:

> I think `getProperty()` and `getConverter()` should be fixed in this PR.

There could be more methods like that. Maybe the script should check specifically for a missing summary?

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From almatvee at openjdk.java.net  Wed Jul 28 22:27:32 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 28 Jul 2021 22:27:32 GMT
Subject: Integrated: 8253351: MediaPlayer does not display an mp4 if there no
 speakers connected to the PC's
In-Reply-To: 
References: 
Message-ID: 

On Sat, 24 Jul 2021 02:59:52 GMT, Alexander Matveev  wrote:

> Fixed by not failing initialization if DSERR_NODRIVER is returned, which will be return if device is not present at all. Fixed format initialization even if DirectSound device was not created in case if audio device will arrive after playback started. Since we already handle correctly device arrival after playback started, audio will resume if device is enabled or USB audio card is plugged back. Due to lack of access to USB audio device, it was tested by disabling sound card via Device Manager, then starting playback (video plays, but not audio) and then enabling device and once enabled audio will start playing.

This pull request has now been integrated.

Changeset: b738e1ce
Author:    Alexander Matveev 
URL:       https://git.openjdk.java.net/jfx/commit/b738e1cee709d0842196c086ad33db95a6e13856
Stats:     27 lines in 1 file changed: 18 ins; 7 del; 2 mod

8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's

Reviewed-by: jvos, kcr

-------------

PR: https://git.openjdk.java.net/jfx/pull/586

From kcr at openjdk.java.net  Wed Jul 28 23:09:40 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 23:09:40 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Jul 2021 12:44:58 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - add missing @since tag

I did a pretty complete review of the docs, and left what are mostly minor (and in some cases picky) comments.

modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 110:

> 108: 
> 109: /**
> 110:  * A parser for CSS document string.

I suggest either `document strings.` or `a document string`.

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 36:

> 34: 
> 35: /**
> 36:  * This class serves as a container of CSS property and its value.

`a CSS property`

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 91:

> 89:     /**
> 90:      * Gets the importance of this {@code Declaration}.
> 91:      * @return important

Maybe `@return the important flag` or `@return whether this {@code Declaration} is important`?

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 113:

> 111:      * the {@code Declaration} belongs. Only the property, value and importance are
> 112:      * considered.
> 113:      * 

No need for a ``. Also there is a missing `@param obj` tag.

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 114:

> 112:      * considered.
> 113:      * 
> 114:      * @return true if this object is the same as the obj argument; false otherwise.

I recommend code style for `true`, `obj`, and `false`.

modules/javafx.graphics/src/main/java/javafx/css/PseudoClass.java line 87:

> 85:      * 
> 86:      * Note: There is only one {@code PseudoClass} instance for a given pseudo class name.
> 87:      * 

No need for ``.

modules/javafx.graphics/src/main/java/javafx/css/PseudoClass.java line 99:

> 97:     /**
> 98:      * Gets the name of the {@code PseudoClass}.
> 99:      * @return the name of the {@code PseudoClass}.

You can remove the `.` here.

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 101:

> 99: 
> 100:     /**
> 101:      * Same as the matches method expect return true/false rather than a match.

Perhaps add an initial sentence like `Gets whether this {@code Selector} applies to the given {@code Styleable}.`? This (now second) sentence could use a little rewording to make it a complete sentence and `matches` could maybe be a link.

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 103:

> 101:      * Same as the matches method expect return true/false rather than a match.
> 102:      * @param styleable styleable to match.
> 103:      * @return {@code true} if this {@code Selector} applies to the given {@code Styleable}.

No need for periods for these two tags.

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 108:

> 106: 
> 107:     /**
> 108:      * Same as applies, but will return pseudoclass state that it finds along the way.

Same comment as above.

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 113:

> 111:      * @param depth depth of the {@code Node} heirarchy to look for
> 112:      * @return {@code true} if this {@code Selector} and a set of {@code PseudoClass}
> 113:      * applies to the given {@code Styleable}.

No need for period here.

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 133:

> 131:      * Writes {@code Selector} data in binary form to given {@code DataOutputStream}.
> 132:      * @param os {@code DataOutputStream} to write {@code Selector} data to
> 133:      * @param stringStore unsused

Typo: `unsused` --> `unused`

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 163:

> 161:     /**
> 162:      * Creates a {@code Selector} object.
> 163:      * @param cssSelector css selector string

`CSS` should be upper case (not the parameter name, of course)

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 164:

> 162:      * Creates a {@code Selector} object.
> 163:      * @param cssSelector css selector string
> 164:      * @return a Selector

`selector` or `{@code Selector}`

modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 74:

> 72:     /**
> 73:      * Gets Immutable List of style-classes of the selector.
> 74:      * @return Immutable List<String> of style-classes of the selector

Maybe better in this case to just say `list` (lower case) for both the description and `@return`? Otherwise, use code style. Also, "immutable" should not be capitalized.

modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 90:

> 88:     /**
> 89:      * Gets the {@code Set} of {@code StyleClass} of the selector.
> 90:      * @return set of style class

style classes (plural)

modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 151:

> 149:     // Used in Match. If nodeOrientation is ltr or rtl,
> 150:     // then count it as a pseudoclass
> 151:     /** Gets {@code NodeOrientation} of this Selector.

Minor: move the text to the next line so the `/**` is on a line by itself.

modules/javafx.graphics/src/main/java/javafx/css/SimpleSelector.java line 152:

> 150:     // then count it as a pseudoclass
> 151:     /** Gets {@code NodeOrientation} of this Selector.
> 152:      * @return nodeOrientation

either `node orientation` or `{@code NodeOrientation}`

modules/javafx.graphics/src/main/java/javafx/css/StyleConverter.java line 567:

> 565: 
> 566:         /**
> 567:          * Writes the StringStore strings to a given {@code DataOutputStream}.

`{@code StringStore}`

modules/javafx.graphics/src/main/java/javafx/css/converter/EffectConverter.java line 41:

> 39: 
> 40: /**
> 41:  * Converter to convert representation of an {@code Effect} to an {@code Effect}.

`a representation` or maybe `a string representation`?

modules/javafx.graphics/src/main/java/javafx/css/converter/EffectConverter.java line 82:

> 80: 
> 81:     /**
> 82:      * Converter to convert DropShadow {@code Effect}.

Maybe `Converter to convert a {@code DropShadow}.` or  `Converter to convert a {@code DropShadow} effect.`

modules/javafx.graphics/src/main/java/javafx/css/converter/EnumConverter.java line 127:

> 125:      */
> 126:     // package for unit testing
> 127:     static public StyleConverter getInstance(final String ename) {

Independent of the doc change, the inline comment is wrong: This is a public, not a package-scope method. Maybe remove the comment?

modules/javafx.graphics/src/main/java/javafx/css/converter/StringConverter.java line 47:

> 45:     /**
> 46:      * Get the {@code StringConverter} instance.
> 47:      * @return the {@code StringConverter} instance.

You can remove the period.

modules/javafx.graphics/src/main/java/javafx/css/converter/StringConverter.java line 72:

> 70: 
> 71:     /**
> 72:      * Converter to convert a sequence of {@code String}s to a String[].

I recommend code style for the `String[]` or else say `an array of {@code String}s`.

modules/javafx.graphics/src/main/java/javafx/css/converter/StringConverter.java line 79:

> 77:         /**
> 78:          * Get the {@code SequenceConverter} instance.
> 79:          * @return the {@code SequenceConverter} instance.

Extra period.

modules/javafx.graphics/src/main/java/javafx/css/converter/URLConverter.java line 254:

> 252: 
> 253:     /**
> 254:      * Converter to convert a sequence of URLs to a String[].

Same comment as above about using code style for `String[]`

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Wed Jul 28 23:09:41 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 23:09:41 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 28 Jul 2021 09:37:17 GMT, Pankaj Bansal  wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8250590 - add missing @since tag
>
> modules/javafx.graphics/src/main/java/javafx/css/Rule.java line 141:
> 
>> 139: 
>> 140:     /**
>> 141:      * The {@code Stylesheet} this {@code Selector} belongs to.
> 
> Should not this be "The {@code Stylesheet} this {@code Rule} belongs to" ?

Or better still: `Gets the {@code Stylesheet} this {@code Rule} belongs to.`

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Wed Jul 28 23:28:31 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 23:28:31 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: <7Uzevv7yA0RVHPAnn9jDtWyb6Ujy5dNvnPs-8QFATBE=.2f3fa339-2398-48ad-98cb-e1c2fa1ffaed@github.com>

On Wed, 28 Jul 2021 22:05:00 GMT, Nir Lisker  wrote:

> > I think `getProperty()` and `getConverter()` should be fixed in this PR.
> 
> There could be more methods like that. Maybe the script should check specifically for a missing summary?

We just used the `javadoc` tool to find them, so would need support from the `javadoc` tool itself. I looked through all of the docs and only found one more: `ParsedValue.getValue()`.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Thu Jul 29 07:20:36 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 29 Jul 2021 07:20:36 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: <7Uzevv7yA0RVHPAnn9jDtWyb6Ujy5dNvnPs-8QFATBE=.2f3fa339-2398-48ad-98cb-e1c2fa1ffaed@github.com>
References: 

 <7Uzevv7yA0RVHPAnn9jDtWyb6Ujy5dNvnPs-8QFATBE=.2f3fa339-2398-48ad-98cb-e1c2fa1ffaed@github.com>
Message-ID: 

On Wed, 28 Jul 2021 23:25:34 GMT, Kevin Rushforth  wrote:

> > > I think `getProperty()` and `getConverter()` should be fixed in this PR.
> > 
> > 
> > There could be more methods like that. Maybe the script should check specifically for a missing summary?
> 
> We just used the `javadoc` tool to find them, so would need support from the `javadoc` tool itself. I looked through all of the docs and only found one more: `ParsedValue.getValue()`.

I found few more such methods in javafx.css package using "find in files" in my editor and fixed them.

- CssMetaData.getProperty() 
- CssMetaData.getConverter()
- ParsedValue.getValue()
- PseudoClassImpl.getPseudoClassName()
- PseudoClassImpl.toString()
- SimpleSelector.getPseudoclasses()

Interestingly this is not only limited to javafx.css package, but spread across all JavaFX modules.
I have filed [JDK-8271460](https://bugs.openjdk.java.net/browse/JDK-8271460) for fixing this.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From fkirmaier at openjdk.java.net  Thu Jul 29 07:47:29 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Thu, 29 Jul 2021 07:47:29 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v2]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 22 Jul 2021 11:50:11 GMT, Florian Kirmaier  wrote:

>> After thinking about this issue for some time, I've now got a solution.
>> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. 
>> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269907
>   The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks.

It would be possible to add it to the existing PulseListener, but i think it would be more complicated. It might require some code to decide whether it should only clean the dirty children, or do the full pulse. The logic to add/remove the listener also would have to be more complicated.

Actually it was my first approach, but i didn't find a good place "to get started".

-------------

PR: https://git.openjdk.java.net/jfx/pull/584

From aghaisas at openjdk.java.net  Thu Jul 29 08:43:59 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 29 Jul 2021 08:43:59 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v4]
In-Reply-To: 
References: 
Message-ID: 

> This PR corrects/adds missing documentation for classes in javafx.css package.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  8250590 - fix review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/589/files
  - new: https://git.openjdk.java.net/jfx/pull/589/files/76439ae4..2500661c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=02-03

  Stats: 74 lines in 15 files changed: 28 ins; 1 del; 45 mod
  Patch: https://git.openjdk.java.net/jfx/pull/589.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/589/head:pull/589

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Thu Jul 29 08:44:02 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 29 Jul 2021 08:44:02 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Jul 2021 12:44:58 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - add missing @since tag

Thanks for a detailed review of the changes.
I have addressed the review comments. Request your re-look at the latest changes.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Thu Jul 29 09:05:35 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 29 Jul 2021 09:05:35 GMT
Subject: [jfx17] RFR: 8212088: Missing copyright notices for property files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 28 Jul 2021 17:34:32 GMT, Kevin Rushforth  wrote:

> This PR adds missing copyright header blocks for several properties files, script files, and textual data files (e.g., fxml, css) that do not have them. Where feasible, all non-trivial textual files in the repo should have a proper copyright header.
> 
> ## Notes to Reviewers
> 
> * This PR is targeted to the `jfx17` branch.
> * There are two commits that can be reviewed separately, if you  prefer. The first covers most of the files, and adds a copyright header with a GPL v2 + classpath license. The second is for the `apps/samples` only, which adds a copyright header with a BSD-style license.

Marked as reviewed by aghaisas (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/591

From nlisker at openjdk.java.net  Thu Jul 29 09:17:35 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 29 Jul 2021 09:17:35 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Jul 2021 08:43:59 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - fix review comments

In `Declaration` something is wrong with the html rendering in the last lines, the columns are misaligned:
![image](https://user-images.githubusercontent.com/37422899/127464002-9d77ff25-c5b7-4058-9797-5379c62ded8d.png)

Same with `Stylesheet`.

Does it comes out like that just for me? I didn't see anything wrong with the code after a quick look.

Also, `Match.compareTo` is overriden from `Comparable` without a doc, but maybe something needs to be specified there about what is being compared or for what purpose `Comparable` is implemented to begin with?

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Thu Jul 29 09:41:35 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 29 Jul 2021 09:41:35 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Jul 2021 08:43:59 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - fix review comments

I see that this is a much wider problem with openjfx17 documentation.
Wherever only `@inheritDoc` is used, we are having this corruption in final html documentation.
For example - look for class documentation of  javafx.scene.layout.BackgroundSize in html.
The same class documentation of openjfx16 is all fine - (https://openjfx.io/javadoc/16/javafx.graphics/javafx/scene/layout/BackgroundSize.html)

Need to find root cause and fix this.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Thu Jul 29 11:21:34 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 11:21:34 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v4]
In-Reply-To: 
References: 

Message-ID: <2HqgSLWG770mQM2xjZ_sQhVLPVTSkq26q9qhXJp_V0I=.957e2c07-8f9b-4cb2-89c8-9b3a2cd5a40f@github.com>

On Thu, 29 Jul 2021 09:38:35 GMT, Ajit Ghaisas  wrote:

> Wherever only @inheritDoc is used, we are having this corruption in final html documentation

I saw this problem with `@inheritDoc` yesterday as well, and was getting ready to report it here, but then couldn't reproduce it with a clean build of the docs. I'll try it again with a fully clean build (not just a clean docs build). If reproducible, it seems likely that this is a bug in the `javadoc` tool.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Thu Jul 29 11:31:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 11:31:33 GMT
Subject: [jfx17] Integrated: 8212088: Missing copyright notices for property
 files
In-Reply-To: 
References: 
Message-ID: 

On Wed, 28 Jul 2021 17:34:32 GMT, Kevin Rushforth  wrote:

> This PR adds missing copyright header blocks for several properties files, script files, and textual data files (e.g., fxml, css) that do not have them. Where feasible, all non-trivial textual files in the repo should have a proper copyright header.
> 
> ## Notes to Reviewers
> 
> * This PR is targeted to the `jfx17` branch.
> * There are two commits that can be reviewed separately, if you  prefer. The first covers most of the files, and adds a copyright header with a GPL v2 + classpath license. The second is for the `apps/samples` only, which adds a copyright header with a BSD-style license.

This pull request has now been integrated.

Changeset: df07ac87
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/df07ac8748ec562cd0e50e50910ecc901105009c
Stats:     1712 lines in 66 files changed: 1702 ins; 0 del; 10 mod

8212088: Missing copyright notices for property files

Reviewed-by: jvos, arapte, aghaisas

-------------

PR: https://git.openjdk.java.net/jfx/pull/591

From kcr at openjdk.java.net  Thu Jul 29 11:51:34 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 11:51:34 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v3]
In-Reply-To: 
References: 

 <7Uzevv7yA0RVHPAnn9jDtWyb6Ujy5dNvnPs-8QFATBE=.2f3fa339-2398-48ad-98cb-e1c2fa1ffaed@github.com>

Message-ID: 

On Thu, 29 Jul 2021 07:17:45 GMT, Ajit Ghaisas  wrote:

> I found few more such methods in javafx.css package using "find in files" in my editor and fixed them.
> 
...
> * PseudoClassImpl.getPseudoClassName()
> * PseudoClassImpl.toString()
> * SimpleSelector.getPseudoclasses()

These three are not part of the public API. `PseudoClassImpl` is a package-scope class and `SimpleSelector.getPseudoclasses()` is a package-scope method, so they don't need any javadoc comments (although since you've already added them, there is no need to remove them).

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Thu Jul 29 12:33:34 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 12:33:34 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Jul 2021 08:43:59 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - fix review comments

> > Wherever only @inheritdoc is used, we are having this corruption in final html documentation
> 
> I saw this problem with `@inheritDoc` yesterday as well, and was getting ready to report it here, but then couldn't reproduce it with a clean build of the docs. I'll try it again with a fully clean build (not just a clean docs build). If reproducible, it seems likely that this is a bug in the `javadoc` tool.

I can confirm that this is a `javadoc` tool bug. It is already fixed in JDK 17, but since we use JDK 16 as the boot JDK, we will see it. Since `{@inheritDoc}` doesn't do anything for standard JDK classes that we override, except to provoke this bug, we should avoid this pattern for now.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Thu Jul 29 12:56:35 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 12:56:35 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Jul 2021 08:43:59 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - fix review comments

I left just a few more (mostly minor) comments.

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 115:

> 113:      *
> 114:      * @param obj an {@code Object} to compare
> 115:      * @return {@code true} if this object is the same as the {@code obj} argument; {@code false} otherwise.

Minor: you can remove the period

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 145:

> 143:     /**
> 144:      * {@inheritDoc}
> 145:      */

Given the `javadoc` tool bug, it's best to revert this (and have no comment on this overridden method).

modules/javafx.graphics/src/main/java/javafx/css/Declaration.java line 156:

> 154:     /**
> 155:      * {@inheritDoc}
> 156:      */

Revert.

modules/javafx.graphics/src/main/java/javafx/css/Match.java line 86:

> 84:     /**
> 85:      * Gets the specificity.
> 86:      * @return the specificity.

Minor: you can remove the period

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 102:

> 100:     /**
> 101:      * Gets whether this {@code Selector} applies to the given {@code Styleable}.
> 102:      * It is same as the {@link createMatch} method except it returns true/false rather than a {@code Match}.

It is _the_ same ...

Minor: `true/false` --> `a boolean`?

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 110:

> 108:     /**
> 109:      * Gets whether this {@code Selector} applies to the given {@code Styleable}.
> 110:      * It is same as {@link applies} method except it also returns

The link happens to work, but since there is more than one `applies` method, it's better to specify which one. Also, it isn't grammatically correct. Maybe something like this:

It is the same as the {@link applies(Styleable) applies(Styleable)} method ...

modules/javafx.graphics/src/main/java/javafx/css/converter/EffectConverter.java line 82:

> 80: 
> 81:     /**
> 82:      * Converter to convert a {@code DropShadow} effect.

Good. Can you also apply this change to `InnerShadowConverter`?

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From fastegal at openjdk.java.net  Thu Jul 29 14:15:43 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 29 Jul 2021 14:15:43 GMT
Subject: RFR: 8271484: Tree-/TableCell: NPE when accessing edit event from
 startEdit
Message-ID: 

The NPE was an indirect effect: 

- the bug on part of the cell was an incorrect (== missing) edit location in cellEditEvent - that's fixed in this PR
- a related bug is on part of the implementation of CellEditEvent (assuming that TablePosition != null, [JDK-8269871](https://bugs.openjdk.java.net/browse/JDK-8269871) which is not addressed in this PR

Fix is to use the cell's state at startEdit for creating the editing location, added tests starting the edit on the cell that failed/passed before/after the fix, also added sanity tests with starting edit on the control that passed before/after.

-------------

Commit messages:
 - 8271484: Tree-/TableCell: NPE when accessing edit event from startEdit

Changes: https://git.openjdk.java.net/jfx/pull/592/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=592&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271484
  Stats: 57 lines in 4 files changed: 53 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/592.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/592/head:pull/592

PR: https://git.openjdk.java.net/jfx/pull/592

From aghaisas at openjdk.java.net  Thu Jul 29 14:33:33 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 29 Jul 2021 14:33:33 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Jul 2021 09:14:58 GMT, Nir Lisker  wrote:

> Also, Match.compareTo is overriden from Comparable without a doc, but maybe something needs to be specified there about what is being compared or for what purpose Comparable is implemented to begin with?

I will add the documentation for this method.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Thu Jul 29 14:38:02 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 29 Jul 2021 14:38:02 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v5]
In-Reply-To: 
References: 
Message-ID: 

> This PR corrects/adds missing documentation for classes in javafx.css package.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  8250590 - fix review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/589/files
  - new: https://git.openjdk.java.net/jfx/pull/589/files/2500661c..642e73f1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=03-04

  Stats: 21 lines in 4 files changed: 10 ins; 6 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/589.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/589/head:pull/589

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Thu Jul 29 14:49:37 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 29 Jul 2021 14:49:37 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Jul 2021 12:30:36 GMT, Kevin Rushforth  wrote:

> > > Wherever only @inheritdoc is used, we are having this corruption in final html documentation
> > 
> > 
> > I saw this problem with `@inheritDoc` yesterday as well, and was getting ready to report it here, but then couldn't reproduce it with a clean build of the docs. I'll try it again with a fully clean build (not just a clean docs build). If reproducible, it seems likely that this is a bug in the `javadoc` tool.
> 
> I can confirm that this is a `javadoc` tool bug. It is already fixed in JDK 17, but since we use JDK 16 as the boot JDK, we will see it. Since `{@inheritDoc}` doesn't do anything for standard JDK classes that we override, except to provoke this bug, we should avoid this pattern for now.

I have filed [JDK-8271485](https://bugs.openjdk.java.net/browse/JDK-8271485) to address this.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Thu Jul 29 16:22:44 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 16:22:44 GMT
Subject: [jfx17] RFR: 8271485: Javadoc "Method Summary" table is misaligned if
 overridden JDK method has {@inheritDoc} tag
Message-ID: 

As noted in the JBS bug report, the javadoc-generated HTML table for a class is messed up if any method is overridden from a core JDK class and has the `{@inheritDoc}` tag. For example, the following taken from the [Background](https://github.com/openjdk/jfx/blob/jfx17/modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java#L622) class provokes this bug:

    /**
     * {@inheritDoc}
     */
    @Override public boolean equals(Object o) {

The proposed fix is to stop generating javadocs for overridden methods with no spec change. This matches how the JDK docs have been generated since JDK 10. See [JDK-8157000](https://bugs.openjdk.java.net/browse/JDK-8157000). This is done by running `javadoc` with the `--override-methods=summary` option.

There is no useful information generated for such overridden methods regardless of whether or not they use the `{@inheritDoc}` tag, so this fix also addresses the problem of having methods with no description.

See the attached "before" and "after" images.

Before:

![javadoc-before](https://user-images.githubusercontent.com/34689748/127527754-ae5c529a-8c49-47a2-b595-5e423f5c9c49.png)

After:

![javadoc-after](https://user-images.githubusercontent.com/34689748/127527789-c97c4689-154f-4ed0-a4a1-5dfdfde0d9d2.png)

-------------

Commit messages:
 - 8271485: Javadoc "Method Summary" table is misaligned if overriden JDK method has {@inheritDoc} tag

Changes: https://git.openjdk.java.net/jfx/pull/593/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=593&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271485
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/593.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/593/head:pull/593

PR: https://git.openjdk.java.net/jfx/pull/593

From kcr at openjdk.java.net  Thu Jul 29 16:28:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 16:28:33 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Jul 2021 14:47:10 GMT, Ajit Ghaisas  wrote:

> I have filed [JDK-8271485](https://bugs.openjdk.java.net/browse/JDK-8271485) to address this.

I just submitted PR #593 with a fix. It will also address the problem noted above of overridden methods without additional documentation showing up with no description, since such methods will no longer show up in the first place.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From kcr at openjdk.java.net  Thu Jul 29 16:59:32 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 16:59:32 GMT
Subject: [jfx17] RFR: 8271485: Javadoc "Method Summary" table is
 misaligned if overridden JDK method has {@inheritDoc} tag
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 Jul 2021 16:18:24 GMT, Kevin Rushforth  wrote:

> As noted in the JBS bug report, the javadoc-generated HTML table for a class is messed up if any method is overridden from a core JDK class and has the `{@inheritDoc}` tag. For example, the following taken from the [Background](https://github.com/openjdk/jfx/blob/jfx17/modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java#L622) class provokes this bug:
> 
> 
>     /**
>      * {@inheritDoc}
>      */
>     @Override public boolean equals(Object o) {
> 
> 
> The proposed fix is to stop generating javadocs for overridden methods with no spec change. This matches how the JDK docs have been generated since JDK 10. See [JDK-8157000](https://bugs.openjdk.java.net/browse/JDK-8157000). This is done by running `javadoc` with the `--override-methods=summary` option.
> 
> There is no useful information generated for such overridden methods regardless of whether or not they use the `{@inheritDoc}` tag, so this fix also addresses the problem of having methods with no description.
> 
> See the attached "before" and "after" images.
> 
> Before:
> 
> ![javadoc-before](https://user-images.githubusercontent.com/34689748/127527754-ae5c529a-8c49-47a2-b595-5e423f5c9c49.png)
> 
> After:
> 
> ![javadoc-after](https://user-images.githubusercontent.com/34689748/127527789-c97c4689-154f-4ed0-a4a1-5dfdfde0d9d2.png)

As a follow-on cleanup bug (for JavaFX 18), we might still want to remove the `{@inheritDoc}` from methods where that is the only javadoc tag present.

-------------

PR: https://git.openjdk.java.net/jfx/pull/593

From kcr at openjdk.java.net  Thu Jul 29 17:51:38 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 17:51:38 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v5]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Jul 2021 14:38:02 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - fix review comments

Two remaining comments. I looked through all the generated docs and everything else looks good.

modules/javafx.graphics/src/main/java/javafx/css/PseudoClass.java line 90:

> 88:      * @param pseudoClass the name of the pseudo class
> 89:      * @return the {@code PseudoClass} instance for a given pseudo class name
> 90:      * It will not return null.

Since this is two sentences, you either need to restore the period after `name` or else add a semicolon there, and also remove the period after `null`. Either way, as long as you are add it, you might want to use code style for `null`.

modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 102:

> 100:     /**
> 101:      * Gets whether this {@code Selector} applies to the given {@code Styleable}.
> 102:      * It is the same as the {@link createMatch} method except it returns a boolean rather than a {@code Match}.

I see you changed this from `matches` to `createMatches`, since there is no `matches` method. However, I now wonder if this comment is correct in the first place. The `createMatch` method doesn't take a `Styleable` so it seems unlikely that it would be semantically equivalent to calling `createMatches`. Unless you can figure out what was meant by the original comment, it might best to just remove it.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From michaelstrau2 at gmail.com  Thu Jul 29 19:54:20 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 29 Jul 2021 21:54:20 +0200
Subject: Undecorated-interactive stage style
Message-ID: 

I propose to add StageStyle.UNDECORATED_INTERACTIVE as outlined in
this PR: https://github.com/openjdk/jfx/pull/594

The purpose of this style is to allow developers to provide custom
window decorations, but retain the window behaviors that would be lost
when using StageStyle.UNDECORATED.

I'm looking forward to any comments on this proposal.

From kevin.rushforth at oracle.com  Thu Jul 29 23:21:25 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 29 Jul 2021 16:21:25 -0700
Subject: JavaFX 17 is in Rampdown Phase Two (RDP2)
Message-ID: <23256e39-1762-bc3f-e1f4-e38a8644f631@oracle.com>

To: OpenJFX Developers

As a reminder, JavaFX 17 is now in Rampdown Phase Two (RDP2). [1]

P1-P2 bugs, and test or doc bugs of any priority, can be fixed during 
RDP2. Explicit approval is needed for bug fixes (except for doc and test 
fixes), and all enhancements to go in to the jfx17 branch. The bar for 
approving bug fixes is appropriately high at this point. We do not 
anticipate approving any more enhancements.

We will use the same rules for RDP2 that the JDK uses [2], with two 
modifications:

1. Approval is needed from one of the OpenJFX project leads (not the 
OpenJDK project lead)

2. Since we are not part of the JDK, we need to use labels that do not 
collide with the JDK 17 release. As an obvious choice, derived from the 
JBS fix version, we will use "openjfx17-fix-request", 
"openjfx17-fix-yes", "openjfx17-fix-no" and "openjfx17-fix-nmi", 
"openjfx17-enhancement-request", "openjfx17-enhancement-yes", 
"openjfx17-enhancement-no" and "openjfx17-enhancement-nmi" as 
corresponding labels.

Note that if a fix is approved to integrate into jfx17 (with the 
appropriate approval label added by a lead), then the PR should be 
targeted to the jfx17 branch. There is no need to also create a separate 
PR to integrate it into master -- we will continue to periodically sync 
jfx17 --> master for the duration of the openjfx17 release.

Now that we are in RDP2, the goal is to stabilize what is there, fixing 
bugs that are new in openjfx17. We need to be extremely careful about 
including anything that introduces risk.

IMPORTANT: Reviewers and Committers now have an extra responsibility to 
double-check the target branch of each PR that they review, integrate, 
or sponsor. By default a PR will be targeted to `master` which is the 
main development line (OpenJFX 18 as of today). This is usually what we 
want. A PR should be targeted to `jfx17` if, and only if, it is intended 
for OpenJFX 17 and meets the criteria for the current rampdown phase 
(we're in RDP2 as of today). Reviewers are advised to be extra cautious 
in approving potentially risky fixes targeted to `jfx17`. If there is a 
concern, then a reviewer can as part of the review indicate that the PR 
should be retargeted to `master` for 18. Reviewers also need to be extra 
careful when reviewing PRs targeted to jfx17 that it doesn't mistakenly 
contain any commits from the master branch. You'll be able to tell 
because the diffs will contain changes that are not part of the fix 
being reviewed. Such a PR will either need to be closed and redone, or 
it will need to be rebased and force-pushed.

Let me know if there are any questions.

-- Kevin

[1] 
https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-March/029487.html
[2] http://openjdk.java.net/jeps/3

From kcr at openjdk.java.net  Fri Jul 30 00:32:55 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 30 Jul 2021 00:32:55 GMT
Subject: RFR: Merge jfx17
Message-ID: <8kooxlCSzuKXLEIrZVeOW6WRjlrULJteaNw6guEc_Mo=.f869a58a-28d9-4ccf-9bb6-95a61c5bf758@github.com>

Merge `jfx17` branch into `master`.

-------------

Commit messages:
 - Merge jfx17
 - 8212088: Missing copyright notices for property files
 - 8271086: Block comments of form '/***' are treated as javadoc comments
 - 8240640: [macos] Wrong focus behaviour with multiple Alerts
 - 8271230: Remove obsolete test classes and data files from 3DViewer sample

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jfx&pr=596&range=00.0
 - jfx17: https://webrevs.openjdk.java.net/?repo=jfx&pr=596&range=00.1

Changes: https://git.openjdk.java.net/jfx/pull/596/files
  Stats: 9996 lines in 269 files changed: 1836 ins; 7167 del; 993 mod
  Patch: https://git.openjdk.java.net/jfx/pull/596.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/596/head:pull/596

PR: https://git.openjdk.java.net/jfx/pull/596

From kcr at openjdk.java.net  Fri Jul 30 00:45:53 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 30 Jul 2021 00:45:53 GMT
Subject: Integrated: Merge jfx17
In-Reply-To: <8kooxlCSzuKXLEIrZVeOW6WRjlrULJteaNw6guEc_Mo=.f869a58a-28d9-4ccf-9bb6-95a61c5bf758@github.com>
References: <8kooxlCSzuKXLEIrZVeOW6WRjlrULJteaNw6guEc_Mo=.f869a58a-28d9-4ccf-9bb6-95a61c5bf758@github.com>
Message-ID: 

On Fri, 30 Jul 2021 00:26:47 GMT, Kevin Rushforth  wrote:

> Merge `jfx17` branch into `master`.

This pull request has now been integrated.

Changeset: a283ba3c
Author:    Kevin Rushforth 
URL:       https://git.openjdk.java.net/jfx/commit/a283ba3c24befe9a359078855fe7d08e3bfafe6c
Stats:     9996 lines in 269 files changed: 1836 ins; 7167 del; 993 mod

Merge

-------------

PR: https://git.openjdk.java.net/jfx/pull/596

From kcr at openjdk.java.net  Fri Jul 30 00:45:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 30 Jul 2021 00:45:52 GMT
Subject: RFR: Merge jfx17 [v2]
In-Reply-To: <8kooxlCSzuKXLEIrZVeOW6WRjlrULJteaNw6guEc_Mo=.f869a58a-28d9-4ccf-9bb6-95a61c5bf758@github.com>
References: <8kooxlCSzuKXLEIrZVeOW6WRjlrULJteaNw6guEc_Mo=.f869a58a-28d9-4ccf-9bb6-95a61c5bf758@github.com>
Message-ID: 

> Merge `jfx17` branch into `master`.

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 18 additional commits since the last revision:

 - Merge jfx17
 - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's

   Reviewed-by: jvos, kcr
 - 8240506: TextFieldSkin/Behavior: misbehavior on switching skin

   Reviewed-by: mhanl, arapte
 - Merge
 - 8270839: Remove deprecated implementation methods from Scene

   Reviewed-by: arapte, aghaisas
 - 8269374: Menu inoperable after setting stage to second monitor

   Reviewed-by: kcr, arapte
 - Merge
 - 8270838: Remove deprecated protected access members from DateTimeStringConverter

   Reviewed-by: kcr, aghaisas
 - 8270479: WebKit 612.1 build fails with Visual Studio 2017

   Reviewed-by: arapte, sykora, jvos
 - 8188027: List/TableCell: must not fire event in startEdit if already editing

   Reviewed-by: aghaisas
 - ... and 8 more: https://git.openjdk.java.net/jfx/compare/0479c7f8...56fd54b7

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/596/files
  - new: https://git.openjdk.java.net/jfx/pull/596/files/56fd54b7..56fd54b7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=596&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=596&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/596.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/596/head:pull/596

PR: https://git.openjdk.java.net/jfx/pull/596

From almatvee at openjdk.java.net  Fri Jul 30 00:47:43 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 30 Jul 2021 00:47:43 GMT
Subject: RFR: 8242531: [macos] JavaFX OSXPlatform tries to load nonexistent
 libjfxmedia_qtkit
Message-ID: 

Removed code which loads nonexistent libjfxmedia_qtkit.

-------------

Commit messages:
 - 8242531: [macos] JavaFX OSXPlatform tries to load nonexistent libjfxmedia_qtkit

Changes: https://git.openjdk.java.net/jfx/pull/597/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=597&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242531
  Stats: 14 lines in 1 file changed: 0 ins; 10 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/597.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/597/head:pull/597

PR: https://git.openjdk.java.net/jfx/pull/597

From aghaisas at openjdk.java.net  Fri Jul 30 06:07:36 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 30 Jul 2021 06:07:36 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v5]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Jul 2021 17:41:50 GMT, Kevin Rushforth  wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8250590 - fix review comments
>
> modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 102:
> 
>> 100:     /**
>> 101:      * Gets whether this {@code Selector} applies to the given {@code Styleable}.
>> 102:      * It is the same as the {@link createMatch} method except it returns a boolean rather than a {@code Match}.
> 
> I see you changed this from `matches` to `createMatches`, since there is no `matches` method. However, I now wonder if this comment is correct in the first place. The `createMatch` method doesn't take a `Styleable` so it seems unlikely that it would be semantically equivalent to calling `createMatches`. Unless you can figure out what was meant by the original comment, it might best to just remove it.

It is out of place comment. I think, it is better to remove it.

-------------

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Fri Jul 30 06:23:59 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 30 Jul 2021 06:23:59 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v6]
In-Reply-To: 
References: 
Message-ID: 

> This PR corrects/adds missing documentation for classes in javafx.css package.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  8250590 - fix review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/589/files
  - new: https://git.openjdk.java.net/jfx/pull/589/files/642e73f1..64f31b77

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=589&range=04-05

  Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/589.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/589/head:pull/589

PR: https://git.openjdk.java.net/jfx/pull/589

From aghaisas at openjdk.java.net  Fri Jul 30 10:07:34 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 30 Jul 2021 10:07:34 GMT
Subject: [jfx17] RFR: 8271485: Javadoc "Method Summary" table is
 misaligned if overridden JDK method has {@inheritDoc} tag
In-Reply-To: 
References: 
Message-ID: 

On Thu, 29 Jul 2021 16:18:24 GMT, Kevin Rushforth  wrote:

> As noted in the JBS bug report, the javadoc-generated HTML table for a class is messed up if any method is overridden from a core JDK class and has the `{@inheritDoc}` tag. For example, the following taken from the [Background](https://github.com/openjdk/jfx/blob/jfx17/modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java#L622) class provokes this bug:
> 
> 
>     /**
>      * {@inheritDoc}
>      */
>     @Override public boolean equals(Object o) {
> 
> 
> The proposed fix is to stop generating javadocs for overridden methods with no spec change. This matches how the JDK docs have been generated since JDK 10. See [JDK-8157000](https://bugs.openjdk.java.net/browse/JDK-8157000). This is done by running `javadoc` with the `--override-methods=summary` option.
> 
> There is no useful information generated for such overridden methods regardless of whether or not they use the `{@inheritDoc}` tag, so this fix also addresses the problem of having methods with no description.
> 
> See the attached "before" and "after" images.
> 
> Before:
> 
> ![javadoc-before](https://user-images.githubusercontent.com/34689748/127527754-ae5c529a-8c49-47a2-b595-5e423f5c9c49.png)
> 
> After:
> 
> ![javadoc-after](https://user-images.githubusercontent.com/34689748/127527789-c97c4689-154f-4ed0-a4a1-5dfdfde0d9d2.png)

Marked as reviewed by aghaisas (Reviewer).

-------------

PR: https://git.openjdk.java.net/jfx/pull/593

From kcr at openjdk.java.net  Fri Jul 30 11:48:37 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 30 Jul 2021 11:48:37 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v6]
In-Reply-To: 
References: 

Message-ID: <6iUw9-_NYyovt_DsmdZ4SL0Lj4L6l6wU65vgiQ_3zx4=.c9723eaa-258c-41e4-b5cb-4651939fd001@github.com>

On Fri, 30 Jul 2021 06:23:59 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - fix review comments

Looks good!

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/589

From kevin.rushforth at oracle.com  Fri Jul 30 12:56:53 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 30 Jul 2021 05:56:53 -0700
Subject: Enhancements for JavaFX 18
Message-ID: 

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  Fri Jul 30 13:13:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 30 Jul 2021 13:13:33 GMT
Subject: RFR: 8242531: [macos] JavaFX OSXPlatform tries to load
 nonexistent libjfxmedia_qtkit
In-Reply-To: 
References: 
Message-ID: 

On Fri, 30 Jul 2021 00:42:30 GMT, Alexander Matveev  wrote:

> Removed code which loads nonexistent libjfxmedia_qtkit.

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.java.net/jfx/pull/597

From kevin.rushforth at oracle.com  Fri Jul 30 13:41:05 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 30 Jul 2021 06:41:05 -0700
Subject: Undecorated-interactive stage style
In-Reply-To: 
References: 
Message-ID: 

This looks interesting and useful. I'd like to hear from other 
developers as well.

A few comments:

1. We might want to consider whether there is a better name (nothing 
comes to mind at the moment)
2. This will almost certainly need to be a ConditionalFeature (since it 
might not be supportable on certain platforms, such as embedded platforms)
3. We will need an implementation on all three desktop platforms: 
Windows, macOS, Linux
4. You will need to add tests (at least manual if automated tests prove 
to be infeasible)

-- Kevin

On 7/29/2021 12:54 PM, Michael Strau? wrote:
> I propose to add StageStyle.UNDECORATED_INTERACTIVE as outlined in
> this PR: https://github.com/openjdk/jfx/pull/594
>
> The purpose of this style is to allow developers to provide custom
> window decorations, but retain the window behaviors that would be lost
> when using StageStyle.UNDECORATED.
>
> I'm looking forward to any comments on this proposal.

From wookey.dean at gmail.com  Fri Jul 30 14:01:05 2021
From: wookey.dean at gmail.com (Dean Wookey)
Date: Fri, 30 Jul 2021 16:01:05 +0200
Subject: Undecorated-interactive stage style
In-Reply-To: 
References: 

Message-ID: 

We would be very interested in this. We've tried to implement some of these
native behaviours ourselves, but there are plenty of holes and we only
support Windows. There are also some bugs which could potentially be
addressed by this, for example
https://bugs.openjdk.java.net/browse/JDK-8133330.

In my research I came across this:
https://github.com/rossy/borderless-window which addressed all the Windows
issues I was coming across at once. Maybe it's useful.

Dean

On Fri, Jul 30, 2021 at 3:42 PM Kevin Rushforth 
wrote:

> This looks interesting and useful. I'd like to hear from other
> developers as well.
>
> A few comments:
>
> 1. We might want to consider whether there is a better name (nothing
> comes to mind at the moment)
> 2. This will almost certainly need to be a ConditionalFeature (since it
> might not be supportable on certain platforms, such as embedded platforms)
> 3. We will need an implementation on all three desktop platforms:
> Windows, macOS, Linux
> 4. You will need to add tests (at least manual if automated tests prove
> to be infeasible)
>
> -- Kevin
>
>
> On 7/29/2021 12:54 PM, Michael Strau? wrote:
> > I propose to add StageStyle.UNDECORATED_INTERACTIVE as outlined in
> > this PR: https://github.com/openjdk/jfx/pull/594
> >
> > The purpose of this style is to allow developers to provide custom
> > window decorations, but retain the window behaviors that would be lost
> > when using StageStyle.UNDECORATED.
> >
> > I'm looking forward to any comments on this proposal.
>
>

From michaelstrau2 at gmail.com  Fri Jul 30 14:18:25 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 30 Jul 2021 16:18:25 +0200
Subject: Undecorated-interactive stage style
In-Reply-To: 
References: 

Message-ID: 

2. From an implementation perspective, this doesn't need to be
supported explicitly by a platform.
For the move and resize behaviors, it uses existing
com.sun.glass.ui.Window APIs like setSize and setPosition.
I would imagine that these operations are no-ops for platforms that do
not support floating windows?

3. In general, move and resize works on all platforms via the new
`MoveResizeHelper` class (except for Windows, which uses a different
mechanism).
On Windows, the experience is improved by handling the WM_NCHITTEST
message, which enables support for advanced behaviors like Aero Snap.
Similarly, we can improve the experience on other platforms by
supporting more of their native features:
For example, on macOS, we could query the "Double-click a window's
title bar to zoom" system preference and maximize the window when we
detect a double click.
However, I do not intend to implement more specialized behavior for
macOS or Linux at this point, and leave that as a future optimization.

Am Fr., 30. Juli 2021 um 15:41 Uhr schrieb Kevin Rushforth
:
>
> This looks interesting and useful. I'd like to hear from other
> developers as well.
>
> A few comments:
>
> 1. We might want to consider whether there is a better name (nothing
> comes to mind at the moment)
> 2. This will almost certainly need to be a ConditionalFeature (since it
> might not be supportable on certain platforms, such as embedded platforms)
> 3. We will need an implementation on all three desktop platforms:
> Windows, macOS, Linux
> 4. You will need to add tests (at least manual if automated tests prove
> to be infeasible)
>
> -- Kevin
>

From michaelstrau2 at gmail.com  Fri Jul 30 14:25:48 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Fri, 30 Jul 2021 16:25:48 +0200
Subject: Undecorated-interactive stage style
In-Reply-To: 
References: 

Message-ID: 

It is true that a window with the UNDECORATED style will maximize to
fill the entire screen.
A window with the UNDECORATED_INTERACTIVE style is actually a regular
window where the client area has been extended to include the
non-client areas as well.
As a consequence of this, the window behaves like a regular window,
and maximizes to fill the screen's work area (which excludes the task
bar).

Am Fr., 30. Juli 2021 um 16:01 Uhr schrieb Dean Wookey :
>
> We would be very interested in this. We've tried to implement some of these native behaviours ourselves, but there are plenty of holes and we only support Windows. There are also some bugs which could potentially be addressed by this, for example https://bugs.openjdk.java.net/browse/JDK-8133330.
>
> In my research I came across this: https://github.com/rossy/borderless-window which addressed all the Windows issues I was coming across at once. Maybe it's useful.
>
> Dean
>

From pbansal at openjdk.java.net  Fri Jul 30 17:55:43 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 30 Jul 2021 17:55:43 GMT
Subject: [jfx17] RFR: 8250590: Classes and methods in the javafx.css
 package are missing documentation [v6]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 30 Jul 2021 06:23:59 GMT, Ajit Ghaisas  wrote:

>> This PR corrects/adds missing documentation for classes in javafx.css package.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8250590 - fix review comments

Looks good to me as well

-------------

Marked as reviewed by pbansal (Committer).

PR: https://git.openjdk.java.net/jfx/pull/589

From almatvee at openjdk.java.net  Fri Jul 30 22:08:32 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 30 Jul 2021 22:08:32 GMT
Subject: Integrated: 8242531: [macos] JavaFX OSXPlatform tries to load
 nonexistent libjfxmedia_qtkit
In-Reply-To: 
References: 
Message-ID: 

On Fri, 30 Jul 2021 00:42:30 GMT, Alexander Matveev  wrote:

> Removed code which loads nonexistent libjfxmedia_qtkit.

This pull request has now been integrated.

Changeset: ba61a173
Author:    Alexander Matveev 
URL:       https://git.openjdk.java.net/jfx/commit/ba61a17307d48d373fd8faa169ed16821e81c0fd
Stats:     14 lines in 1 file changed: 0 ins; 10 del; 4 mod

8242531: [macos] JavaFX OSXPlatform tries to load nonexistent libjfxmedia_qtkit

Reviewed-by: kcr

-------------

PR: https://git.openjdk.java.net/jfx/pull/597