On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote:
> This is an alternative solution to the PR:
> https://github.com/openjdk/jfx/pull/1310.
>
> This solution is based on the invariant that if a node is marked as dirty,
> all ancestors must also be marked as dirty and that if
On Thu, 4 Jul 2024 07:51:00 GMT, Ambarish Rapte wrote:
>> Yes, the test with your suggestion also works under Windows. Thank you,
>> @arapte.
>
>Thanks for verifying. In that case, let's remove the waitForRenderer() method
>that was added to solve the test failure on Mac but is not required any
even if they are
> partially covered, which led to the error in the version before the PR. The
> test can be started with:
> ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests
> NGNodeDirtyFlagTest``
eduardsdv has updated the pull request incrementally with one a
On Wed, 3 Jul 2024 20:26:35 GMT, Ambarish Rapte wrote:
>> eduardsdv has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - JDK-8322619: Move to the test.robot.com.sun.prism package and use
>> TOLERANCE w
even if they are
> partially covered, which led to the error in the version before the PR. The
> test can be started with:
> ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests
> NGNodeDirtyFlagTest``
eduardsdv has updated the pull request incrementally with one additi
On Wed, 3 Jul 2024 14:27:19 GMT, Ambarish Rapte wrote:
>> eduardsdv has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains five
On Wed, 3 Jul 2024 14:55:16 GMT, Kevin Rushforth wrote:
>> eduardsdv has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains five
On Wed, 3 Jul 2024 15:05:50 GMT, Kevin Rushforth wrote:
>> tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java
>> line 68:
>>
>>> 66: root = new StackPane();
>>> 67: primaryStage.setScene(new Scene(root, 500, 400));
>>> 68:
>>
>> Please add `pri
On Mon, 1 Jul 2024 18:24:36 GMT, Ambarish Rapte wrote:
>> eduardsdv has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains five
even if they are
> partially covered, which led to the error in the version before the PR. The
> test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests
> NGNodeDirtyFlagTest``
eduardsdv has updated the pull request incrementally with four additional
commits since th
On Fri, 28 Jun 2024 10:25:58 GMT, eduardsdv wrote:
>> This is an alternative solution to the PR:
>> https://github.com/openjdk/jfx/pull/1310.
>>
>> This solution is based on the invariant that if a node is marked as dirty,
>> all ancestors must also be marked as
even if they are
> partially covered, which led to the error in the version before the PR. The
> test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests
> NGNodeDirtyFlagTest``
eduardsdv has updated the pull request with a new target base due to a merge or
a rebase.
On Sat, 18 May 2024 14:11:36 GMT, Kevin Rushforth wrote:
>>> At a minimum I think the tests that are part of this PR should be included
>>> in FX whichever fix ends up being integrated.
>>
>> The test has already been added to both PRs.
>>
>>> I'm only wondering if the code in ``paintImpl`` sh
even if they are
> partially covered, which led to the error in the version before the PR. The
> test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests
> NGNodeDirtyFlagTest``
eduardsdv has updated the pull request incrementally with three additional
commits sinc
On Fri, 28 Jun 2024 05:17:41 GMT, Ambarish Rapte wrote:
>> eduardsdv has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - JDK-8322619: Fix waiting for the stage
>> - JDK-8322619: Improve output message in
On Fri, 3 May 2024 10:23:27 GMT, Florian Kirmaier wrote:
>> In some situations, a part of the SG is no longer rendered.
>> I created a test program that showcases this problem.
>>
>> Explanation:
>>
>> This can happen, when a part of the SG, is covered by another Node.
>> In this part, one node
On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote:
> This is an alternative solution to the PR:
> https://github.com/openjdk/jfx/pull/1310.
>
> This solution is based on the invariant that if a node is marked as dirty,
> all ancestors must also be marked as dirty and that if
On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote:
> This is an alternative solution to the PR:
> https://github.com/openjdk/jfx/pull/1310.
>
> This solution is based on the invariant that if a node is marked as dirty,
> all ancestors must also be marked as dirty and that if
On Fri, 3 May 2024 10:23:27 GMT, Florian Kirmaier wrote:
>> In some situations, a part of the SG is no longer rendered.
>> I created a test program that showcases this problem.
>>
>> Explanation:
>>
>> This can happen, when a part of the SG, is covered by another Node.
>> In this part, one node
On Wed, 22 May 2024 06:39:18 GMT, Johan Vos wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
>> line 1918:
>>
>>> 1916: * Returns the length of the viewport portion of the {@code
>>> VirtualFlow} as computed during the layout pass.
>>> 1917:
On Fri, 17 May 2024 13:21:36 GMT, John Hendrikx wrote:
> At a minimum I think the tests that are part of this PR should be included in
> FX whichever fix ends up being integrated.
The test has already been added to both PRs.
> I'm only wondering if the code in ``paintImpl`` should always clear
On Thu, 16 May 2024 19:36:00 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8323511: Adjust javadoc of the getViewportLength()
>
> modules/javafx.controls/src/main/java/javafx/scene/co
On Fri, 17 May 2024 07:23:45 GMT, Florian Kirmaier
wrote:
>> As seen in the unit test of the PR, when we click on the area above/below
>> the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI always jumps to the top. In
On Thu, 9 May 2024 14:31:56 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8323511: Mage getViewportLength() public and use it instead of
>> getBlockIncrement()
>
> modules/javafx.con
would like to see it merged!
> I've worked on this topic together with @eduardsdv ,
> So consider his response to be my answer to the question.
I ask @FlorianKirmaier to create a CSR ticket.
-
PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2102809583
On Thu, 9 May 2024 09:04:54 GMT, Johan Vos wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8323511: Use viewport length as block increment
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin
On Mon, 6 May 2024 18:05:06 GMT, Andy Goryachev wrote:
>> I agree with you, at least with scrolling when clicking on the scrollbar
>> track.
>> I would like to change the amount of scroll pixels to the viewport length.
>>
>> PageUp/PageDown not only scrolls the view, but also moves the
>> sel
On Tue, 7 May 2024 09:39:23 GMT, Florian Kirmaier wrote:
>> As seen in the unit test of the PR, when we click on the area above/below
>> the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI always jumps to the top. In
On Mon, 6 May 2024 18:52:10 GMT, Andy Goryachev wrote:
> > What about the `GridView`
>
> What's a GridView? ControlsFX is not a part of OpenJFX...
Oh, sorry, my mistake. You are right. It is part of the ControlsFX.
-
PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2
On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev wrote:
>> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to
>>
>> - ListView
>> - TreeView
>> - TableView
>> - TreeTableView
>>
>> to support keyboard-only horizontal scrolling. The main reason for the
>> change is to improv
On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev wrote:
>> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to
>>
>> - ListView
>> - TreeView
>> - TableView
>> - TreeTableView
>>
>> to support keyboard-only horizontal scrolling. The main reason for the
>> change is to improv
On Mon, 6 May 2024 08:49:27 GMT, Florian Kirmaier wrote:
>> As seen in the unit test of the PR, when we click on the area above/below
>> the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI always jumps to the top. In
On Mon, 6 May 2024 08:49:27 GMT, Florian Kirmaier wrote:
>> As seen in the unit test of the PR, when we click on the area above/below
>> the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI always jumps to the top. In
On Mon, 6 May 2024 16:35:14 GMT, Andy Goryachev wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8323511: Fix scrolling when clicking the scrollbar track when only one
>> cell is visible
>
> modules/javafx.
On Mon, 6 May 2024 16:34:22 GMT, Andy Goryachev wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8323511: Fix scrolling when clicking the scrollbar track when only one
>> cell is visible
>
> modules/javafx.
This is an alternative solution to the PR:
https://github.com/openjdk/jfx/pull/1310.
This solution is based on the invariant that if a node is marked as dirty, all
ancestors must also be marked as dirty and that if an ancestor is marked as
clean, all descendants must also be marked as clean.
T
On Fri, 3 May 2024 10:23:27 GMT, Florian Kirmaier wrote:
>> In some situations, a part of the SG is no longer rendered.
>> I created a test program that showcases this problem.
>>
>> Explanation:
>>
>> This can happen, when a part of the SG, is covered by another Node.
>> In this part, one node
On Mon, 6 May 2024 08:49:27 GMT, Florian Kirmaier wrote:
>> As seen in the unit test of the PR, when we click on the area above/below
>> the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI always jumps to the top. In
On Wed, 13 Mar 2024 09:13:20 GMT, Florian Kirmaier
wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> reverted accidental change in the .idea folder
>
> *push*
> It's still a important bug.
> If someone can guide
On Mon, 29 Apr 2024 09:30:18 GMT, Florian Kirmaier
wrote:
>> In some situations, a part of the SG is no longer rendered.
>> I created a test program that showcases this problem.
>>
>> Explanation:
>>
>> This can happen, when a part of the SG, is covered by another Node.
>> In this part, one no
On Tue, 23 Jan 2024 11:51:52 GMT, Florian Kirmaier
wrote:
>> In some situations, a part of the SG is no longer rendered.
>> I created a test program that showcases this problem.
>>
>> Explanation:
>>
>> This can happen, when a part of the SG, is covered by another Node.
>> In this part, one no
On Thu, 28 Mar 2024 11:31:14 GMT, eduardsdv wrote:
> This change fixes the calculation of which nodes go to the toolbar and which
> go to the overflow menu.
> It is now determined before the nodes are removed from the scene graph.
> This is important because the values
On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv wrote:
>> This change fixes the calculation of which nodes go to the toolbar and which
>> go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important becaus
On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv wrote:
>> This change fixes the calculation of which nodes go to the toolbar and which
>> go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important becaus
On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv wrote:
>> This change fixes the calculation of which nodes go to the toolbar and which
>> go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important becaus
On Tue, 16 Apr 2024 16:08:12 GMT, Andy Goryachev wrote:
>> The ``Node.getPseudoClassStates()`` returns an unmodifiable collection. The
>> bindings would not work. Therefore we need to use a listener and change the
>> pseudo-class-state by using the ``Node.pseudoClassStateChanged(PseudoClass,
>
On Tue, 16 Apr 2024 15:58:21 GMT, Andy Goryachev wrote:
>> ~~Done. See
>> [92921e3](https://github.com/openjdk/jfx/pull/1434/commits/92921e36987e3cd1cfe78c17b464547aa73d241e)~~
>
> line 575 still uses a listener instead of
> Bindings.bindContent(**Set,ObservableSet**)
The ``Node.getPseudoClass
On Mon, 15 Apr 2024 15:49:04 GMT, Andy Goryachev wrote:
>> eduardsdv has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8328577: Refactor and fix binding of style related properties
>
> modules/javafx
On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv wrote:
>> This change fixes the calculation of which nodes go to the toolbar and which
>> go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important becaus
On Mon, 15 Apr 2024 15:24:06 GMT, Andy Goryachev wrote:
>> eduardsdv has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - JDK-8328577: Update comment
>> - JDK-8328577: Bind style related properties
>
&
On Mon, 15 Apr 2024 15:10:42 GMT, Andy Goryachev wrote:
>> eduardsdv has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - JDK-8328577: Update comment
>> - JDK-8328577: Bind style related properties
>
&
` may depend on whether the node
> is added to the scene graph.
>
> Furthermore I corrected the ``hasOveflow`` value passed to the
> ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
eduardsdv has updated the pull request incrementally with one additional comm
On Mon, 15 Apr 2024 12:28:55 GMT, eduardsdv wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java
>> line 783:
>>
>>> 781: CustomMenuItem customMenuItem = new
>>> CustomMenuItem(node);
>>> 7
On Fri, 12 Apr 2024 18:11:14 GMT, Andy Goryachev wrote:
>> eduardsdv has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8328577: Collect overflowed items in a shadow (overflowBox) pane
>
> modules/javafx
` may depend on whether the node
> is added to the scene graph.
>
> Furthermore I corrected the ``hasOveflow`` value passed to the
> ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
eduardsdv has updated the pull request incrementally with two additional
comm
On Fri, 12 Apr 2024 18:15:41 GMT, Andy Goryachev wrote:
>> eduardsdv has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8328577: Collect overflowed items in a shadow (overflowBox) pane
>
> modules/javafx
On Fri, 12 Apr 2024 15:21:14 GMT, eduardsdv wrote:
>> This change fixes the calculation of which nodes go to the toolbar and which
>> go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important becaus
` may depend on whether the node
> is added to the scene graph.
>
> Furthermore I corrected the ``hasOveflow`` value passed to the
> ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
eduardsdv has updated the pull request incrementally with one additional comm
On Mon, 15 Jan 2024 08:31:59 GMT, Florian Kirmaier
wrote:
>> As seen in the unit test of the PR, when we click on the area above/below
>> the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI always jumps to the top. In
` may depend on whether the node
> is added to the scene graph.
>
> Furthermore I corrected the ``hasOveflow`` value passed to the
> ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
eduardsdv has updated the pull request incrementally with one additional comm
On Thu, 28 Mar 2024 18:53:00 GMT, eduardsdv wrote:
>> This change fixes the calculation of which nodes go to the toolbar and which
>> go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important becaus
` may depend on whether the node
> is added to the scene graph.
>
> Furthermore I corrected the ``hasOveflow`` value passed to the
> ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
eduardsdv has updated the pull request incrementally with one additional comm
This change fixes the calculation of which nodes go to the toolbar and which go
to the overflow menu.
It is now determined before the nodes are removed from the scene graph.
This is important because the values returned by
``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the n
On Mon, 15 Jan 2024 08:31:59 GMT, Florian Kirmaier
wrote:
>> As seen in the unit test of the PR, when we click on the area above/below
>> the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI always jumps to the top. In
On Tue, 19 Mar 2024 12:02:14 GMT, Marius Hanl wrote:
> But is it possible to scroll to an index that is negative?
Yes, both the negative value (``-1``) and the positive value, which is greater
than the items count (to be precise ``last item index + 1``), are possible and
indicate the direction
On Sun, 17 Mar 2024 18:07:35 GMT, Johan Vos wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8323511
>> reverted accidental indentation chang
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/
On Mon, 5 Feb 2024 09:53:23 GMT, Marius Hanl wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8323511
>> reverted accidental indentation chang
>
> modules/javafx.controls/src/main/java/javafx/scene/control
On Fri, 14 Oct 2022 15:45:10 GMT, eduardsdv wrote:
> This fixes a race condition between application and 'Print Job Thread'
> threads when printing.
>
> The race condition occurs when application thread calls `endJob()`, which in
> effect sets the `jobDone` flag to tr
On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote:
> Create sources.jars and attach they to the publish task, so that they can be
> uploaded to the (e.g. maven) repository automatically.
Thanks for the clarification and I totally comprehend your point of view. The
build file is really b
On Thu, 1 Dec 2022 10:12:26 GMT, eduardsdv wrote:
>> This fixes a race condition between application and 'Print Job Thread'
>> threads when printing.
>>
>> The race condition occurs when application thread calls `endJob()`, which in
>> effect sets the
On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote:
> Create sources.jars and attach they to the publish task, so that they can be
> uploaded to the (e.g. maven) repository automatically.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.o
On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote:
> Create sources.jars and attach they to the publish task, so that they can be
> uploaded to the (e.g. maven) repository automatically.
It seems that no one needs it, so I am closing this PR.
-
PR: https://git.openjdk.o
lso that there is no
> other page to be printed.
> It was also needed to introduce a new flag 'jobCanceled', to skip the page if
> the printing was canceled by 'cancelJob()'.
eduardsdv has updated the pull request incrementally with three additional
commits since the la
On Fri, 28 Oct 2022 13:54:40 GMT, eduardsdv wrote:
>> This fixes a race condition between application and 'Print Job Thread'
>> threads when printing.
>>
>> The race condition occurs when application thread calls `endJob()`, which in
>> effect sets the
On Fri, 28 Oct 2022 13:54:40 GMT, eduardsdv wrote:
>> This fixes a race condition between application and 'Print Job Thread'
>> threads when printing.
>>
>> The race condition occurs when application thread calls `endJob()`, which in
>> effect sets the
lso that there is no
> other page to be printed.
> It was also needed to introduce a new flag 'jobCanceled', to skip the page if
> the printing was canceled by 'cancelJob()'.
eduardsdv has updated the pull request incrementally with two additional
commits since the
On Mon, 17 Oct 2022 07:12:00 GMT, eduardsdv wrote:
>> This fixes a race condition between application and 'Print Job Thread'
>> threads when printing.
>>
>> The race condition occurs when application thread calls `endJob()`, which in
>> effect sets the
On Mon, 17 Oct 2022 07:12:00 GMT, eduardsdv wrote:
>> This fixes a race condition between application and 'Print Job Thread'
>> threads when printing.
>>
>> The race condition occurs when application thread calls `endJob()`, which in
>> effect sets the
lso that there is no
> other page to be printed.
> It was also needed to introduce a new flag 'jobCanceled', to skip the page if
> the printing was canceled by 'cancelJob()'.
eduardsdv has updated the pull request incrementally with one additional commit
since the
This fixes a race condition between application and 'Print Job Thread' threads
when printing.
The race condition occurs when application thread calls `endJob()`, which in
effect sets the `jobDone` flag to true,
and when the 'Print Job Thread' thread was in the `synchronized` block in
`waitForNe
80 matches
Mail list logo
