Vote: YES
Regards,
Ajit
> On 23-Oct-2020, at 8:08 PM, Kevin Rushforth
> wrote:
>
> I hereby nominate Pankaj Bansal [1] to OpenJFX Committer.
>
> Pankaj is a member of Java client team at Oracle, who has contributed 11
> commits [2] to OpenJFX.
>
> Votes are due by November 6, 2020.
>
> Onl
On Tue, 27 Oct 2020 00:03:18 GMT, Kevin Rushforth wrote:
>> As discussed in the [JBS
>> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
>> already snapped value (either intentionally or by mistake), the result
>> should be the same, otherwise we'll be jumping unnece
On Fri, 23 Oct 2020 08:32:59 GMT, Jose Pereda wrote:
> As discussed in the [JBS
> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
> already snapped value (either intentionally or by mistake), the result
> should be the same, otherwise we'll be jumping unnecessary fr
Vote: YES
-Original Message-
From: Kevin Rushforth
Sent: Friday, October 23, 2020 8:08 PM
To: openjfx-dev@openjdk.java.net
Subject: CFV: New OpenJFX Committer: Pankaj Bansal
I hereby nominate Pankaj Bansal [1] to OpenJFX Committer.
Pankaj is a member of Java client team at Oracle, who
On Tue, 27 Oct 2020 05:32:47 GMT, Ajit Ghaisas wrote:
>> modules/javafx.controls/src/test/java/test/javafx/scene/control/ButtonTest.java
>> line 425:
>>
>>> 423:
>>> 424: mouse.dispose();
>>> 425: }
>>
>> just curious: do we have to dispose the mouseFirer? If so, that pattern
>>
On Tue, 27 Oct 2020 05:41:02 GMT, Ajit Ghaisas wrote:
>> modules/javafx.controls/src/test/java/test/javafx/scene/control/ComboBoxTest.java
>> line 658:
>>
>>> 656: StageLoader sl = new StageLoader(comboBox);
>>> 657:
>>> 658:
>>
>> good catch :) But wouldn't show the stage have the s
On Tue, 27 Oct 2020 10:16:19 GMT, Jeanette Winzenburg
wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update JBS reference in RegionTest
>
> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/RegionTest
> As discussed in the [JBS
> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
> already snapped value (either intentionally or by mistake), the result
> should be the same, otherwise we'll be jumping unnecessary from a valid pixel
> to another pixel.
>
> This PR prov
On Tue, 27 Oct 2020 10:18:26 GMT, Jeanette Winzenburg
wrote:
>> Looks good.
>>
>> I can confirm that this fixes the problem of `snapSizeXY(snapSizeXY(val)) !=
>> snapSizeXY(val)` and that it fixes the test case from
>> [JDK-8199592](https://bugs.openjdk.java.net/browse/JDK-8199592) when
>> `
On Tue, 27 Oct 2020 10:23:39 GMT, Jeanette Winzenburg
wrote:
>> Hmm.. very good point. I believe, we should use dispose mechanism whenever
>> available for a readable cleanup. Both classes MouseEventFirer & StageLoader
>> provide dispose method and the user of these classes should use it.
>> N
On Tue, 27 Oct 2020 10:38:34 GMT, Jose Pereda wrote:
>> As discussed in the [JBS
>> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
>> already snapped value (either intentionally or by mistake), the result
>> should be the same, otherwise we'll be jumping unnecessar
On Tue, 27 Oct 2020 10:39:42 GMT, Jose Pereda wrote:
>
>
> @kleopatra That's a good question.
>
> I already saw it, but given it has private/package private access in a public
> class, simply trying to test it would imply creating a public access to
> snapPortionXX.
> I guess that is out of
On Tue, 27 Oct 2020 10:50:26 GMT, Jeanette Winzenburg
wrote:
>> @kleopatra That's a good question.
>>
>> I already saw it, but given it has private/package private access in a
>> public class, simply trying to test it would imply creating a public access
>> to snapPortionXX.
>> I guess that
On Tue, 27 Oct 2020 10:44:00 GMT, Johan Vos wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update JBS reference in RegionTest
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line
> 303:
>
On Tue, 27 Oct 2020 10:41:17 GMT, Jeanette Winzenburg
wrote:
>> makes sense :)
>
> just looked at MouseEventFirer (a bit late, sry ;): all it does is to dispose
> the Stageloader it created (if it received a bare node) - so if we add a node
> to a stage and/or wrap it into our own loader, we d
> This is a test fix.
>
> Root cause:
> - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on to
> the stage and shows it before firing mouse event
> - For ComboBoxTest - adding ComboBox to a Stage, not showing the Stage but
> trying to show the ComboBox
>
>
> Fix :
> - Fo
On Tue, 27 Oct 2020 11:30:23 GMT, Ajit Ghaisas wrote:
>> just looked at MouseEventFirer (a bit late, sry ;): all it does is to
>> dispose the Stageloader it created (if it received a bare node) - so if we
>> add a node to a stage and/or wrap it into our own loader, we don't really
>> need to d
On Tue, 27 Oct 2020 10:31:48 GMT, Jeanette Winzenburg
wrote:
>> stage.show() has the same effect of fixing the bug. In fact, I fixed it
>> initially with exact this fix.
>>
>> When I looked at the other tests in ComboBoxTest class, I saw that there is
>> a pattern of creating a Stage, creatin
On Tue, 27 Oct 2020 11:37:40 GMT, Jeanette Winzenburg
wrote:
>> If we use our own loader - we would need to dispose that as well :)
>>
>> Also, I found approach (1) of using reference at test class level and
>> cleaning it up in cleanup method after the test is more suitable as in
>> ButtonTe
On Tue, 27 Oct 2020 11:35:28 GMT, Ajit Ghaisas wrote:
>> This is a test fix.
>>
>> Root cause:
>> - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on
>> to the stage and shows it before firing mouse event
>> - For ComboBoxTest - adding ComboBox to a Stage, not showing the
> When connecting via Remote Desktop to a Windows 10 machine ans starting a
> JavaFX application, the D3D pipeline is used successfully.
> After closing the the Remote Desktop session and reconnecting, the D3D
> requests fail with an D3DERR_DEVICEREMOVED HResult, and the application
> contents
On Tue, 27 Oct 2020 11:57:03 GMT, Ajit Ghaisas wrote:
>> thanks!
>>
>> Wondering as to when/why Stageloader might be a misfit? I completely gave up
>> on using it a while ago, so don't really remember *cough
>
> It is not that StageLoader is bad as such. By misfit - I meant - error prone
> to
> As discussed in the [JBS
> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
> already snapped value (either intentionally or by mistake), the result
> should be the same, otherwise we'll be jumping unnecessary from a valid pixel
> to another pixel.
>
> This PR prov
> As discussed in the [JBS
> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
> already snapped value (either intentionally or by mistake), the result
> should be the same, otherwise we'll be jumping unnecessary from a valid pixel
> to another pixel.
>
> This PR prov
> As discussed in the [JBS
> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
> already snapped value (either intentionally or by mistake), the result
> should be the same, otherwise we'll be jumping unnecessary from a valid pixel
> to another pixel.
>
> This PR prov
On Mon, 26 Oct 2020 08:29:14 GMT, Robin Westberg wrote:
>> The jdk workflow is split into a build job and multiple test jobs (since it
>> takes so long they need the parallelism when running the tests). It's more
>> complicated that way, since you have to feed the results of the build job
>> i
On Tue, 27 Oct 2020 17:39:08 GMT, Kevin Rushforth wrote:
>>> I noticed this in the openjdk/mobile repository as well, and that looks
>>> great. In that repository, there seems to be a different configuration, as
>>> there is a line for "build" and a line for "test/tier 1" ( e.g.
>>> [openjdk/m
On Mon, 26 Oct 2020 22:49:41 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8244297
>> Added some more whitespaces based on review
>
> modules/javafx.base/src/test/java/test/util/mem
On Tue, 27 Oct 2020 19:24:35 GMT, Florian Kirmaier
wrote:
>> modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java line
>> 150:
>>
>>> 148: public static boolean checkNotCollectable(WeakReference
>>> weakReference) {
>>> 149: createGarbage();
>>> 150: System
On Tue, 27 Oct 2020 12:56:28 GMT, Jose Pereda wrote:
>> As discussed in the [JBS
>> issue](https://bugs.openjdk.java.net/browse/JDK-8199592), when snapping an
>> already snapped value (either intentionally or by mistake), the result
>> should be the same, otherwise we'll be jumping unnecessar
On Tue, 27 Oct 2020 11:35:28 GMT, Ajit Ghaisas wrote:
>> This is a test fix.
>>
>> Root cause:
>> - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on
>> to the stage and shows it before firing mouse event
>> - For ComboBoxTest - adding ComboBox to a Stage, not showing the
This test is somewhat unstable on Windows. Even after the test timeout was
increased to 25 seconds, it still times out on some Windows machines.
The proposed fix is to mark this test unstable on Windows so our nightly build
will not execute it and get frequent failures. It can still be run by pa
On Fri, 23 Oct 2020 11:35:50 GMT, Ajit Ghaisas wrote:
> This is a test fix.
>
> Root cause:
> - For ButtonTest - Incorrect use of MouseEventFirer - which puts Button on to
> the stage and shows it before firing mouse event
> - For ComboBoxTest - adding ComboBox to a Stage, not showing the Stage
33 matches
Mail list logo
