Btw, you can find the JavaFX 22+5 build here:
https://jdk.java.net/javafx22/
-- Kevin
On 8/18/2023 4:17 PM, Kevin Rushforth wrote:
As a heads-up for app developers who use JavaFX animation (including
Animation, along with any subclasses, and AnimationTimer), a change
went into the JavaFX
As a heads-up for app developers who use JavaFX animation (including
Animation, along with any subclasses, and AnimationTimer), a change went
into the JavaFX 22+5 build to enforce that the play, pause, and stop
methods must be called on the JavaFX Application thread. Applications
should have
On Fri, 18 Aug 2023 22:53:42 GMT, Kevin Rushforth wrote:
> Um, "classpath"?
The problem I was referring to is how to enumerate all descendants of Control
in javafx.* hierarchy, and I don't have a good solution. So, no change in the
unit test is being planned, and all newly developed controls
On Fri, 18 Aug 2023 22:17:15 GMT, Andy Goryachev wrote:
>> In the Control hierarchy, all property accessor methods must be declared
>> `final`.
>>
>> Added a test to check for missing `final` keyword and added the said keyword
>> where required.
>
> Andy Goryachev has updated the pull request
On Fri, 18 Aug 2023 22:42:22 GMT, Andy Goryachev wrote:
> > (unless we are also willing to create a new shared interface that Node,
> > MenuItem, and Toggle all inherit)
>
> that would be a clean(er) design, at the expense of slight runtime overhead
> traversing the interface table. could
On Fri, 18 Aug 2023 22:32:12 GMT, Kevin Rushforth wrote:
> (unless we are also willing to create a new shared interface that Node,
> MenuItem, and Toggle all inherit)
that would be a clean(er) design, at the expense of slight runtime overhead
traversing the interface table.
could there be any
On Fri, 18 Aug 2023 22:32:58 GMT, Kevin Rushforth wrote:
> And thanks for adding a test.
I feel the test can be improved by collecting the classes automatically, so as
to catch possible issues when new controls are added (it'll be a full classpath
scan though). While the scan should be
On Fri, 18 Aug 2023 22:17:15 GMT, Andy Goryachev wrote:
>> In the Control hierarchy, all property accessor methods must be declared
>> `final`.
>>
>> Added a test to check for missing `final` keyword and added the said keyword
>> where required.
>
> Andy Goryachev has updated the pull request
On Fri, 18 Aug 2023 22:17:15 GMT, Andy Goryachev wrote:
>> In the Control hierarchy, all property accessor methods must be declared
>> `final`.
>>
>> Added a test to check for missing `final` keyword and added the said keyword
>> where required.
>
> Andy Goryachev has updated the pull request
> Adding new
> `boolean hasProperties()`
> method to MenuItem and Toggle only.
>
> This change requires CSR.
Andy Goryachev has updated the pull request incrementally with one additional
commit since the last revision:
review comments
-
Changes:
- all:
On Fri, 18 Aug 2023 17:06:57 GMT, Andy Goryachev wrote:
> Adding new
> `boolean hasProperties()`
> method to MenuItem and Toggle only.
>
> This change requires CSR.
Hmm. I also think might not want to put it in `Toggle` (unless we are also
willing to create a new shared interface that Node,
On Fri, 18 Aug 2023 22:08:35 GMT, John Hendrikx wrote:
>> Adding new
>> `boolean hasProperties()`
>> method to MenuItem and Toggle only.
>>
>> This change requires CSR.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/MenuItem.java line
> 532:
>
>> 530: /**
>> 531: *
On Fri, 18 Aug 2023 17:06:57 GMT, Andy Goryachev wrote:
> Adding new
> `boolean hasProperties()`
> method to MenuItem and Toggle only.
>
> This change requires CSR.
On second thought, I don't think you should add `hasProperties` to the `Toggle`
interface. Adding it to `MenuItem` should be
On Fri, 18 Aug 2023 22:18:29 GMT, John Hendrikx wrote:
> I don't think you should add `hasProperties` to the `Toggle` interface
I think it's ok - the interface declares getProperties(), so it makes sense to
add it there. Alternatively, there should have been "ContainsProperties"
interface.
On Fri, 18 Aug 2023 22:04:11 GMT, John Hendrikx wrote:
>> Andy Goryachev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review comments
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlPropertiesTest.java
>
> In the Control hierarchy, all property accessor methods must be declared
> `final`.
>
> Added a test to check for missing `final` keyword and added the said keyword
> where required.
Andy Goryachev has updated the pull request incrementally with one additional
commit since the last
On Tue, 15 Aug 2023 21:32:42 GMT, Michael Strauß wrote:
> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
> scene graph. Previously, the `focusWithin` counts of all parents of a removed
> node would be decreased if the removed node has a non-zero `focusWithin`
>
On Fri, 18 Aug 2023 17:06:57 GMT, Andy Goryachev wrote:
> Adding new
> `boolean hasProperties()`
> method to MenuItem and Toggle only.
>
> This change requires CSR.
modules/javafx.controls/src/main/java/javafx/scene/control/MenuItem.java line
532:
> 530: /**
> 531: * Tests if
On Thu, 17 Aug 2023 23:07:14 GMT, Andy Goryachev wrote:
> In the Control hierarchy, all property accessor methods must be declared
> `final`.
>
> Added a test to check for missing `final` keyword and added the said keyword
> where required.
Marked as reviewed by jhendrikx (Committer).
On Fri, 18 Aug 2023 20:45:00 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
On Fri, 18 Aug 2023 21:48:59 GMT, Michael Strauß wrote:
>> thank you for explanations!
>>
>> one more question: suppose, prior to removal of the Pane it contained a
>> focused (Scene.focusOwner) Node.
>> 1. once the Pane is removed, what happens to Scene.focusOwner?
>> 2. once the Pane is
On Fri, 18 Aug 2023 16:21:00 GMT, Michael Strauß wrote:
> The `focusWithin` count cannot be negative, and there is no possible way for
> applications to misuse the API to cause a negative count. If it ends up being
> negative, that's because of a bug, and I think that bugs should be fixed and
On Fri, 18 Aug 2023 20:45:00 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
On Fri, 18 Aug 2023 21:25:38 GMT, Andy Goryachev wrote:
> thank you for explanations!
>
> one more question: suppose, prior to removal of the Pane it contained a
> focused (Scene.focusOwner) Node.
>
> 1. once the Pane is removed, what happens to Scene.focusOwner?
There's quite a bit of logic
Adding new
`boolean hasProperties()`
method to MenuItem and Toggle only.
This change requires CSR.
-
Commit messages:
- test
- has properties
Changes: https://git.openjdk.org/jfx/pull/1215/files
Webrev: https://webrevs.openjdk.org/?repo=jfx=1215=00
Issue:
In the Control hierarchy, all property accessor methods must be declared
`final`.
Added a test to check for missing `final` keyword and added the said keyword
where required.
-
Commit messages:
- whitespace
- added final keyword
- test
Changes:
On Fri, 18 Aug 2023 17:38:51 GMT, Andy Goryachev wrote:
> why I am getting only 91 warnings?
>
> edit: gradle javadoc on mac, java 18 (may be that's why).
Very likely. Btw, our CI builds (for releases) and GHA builds use JDK 19.0.2.
JDK 19 added more checks (so we get 187 warnings). JDK 21
On Fri, 18 Aug 2023 17:54:03 GMT, Andy Goryachev wrote:
> I wish github would copy bug description from the ticket to the PR... I ddi
> not bother to read JBS this time.
I'm glad it doesn't given what ends up in the Descriptions for many bugs. I
should have added that to the PR description.
On Fri, 18 Aug 2023 21:12:58 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8190:
>>
>>> 8188: Node node = oldParent;
>>> 8189: while (node != null) {
>>> 8190: node.focusWithin.adjust(-focusWithin.count);
>>
>>
On Fri, 18 Aug 2023 20:55:23 GMT, Andy Goryachev wrote:
> question: what happens when the user navigates away when editing the cell? it
> looks like the fix correctly handles the situation. are there any other
> possible scenarios?
I don't think there are, because now we're correctly handling
On Fri, 18 Aug 2023 21:05:54 GMT, Andy Goryachev wrote:
> suppose we are removing a Pane with a bunch of Nodes in it that have non-zero
> focusWithin.count values. the parent of said Pane gets a zero count (which is
> correct), whereas the children of said Pane have their counts unchanged (I
On Fri, 18 Aug 2023 20:45:00 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
On Fri, 18 Aug 2023 20:45:00 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
On Fri, 18 Aug 2023 20:45:00 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
On 18/08/2023 18:35, Michael Strauß wrote:
Scene graph nodes have three focus-related properties:
1. focused
2. focus-within
3. focus-visible
What might be a bit surprising is that multiple nodes can be focused
at the same time, but only one of those focused nodes can be the
scene's focus
> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
> scene graph. Previously, the `focusWithin` counts of all parents of a removed
> node would be decreased if the removed node has a non-zero `focusWithin`
> count. This PR adds logic for the opposite scenario: the
On Fri, 18 Aug 2023 20:25:53 GMT, John Hendrikx wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Correctly handle added node with multiple focuses
>
>
On Fri, 18 Aug 2023 20:31:55 GMT, Andy Goryachev wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8329:
>>
>>> 8327: set(true);
>>> 8328: } else if (count == 0) {
>>> 8329: set(false);
>>
>> This looks a bit odd due to the
On Fri, 18 Aug 2023 20:23:04 GMT, John Hendrikx wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Correctly handle added node with multiple focuses
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java
On Fri, 18 Aug 2023 13:39:59 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
On Fri, 18 Aug 2023 18:04:14 GMT, Andy Goryachev wrote:
>> Please, see my edited comment. If we are to change to snapped values
>> _everywhere_ (not only in the proposed fix of this PR), that would be a
>> broader change...
>
> no, I did not propose to change it everywhere.
> In this PR, in
On Fri, 18 Aug 2023 18:00:48 GMT, Jose Pereda wrote:
>> Following the great insight @hjohn vocalized in one of the earlier PRs, at
>> the end we are always dealing with integer pixel coordinates.
>>
>> so, to be correct, any computation that returns pixel coordinates must use
>> snapped
On Fri, 18 Aug 2023 17:48:16 GMT, Andy Goryachev wrote:
>> You might be right.
>>
>> In this case, `topPrefHeight` comes from `getAreaHeight()`, that calls
>> `computeChildPrefAreaHeight()` that ultimately uses `snapSpaceY()`.
>>
>> However, this would also mean that the returned value
On Fri, 18 Aug 2023 17:17:06 GMT, Kevin Rushforth wrote:
> This PR bumps the limit for the number of javadoc warnings and error from 100
> to 1000.
>
> We currently use the default setting of javadoc which only shows 100 warnings
> and errors. This is too small, especially for warnings, and
On Fri, 18 Aug 2023 17:39:12 GMT, Kevin Rushforth wrote:
>> build.gradle line 4262:
>>
>>> 4260: options.addStringOption("-since-label").setValue("New API since
>>> JavaFX 9")
>>> 4261: options.addStringOption("Xmaxwarns").setValue("1000")
>>> 4262:
On Fri, 18 Aug 2023 17:34:28 GMT, Jose Pereda wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderPane.java
>> line 395:
>>
>>> 393:
>>> 394: double middleAreaHeight = Math.max(0,
>>> 395: height - insets.getTop() - insets.getBottom() -
JDK-8313956 is just a simple bug, it's alrady fixed in PR 1210 without
any new API.
I'm only referencing this PR because I think it shows that there can
be confusion that `focus-within` can match a node that doesn't contain
the focus owner. This is not a bug, it's by design. The question is
On Fri, 18 Aug 2023 17:26:14 GMT, Andy Goryachev wrote:
>> This PR bumps the limit for the number of javadoc warnings and error from
>> 100 to 1000.
>>
>> We currently use the default setting of javadoc which only shows 100
>> warnings and errors. This is too small, especially for warnings,
On Fri, 18 Aug 2023 17:17:06 GMT, Kevin Rushforth wrote:
> This PR bumps the limit for the number of javadoc warnings and error from 100
> to 1000.
>
> We currently use the default setting of javadoc which only shows 100 warnings
> and errors. This is too small, especially for warnings, and
On Wed, 16 Aug 2023 21:26:21 GMT, Andy Goryachev wrote:
>> Jose Pereda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Migrate old tests to JUnit 5
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/BorderPane.java
> line
Michael:
Thank you for clarifications! So, are these new properties really required to
fix https://bugs.openjdk.org/browse/JDK-8313956, or it can be fixed by
improving event handling?
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Friday, August 18, 2023 at 10:19
To:
Cc:
On Fri, 18 Aug 2023 17:17:06 GMT, Kevin Rushforth wrote:
> This PR bumps the limit for the number of javadoc warnings and error from 100
> to 1000.
>
> We currently use the default setting of javadoc which only shows 100 warnings
> and errors. This is too small, especially for warnings, and
On Fri, 18 Aug 2023 17:17:06 GMT, Kevin Rushforth wrote:
> This PR bumps the limit for the number of javadoc warnings and error from 100
> to 1000.
>
> We currently use the default setting of javadoc which only shows 100 warnings
> and errors. This is too small, especially for warnings, and
This PR bumps the limit for the number of javadoc warnings and error from 100
to 1000.
We currently use the default setting of javadoc which only shows 100 warnings
and errors. This is too small, especially for warnings, and can cause us to
miss new warnings that arise. Eventually we should
The added properties and pseudo-classes would basically complete the
representation of focus-related states of JavaFX nodes. But I don't
think it's something an application can't implement in other ways.
What prompted this idea is the discussion in PR 1210 [0], where the
behavior of the
Michael:
Is there a specific problem that absolutely cannot be solved without adding
extra properties to Node (or Control)?
Thanks!
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Friday, August 18, 2023 at 09:35
To: openjfx-dev
Subject: Focused nodes and focus owners
Scene
Scene graph nodes have three focus-related properties:
1. focused
2. focus-within
3. focus-visible
What might be a bit surprising is that multiple nodes can be focused
at the same time, but only one of those focused nodes can be the
scene's focus owner. The `Scene.focusOwner` property indicates
On Fri, 18 Aug 2023 15:47:54 GMT, Marius Hanl wrote:
> One a side note, I remember that there is a ticket to clarify what to do when
> the `focusWithin` count is negative. We don't need to solve this in this PR,
> bur maybe for the future we should consider logging an info or something
>
On Fri, 18 Aug 2023 13:38:43 GMT, Michael Strauß wrote:
> That's because the table row remains `focused` even if you change the scene's
> focus owner to the "focus lost" button
I see. But to be honest, the table focus code is not optimal as it contains
multiple focus workarounds which can be
On Fri, 18 Aug 2023 07:17:47 GMT, Ambarish Rapte wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Removed unnecessary code
>
> Looks all neat to me. The FocusTest does cover a variety of scenarios.
> The change
A clean backport to jfx21u. The fix is for the cnn.com web page crash issue,
without the fix, the page crashes. I have tested the fix it is working with the
fix and failing without the fix.
-
Commit messages:
- Backport ddd1f79685383f592a4651811a9a9070569a7832
Changes:
On Fri, 18 Aug 2023 15:17:56 GMT, Jay Bhaskar wrote:
> A clean backport to jfx21u. The fix is for the cnn.com web page crash issue,
> without the fix, the page crashes. I have tested the fix it is working with
> the fix and failing without the fix.
This pull request has now been integrated.
On Thu, 17 Aug 2023 07:51:56 GMT, Jay Bhaskar wrote:
> Issue: WCMediaPlayer does not support HTTP live streaming m3u8 format. Giving
> error com.sun.javafx.webkit.prism.WCMediaPlayerImpl onError WARNING: onError,
> errCode=0, msg=Unsupported protocol "data"
>
> Solution: Do not invoke the
On Thu, 17 Aug 2023 13:50:06 GMT, Jay Bhaskar wrote:
>> Issue: WCMediaPlayer does not support HTTP live streaming m3u8 format.
>> Giving error com.sun.javafx.webkit.prism.WCMediaPlayerImpl onError WARNING:
>> onError, errCode=0, msg=Unsupported protocol "data"
>>
>> Solution: Do not invoke
On Thu, 17 Aug 2023 00:30:45 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
On Fri, 18 Aug 2023 09:19:34 GMT, John Hendrikx wrote:
>> I also noticed this code, which I think will not do the correct thing when
>> `change` is not 1 or -1:
>>
>> void adjust(int change) {
>> count += change;
>>
>> if (count == 1) {
>>
> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
> scene graph. Previously, the `focusWithin` counts of all parents of a removed
> node would be decreased if the removed node has a non-zero `focusWithin`
> count. This PR adds logic for the opposite scenario: the
On Thu, 17 Aug 2023 00:30:45 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
On Thu, 17 Aug 2023 13:50:06 GMT, Jay Bhaskar wrote:
>> Issue: WCMediaPlayer does not support HTTP live streaming m3u8 format.
>> Giving error com.sun.javafx.webkit.prism.WCMediaPlayerImpl onError WARNING:
>> onError, errCode=0, msg=Unsupported protocol "data"
>>
>> Solution: Do not invoke
On Fri, 11 Aug 2023 22:03:28 GMT, John Hendrikx wrote:
>> Incorporates documentation review comments from #1069.
>>
>> This PR should be kept minimal so it can be backported to JFX21; it should
>> only contain documentation changes.
>
> John Hendrikx has updated the pull request incrementally
On Fri, 18 Aug 2023 09:16:57 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8201:
>>
>>> 8199:
>>> 8200: // Since focus changes are atomic, we only fire change
>>> notifications after
>>> 8201: // all changes are committed on all
On Fri, 18 Aug 2023 09:15:03 GMT, John Hendrikx wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Removed unnecessary code
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8201:
>
>> 8199:
On Thu, 17 Aug 2023 00:30:45 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
The issue is present in AreaChart along with the LineChart. Issue is fixed in
both the charts as part of this PR.
The line elements in case of Line chart and both line element and fill element
in the case of Area charts were not cleared in `makePaths()` method in
AreaChart.java. Hence the line
On Thu, 17 Aug 2023 00:30:45 GMT, Michael Strauß wrote:
>> This PR fixes an issue with the way `focusWithin` bits are adjusted in the
>> scene graph. Previously, the `focusWithin` counts of all parents of a
>> removed node would be decreased if the removed node has a non-zero
>> `focusWithin`
On Fri, 18 Aug 2023 01:59:06 GMT, Michael Strauß wrote:
> @Maran23 maybe you could take a look, too.
Yes! It is on my list.
-
PR Comment: https://git.openjdk.org/jfx/pull/1210#issuecomment-1683406362
76 matches
Mail list logo
