Re: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v10]

[John Hendrikx]

> There are a number of tickets open related to text rendering:
> 
> https://bugs.openjdk.org/browse/JDK-8314215
> 
> https://bugs.openjdk.org/browse/JDK-8145496
> 
> https://bugs.openjdk.org/browse/JDK-8129014
> 
> They have in common that wrapped text is taking the trailing spaces on each 
> wrapped line into account when calculating where to wrap.  This looks okay 
> for text that is left aligned (as the spaces will be trailing the lines and 
> generally aren't a problem, but looks weird with CENTER and RIGHT alignments. 
>  Even with LEFT alignment there are artifacts of this behavior, where a line 
> like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, 
> `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early 
> because the space is taken into account (ie. `AAA` may still have fit just 
> fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or 
> something).
> 
> The fix for this is two fold; first the individual lines of text should not 
> include any trailing spaces into their widths; second, the code that is 
> taking the trailing space into account when wrapping should ignore all 
> trailing spaces (currently it is ignoring all but one trailing space).  With 
> these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, 
> and there is no more early wrapping due to a space being taking into account 
> while the actual text still would have fit (this is annoying in tight 
> layouts, where a line can be wrapped early even though it looks like it would 
> have fit).
> 
> If it were that simple, we'd be done, but there may be another issue here 
> that needs solving: wrapped aligned TextArea's.
> 
> TextArea don't directly support text alignment (via a setTextAlignment method 
> like Label) but you can change it via CSS.
> 
> For Left alignment + wrapping, TextArea will ignore any spaces typed before a 
> line that was wrapped.  In other words, you can type spaces as much as you 
> want, and they won't show up and the cursor won't move.  The spaces are all 
> getting appended to the previous line.  When you cursor through these spaces, 
> the cursor can be rendered out of the control's bounds.  To illustrate, if 
> you have the text `AAA BBB CCC`, and the text gets wrapped to 
> `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you 
> cursor back, the cursor may be outside the control bounds because so many 
> spaces are trailing `AAA`.
> 
> The above behavior has NOT changed, is pretty standard for wrapped text 
> controls, and IMHO does not need further attent...

John Hendrikx has updated the pull request incrementally with one additional 
commit since the last revision:

  Fix test comment

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1236/files
  - new: https://git.openjdk.org/jfx/pull/1236/files/e71a851a..a49b99a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx=1236=09
 - incr: https://webrevs.openjdk.org/?repo=jfx=1236=08-09

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

PR: https://git.openjdk.org/jfx/pull/1236

Re: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v9]

[John Hendrikx]

> There are a number of tickets open related to text rendering:
> 
> https://bugs.openjdk.org/browse/JDK-8314215
> 
> https://bugs.openjdk.org/browse/JDK-8145496
> 
> https://bugs.openjdk.org/browse/JDK-8129014
> 
> They have in common that wrapped text is taking the trailing spaces on each 
> wrapped line into account when calculating where to wrap.  This looks okay 
> for text that is left aligned (as the spaces will be trailing the lines and 
> generally aren't a problem, but looks weird with CENTER and RIGHT alignments. 
>  Even with LEFT alignment there are artifacts of this behavior, where a line 
> like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, 
> `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early 
> because the space is taken into account (ie. `AAA` may still have fit just 
> fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or 
> something).
> 
> The fix for this is two fold; first the individual lines of text should not 
> include any trailing spaces into their widths; second, the code that is 
> taking the trailing space into account when wrapping should ignore all 
> trailing spaces (currently it is ignoring all but one trailing space).  With 
> these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, 
> and there is no more early wrapping due to a space being taking into account 
> while the actual text still would have fit (this is annoying in tight 
> layouts, where a line can be wrapped early even though it looks like it would 
> have fit).
> 
> If it were that simple, we'd be done, but there may be another issue here 
> that needs solving: wrapped aligned TextArea's.
> 
> TextArea don't directly support text alignment (via a setTextAlignment method 
> like Label) but you can change it via CSS.
> 
> For Left alignment + wrapping, TextArea will ignore any spaces typed before a 
> line that was wrapped.  In other words, you can type spaces as much as you 
> want, and they won't show up and the cursor won't move.  The spaces are all 
> getting appended to the previous line.  When you cursor through these spaces, 
> the cursor can be rendered out of the control's bounds.  To illustrate, if 
> you have the text `AAA BBB CCC`, and the text gets wrapped to 
> `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you 
> cursor back, the cursor may be outside the control bounds because so many 
> spaces are trailing `AAA`.
> 
> The above behavior has NOT changed, is pretty standard for wrapped text 
> controls, and IMHO does not need further attent...

John Hendrikx has updated the pull request incrementally with one additional 
commit since the last revision:

  More test cases (for hard wrapping) and another small fix

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1236/files
  - new: https://git.openjdk.org/jfx/pull/1236/files/70ab18fe..e71a851a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx=1236=08
 - incr: https://webrevs.openjdk.org/?repo=jfx=1236=07-08

  Stats: 65 lines in 2 files changed: 61 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1236.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236

PR: https://git.openjdk.org/jfx/pull/1236

Re: RFR: JDK-8314215 Trailing Spaces before Line Breaks Affect the Center Alignment of Text [v8]

[John Hendrikx]

> There are a number of tickets open related to text rendering:
> 
> https://bugs.openjdk.org/browse/JDK-8314215
> 
> https://bugs.openjdk.org/browse/JDK-8145496
> 
> https://bugs.openjdk.org/browse/JDK-8129014
> 
> They have in common that wrapped text is taking the trailing spaces on each 
> wrapped line into account when calculating where to wrap.  This looks okay 
> for text that is left aligned (as the spaces will be trailing the lines and 
> generally aren't a problem, but looks weird with CENTER and RIGHT alignments. 
>  Even with LEFT alignment there are artifacts of this behavior, where a line 
> like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, 
> `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early 
> because the space is taken into account (ie. `AAA` may still have fit just 
> fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or 
> something).
> 
> The fix for this is two fold; first the individual lines of text should not 
> include any trailing spaces into their widths; second, the code that is 
> taking the trailing space into account when wrapping should ignore all 
> trailing spaces (currently it is ignoring all but one trailing space).  With 
> these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, 
> and there is no more early wrapping due to a space being taking into account 
> while the actual text still would have fit (this is annoying in tight 
> layouts, where a line can be wrapped early even though it looks like it would 
> have fit).
> 
> If it were that simple, we'd be done, but there may be another issue here 
> that needs solving: wrapped aligned TextArea's.
> 
> TextArea don't directly support text alignment (via a setTextAlignment method 
> like Label) but you can change it via CSS.
> 
> For Left alignment + wrapping, TextArea will ignore any spaces typed before a 
> line that was wrapped.  In other words, you can type spaces as much as you 
> want, and they won't show up and the cursor won't move.  The spaces are all 
> getting appended to the previous line.  When you cursor through these spaces, 
> the cursor can be rendered out of the control's bounds.  To illustrate, if 
> you have the text `AAA BBB CCC`, and the text gets wrapped to 
> `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you 
> cursor back, the cursor may be outside the control bounds because so many 
> spaces are trailing `AAA`.
> 
> The above behavior has NOT changed, is pretty standard for wrapped text 
> controls, and IMHO does not need further attent...

John Hendrikx has updated the pull request incrementally with one additional 
commit since the last revision:

  Improve tests, fix a bug

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1236/files
  - new: https://git.openjdk.org/jfx/pull/1236/files/93be3f48..70ab18fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx=1236=07
 - incr: https://webrevs.openjdk.org/?repo=jfx=1236=06-07

  Stats: 287 lines in 2 files changed: 71 ins; 164 del; 52 mod
  Patch: https://git.openjdk.org/jfx/pull/1236.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236

PR: https://git.openjdk.org/jfx/pull/1236

Re: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2]

[Andy Goryachev]

On Tue, 30 Jan 2024 20:43:33 GMT, Martin Fox  wrote:

> I submitted PR

thank you!

-

PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1917861792

Re: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2]

[Martin Fox]

On Tue, 30 Jan 2024 17:33:06 GMT, Andy Goryachev  wrote:

>>> > [JDK-8320912](https://bugs.openjdk.org/browse/JDK-8320912). I put 
>>> > together a fix for that bug but decided not to roll it into this PR.
>>> 
>>> Are these two bugs independent? Should JDK-8320912 be resolved first?
>> 
>> They are independent. This bug has to do with how we divide keystrokes 
>> between KeyEvents and InputMethodEvents. JDK-8320912 is about cleaning up 
>> during focus changes. The order in which they get resolved doesn't matter.
>
>> The order in which they get resolved doesn't matter.
> 
> would it be possible to get 
> [JDK-8320912](https://bugs.openjdk.org/browse/JDK-8320912) integrated first 
> then?  It seems the  scenario it addresses is narrower, and it will be easier 
> to review this bug.

@andy-goryachev-oracle I submitted PR #1356.

-

PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1917860662

RFR: 8320912: IME should commit on focus change

[Martin Fox]

This is a Mac only bug. If the user was in the middle of IM text composition 
and clicked on a different node the partially composed text was left in the old 
node and the IM window wasn't dismissed. This PR implements the existing 
finishInputMethodComposition call so it can commit the text and dismiss the IM 
window before focus moves away from the node where composition was taking place.

This PR changes the implementation of `unmarkText` to match what we want and 
what Apple says it should do ("The text view should accept the marked text as 
if it had been inserted normally"). With that said I haven't found an IME that 
calls this routine.

-

Commit messages:
 - Proper IM window cleanup when focus moves from one node to another

Changes: https://git.openjdk.org/jfx/pull/1356/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx=1356=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320912
  Stats: 40 lines in 4 files changed: 36 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1356.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1356/head:pull/1356

PR: https://git.openjdk.org/jfx/pull/1356

[jfx22] Integrated: 8324879: Platform-specific preferences keys are incorrect for Windows toolkit

[Michael Strauß]

On Tue, 30 Jan 2024 19:21:50 GMT, Michael Strauß  wrote:

> This pull request contains a backport of commit 
> [af7e0571](https://github.com/openjdk/jfx/commit/af7e05716711d942df20eb1f807b384810a4a839)
>  from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Michael Strauß on 30 Jan 2024 and 
> was reviewed by Kevin Rushforth and Andy Goryachev.

This pull request has now been integrated.

Changeset: 34914c46
Author:Michael Strauß 
URL:   
https://git.openjdk.org/jfx/commit/34914c465ac71bd2ab3ba2a5ccae5f353bc59264
Stats: 40 lines in 3 files changed: 33 ins; 0 del; 7 mod

8324879: Platform-specific preferences keys are incorrect for Windows toolkit

Reviewed-by: kcr
Backport-of: af7e05716711d942df20eb1f807b384810a4a839

-

PR: https://git.openjdk.org/jfx/pull/1355

Re: [jfx22] RFR: 8324879: Platform-specific preferences keys are incorrect for Windows toolkit

[Kevin Rushforth]

On Tue, 30 Jan 2024 19:21:50 GMT, Michael Strauß  wrote:

> This pull request contains a backport of commit 
> [af7e0571](https://github.com/openjdk/jfx/commit/af7e05716711d942df20eb1f807b384810a4a839)
>  from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Michael Strauß on 30 Jan 2024 and 
> was reviewed by Kevin Rushforth and Andy Goryachev.

Marked as reviewed by kcr (Lead).

Since it is a clean backport, a single reviewer is sufficient.

-

PR Review: https://git.openjdk.org/jfx/pull/1355#pullrequestreview-1852185055
PR Comment: https://git.openjdk.org/jfx/pull/1355#issuecomment-1917748052

[jfx22] RFR: 8324879: Platform-specific preferences keys are incorrect for Windows toolkit

[Michael Strauß]

This pull request contains a backport of commit 
[af7e0571](https://github.com/openjdk/jfx/commit/af7e05716711d942df20eb1f807b384810a4a839)
 from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Michael Strauß on 30 Jan 2024 and 
was reviewed by Kevin Rushforth and Andy Goryachev.

-

Commit messages:
 - Backport af7e05716711d942df20eb1f807b384810a4a839

Changes: https://git.openjdk.org/jfx/pull/1355/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx=1355=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324879
  Stats: 40 lines in 3 files changed: 33 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1355.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1355/head:pull/1355

PR: https://git.openjdk.org/jfx/pull/1355

Integrated: 8324879: Platform-specific preferences keys are incorrect for Windows toolkit

[Michael Strauß]

On Tue, 30 Jan 2024 00:53:51 GMT, Michael Strauß  wrote:

> `WinApplication` contains mappings of platform-specific preference keys to 
> platform-independent keys.
> These keys are incorrect (for example, `Windows.UIColor.ForegroundColor` 
> instead of `Windows.UIColor.Foreground`).
> 
> This was not discovered during testing because the manual test application 
> doesn't show the values of platform-independent properties (it only shows the 
> platform-specific mappings). I've exended the test application to also show 
> the platform-independent property values.

This pull request has now been integrated.

Changeset: af7e0571
Author:Michael Strauß 
URL:   
https://git.openjdk.org/jfx/commit/af7e05716711d942df20eb1f807b384810a4a839
Stats: 40 lines in 3 files changed: 33 ins; 0 del; 7 mod

8324879: Platform-specific preferences keys are incorrect for Windows toolkit

Reviewed-by: kcr, angorya

-

PR: https://git.openjdk.org/jfx/pull/1353

Re: Binding properties to constant values

[Michael Strauß]

Hi John,

the rule that values set from code are less specific than values set
in author and inline styles is probably lifted from the CSS
specification, which says [0]:

"The UA may choose to honor presentational attributes in an HTML
source document. If so, these attributes are translated to the
corresponding CSS rules with specificity equal to 0, and are treated
as if they were inserted at the start of the author style sheet."

However, it seems like an arbitrary fact that attributes in an FXML
document are equivalent to calling setters from code. Attributes in
FXML documents could just as well be their own thing, couldn't they?

Let's assume for a moment that we could change that (which is a
breaking change), and make a distinction between values that come from
FXML attributes and values that come from code. This would introduce a
new StyleOrigin.ATTRIBUTE, which would be the origin for all attribute
values set by FXMLLoader (or by anyone, this is a public API in
StyleableProperty after all). However, bindings in FXML documents
would probably continue to use the USER origin. The CSS system would
then never change values with USER origin, since they definitely don't
come from attribute values.

With regards to your idea of only allowing cssProperty.setValue() if
the current value doesn't come from an AUTHOR or INLINE style: it
seems like this *will* work some of the time, namely before CSS is
applied for the first time.


[0] https://www.w3.org/TR/CSS22/cascade.html#preshint


On Tue, Jan 30, 2024 at 3:22 PM John Hendrikx  wrote:
>
> Hi Michael,
>
> I think we first need to decide what the correct behavior is for CSS
> properties, as the "bind" solution IMHO is a bug.
>
> The StyleOrigin enum encodes the relative priorities of styles and user
> set values, but it is incomplete and not fully enforced.  There is
> (currently) actually a 5th level (next to USER_AGENT, USER, AUTHOR and
> INLINE) where it checks the binding state (it has no choice, as it will
> get an exception otherwise, or has to call `unbind` first).  Whether
> that's a bug or should more formally be accepted as the correct behavior
> remains to be seen.  Also the AUTHOR and INLINE levels are only best
> effort, as setting a value in code (USER level) will override AUTHOR and
> INLINE values **temporarily** until the next CSS pass...
>
> So first questions to answer IMHO are:
>
> 1) Does it make sense to treat values set in code (which IMHO should
> always be the last word on anything) as less important than values from
> AUTHOR and INLINE styles?  This is specified in the CSS document, but
> not fully enforced.
>
> 2) Should bound values (which IMHO fall under "values set from code") be
> able to override AUTHOR and INLINE styles?  Why are they being treated
> differently at all?  Which StyleOrigin level do they fall under?
> "USER"?  A 5th level with higher priority than "INLINE"?
>
> 3) Should properties which hold an AUTHOR or INLINE value reject calls
> to `setValue` (to make it clear they are temporary and that your code is
> probably wrong)?  This currently is not in line with the CSS document.
> Note that this will be slightly annoying for the CSS engine as it may
> not be able to "reset" such values as easily as before (which is
> probably the reason it currently works the way it does, but that's no
> excuse IMHO).
>
> As for your potential solution, if you introduce a constant binding
> system (to solve a CSS problem), does that make sense for properties as
> a whole?  What can be achieved with `bindConstant` that can't be done
> with `setValue`?  `bindConstant` will become the "setter" that always
> works (never throws an exception...), but probably at a higher cost than
> using `setValue`.  Would it not make more sense to only have such
> methods on the Styleable properties (which can then also signal this by
> using an even higher precedence StyleOrigin instead of relying on
> bound/unbound) once there is agreement on the above questions?
>
> In other words, I'd look more in the direction of providing users with a
> better "setter" only for CSS properties, that also uses a different
> StyleOrigin, and to bring both binding and setting in line with the CSS
> document's specification (or alternatively, to change that
> specification).  This means that the normal setter provided next to the
> property method (ie. setXXX) would have to default to some standard
> behavior, while a more specific setter provided on the property itself
> can have an overriding behavior, something like:
>
>  setX() -> calls cssProperty.setValue()
>  cssProperty.setValue() -> sets values if not originated from an
> AUTHOR or INLINE stylesheet, otherwise throws exception (as if bound)
>  cssProperty.forceValue() -> sets value unconditionally, setting
> StyleOrigin to some new to introduce 5th level
> (StyleOrigin.FORCED/DEVELOPER/DEBUG/CONSTANT/FINAL)
>
> Binding can then either be categorized as the StyleOrigin.FORCED or if
> it is 

Re: RFR: 8324879: Platform-specific preferences keys are incorrect for Windows toolkit

[Andy Goryachev]

On Tue, 30 Jan 2024 00:53:51 GMT, Michael Strauß  wrote:

> `WinApplication` contains mappings of platform-specific preference keys to 
> platform-independent keys.
> These keys are incorrect (for example, `Windows.UIColor.ForegroundColor` 
> instead of `Windows.UIColor.Foreground`).
> 
> This was not discovered during testing because the manual test application 
> doesn't show the values of platform-independent properties (it only shows the 
> platform-specific mappings). I've exended the test application to also show 
> the platform-independent property values.

verified on windows 11.
thank you for explicitly mentioning the dependencies between c++ and java in 
the comments!

-

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1353#pullrequestreview-1852100109

Re: RFR: 8324879: Platform-specific preferences keys are incorrect for Windows toolkit

[Andy Goryachev]

On Tue, 30 Jan 2024 00:53:51 GMT, Michael Strauß  wrote:

> `WinApplication` contains mappings of platform-specific preference keys to 
> platform-independent keys.
> These keys are incorrect (for example, `Windows.UIColor.ForegroundColor` 
> instead of `Windows.UIColor.Foreground`).
> 
> This was not discovered during testing because the manual test application 
> doesn't show the values of platform-independent properties (it only shows the 
> platform-specific mappings). I've exended the test application to also show 
> the platform-independent property values.

perhaps under a separate issue, would it be possible to add labels for all the 
properties in Preferences to the PlatformPreferencesChangeTest?

-

PR Comment: https://git.openjdk.org/jfx/pull/1353#issuecomment-1917653158

Re: [jfx22u] RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS

[Kevin Rushforth]

On Tue, 30 Jan 2024 16:57:37 GMT, Kevin Rushforth  wrote:

> Clean backport to jfx22u (for 22.0.1).

@johanvos This clean backport needs Maintainer approval in JBS (but not a 
Review in the PR). You can either use the "/approve" command or do it directly 
in JBS.

-

PR Comment: https://git.openjdk.org/jfx22u/pull/8#issuecomment-1917593055

Re: Build artifacts for Linux aarch64

[Nir Lisker]

Hi Armin,

If I go to https://gluonhq.com/products/javafx/ and filter to linux
aarch64, I see both SDK and JMODS for JavaFX 22-ea+16 (latest version,
which is early access). If you're talking about commercial support, I don't
know. Different companies choose what they support.

- Nir

On Tue, Jan 30, 2024 at 4:07 PM Armin Schrenk 
wrote:

> Hey,
>
> in the past there were releases for the platform linux aarch64. But I
> can't find those anymore, neither in maven central, nor on the Gluon
> javafx page, which provides prebuild jmods/SDKs. Is this platform not
> supported anymore?
>
> Best regards,
>
> Armin Schrenk
>
> --
> Armin Schrenk
>
> Skymatic GmbH, Am Hauptbahnhof 6, 53111 Bonn
> Sitz der Gesellschaft: Bonn; Amtsgericht Bonn, HRB 22635
>
>

Re: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2]

[Andy Goryachev]

On Tue, 30 Jan 2024 17:21:37 GMT, Martin Fox  wrote:

> The order in which they get resolved doesn't matter.

would it be possible to get 
[JDK-8320912](https://bugs.openjdk.org/browse/JDK-8320912) integrated first 
then?  It seems the  scenario it addresses is narrower, and it will be easier 
to review this bug.

-

PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1917552047

Re: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2]

[Martin Fox]

On Tue, 30 Jan 2024 15:56:04 GMT, Andy Goryachev  wrote:

> > [JDK-8320912](https://bugs.openjdk.org/browse/JDK-8320912). I put together 
> > a fix for that bug but decided not to roll it into this PR.
> 
> Are these two bugs independent? Should JDK-8320912 be resolved first?

They are independent. This bug has to do with how we divide keystrokes between 
KeyEvents and InputMethodEvents. JDK-8320912 is about cleaning up during focus 
changes. The order in which they get resolved doesn't matter.

-

PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1917531554

Integrated: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS

[Kevin Rushforth]

On Fri, 5 Jan 2024 23:59:31 GMT, Kevin Rushforth  wrote:

> As noted in the JBS bug, this is a follow-on to 
> [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) that I discovered 
> while testing the fix for 
> [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) (a deadlock in the 
> IME code when using WebView in a JFXPanel on macOS).
> 
> I have tested this in connection with with the proposed fix for JDK-8221261, 
> although it is a valid fix regardless.
> 
> This expands the fix done in 
> [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) to call all of the 
> WebKit methods on the right thread. Additionally, we sometimes see spurious 
> exceptions where the committed text is coming back as null, so I changed the 
> log level to "fine" rather than "severe" for those exceptions. I'll file a 
> follow-up bug  to see if any of these are real problems or not.

This pull request has now been integrated.

Changeset: 40809a3f
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx/commit/40809a3f84d5f9f91b265f455a95d045e5b4f692
Stats: 62 lines in 1 file changed: 33 ins; 18 del; 11 mod

8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS

Reviewed-by: jbhaskar, arapte

-

PR: https://git.openjdk.org/jfx/pull/1321

[jfx22u] RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS

[Kevin Rushforth]

Clean backport to jfx22u (for 22.0.1).

-

Commit messages:
 - Backport 40809a3f84d5f9f91b265f455a95d045e5b4f692

Changes: https://git.openjdk.org/jfx22u/pull/8/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx22u=8=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322703
  Stats: 62 lines in 1 file changed: 33 ins; 18 del; 11 mod
  Patch: https://git.openjdk.org/jfx22u/pull/8.diff
  Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/8/head:pull/8

PR: https://git.openjdk.org/jfx22u/pull/8

Re: Binding properties to constant values

[Scott Palmer]

IMO the current CSS priorities are wrong. A value set from code should be 
adjacent to an in-line style in terms of precedence.  They are both ways of 
saying saying “this particular instance should have this value”

Scott

> On Jan 30, 2024, at 8:31 AM, John Hendrikx  wrote:
> 
> Hi Michael,
> 
> I think we first need to decide what the correct behavior is for CSS 
> properties, as the "bind" solution IMHO is a bug.
> 
> The StyleOrigin enum encodes the relative priorities of styles and user set 
> values, but it is incomplete and not fully enforced.  There is (currently) 
> actually a 5th level (next to USER_AGENT, USER, AUTHOR and INLINE) where it 
> checks the binding state (it has no choice, as it will get an exception 
> otherwise, or has to call `unbind` first).  Whether that's a bug or should 
> more formally be accepted as the correct behavior remains to be seen.  Also 
> the AUTHOR and INLINE levels are only best effort, as setting a value in code 
> (USER level) will override AUTHOR and INLINE values **temporarily** until the 
> next CSS pass...
> 
> So first questions to answer IMHO are:
> 
> 1) Does it make sense to treat values set in code (which IMHO should always 
> be the last word on anything) as less important than values from AUTHOR and 
> INLINE styles?  This is specified in the CSS document, but not fully enforced.
> 
> 2) Should bound values (which IMHO fall under "values set from code") be able 
> to override AUTHOR and INLINE styles?  Why are they being treated differently 
> at all?  Which StyleOrigin level do they fall under?  "USER"?  A 5th level 
> with higher priority than "INLINE"?
> 
> 3) Should properties which hold an AUTHOR or INLINE value reject calls to 
> `setValue` (to make it clear they are temporary and that your code is 
> probably wrong)?  This currently is not in line with the CSS document.  Note 
> that this will be slightly annoying for the CSS engine as it may not be able 
> to "reset" such values as easily as before (which is probably the reason it 
> currently works the way it does, but that's no excuse IMHO).
> 
> As for your potential solution, if you introduce a constant binding system 
> (to solve a CSS problem), does that make sense for properties as a whole?  
> What can be achieved with `bindConstant` that can't be done with `setValue`?  
> `bindConstant` will become the "setter" that always works (never throws an 
> exception...), but probably at a higher cost than using `setValue`.  Would it 
> not make more sense to only have such methods on the Styleable properties 
> (which can then also signal this by using an even higher precedence 
> StyleOrigin instead of relying on bound/unbound) once there is agreement on 
> the above questions?
> 
> In other words, I'd look more in the direction of providing users with a 
> better "setter" only for CSS properties, that also uses a different 
> StyleOrigin, and to bring both binding and setting in line with the CSS 
> document's specification (or alternatively, to change that specification).  
> This means that the normal setter provided next to the property method (ie. 
> setXXX) would have to default to some standard behavior, while a more 
> specific setter provided on the property itself can have an overriding 
> behavior, something like:
> 
> setX() -> calls cssProperty.setValue()
> cssProperty.setValue() -> sets values if not originated from an AUTHOR or 
> INLINE stylesheet, otherwise throws exception (as if bound)
> cssProperty.forceValue() -> sets value unconditionally, setting 
> StyleOrigin to some new to introduce 5th level 
> (StyleOrigin.FORCED/DEVELOPER/DEBUG/CONSTANT/FINAL)
> 
> Binding can then either be categorized as the StyleOrigin.FORCED or if it is 
> StyleOrigin.USER, the CSS engine is free to **unbind** if the need arises.
> 
> --John
> 
> 
>> On 30/01/2024 09:25, Michael Strauß wrote:
>> Hi everyone,
>> 
>> I'm interested in hearing your thoughts on the following proposal,
>> which could increase the expressiveness of the JavaFX Property API:
>> 
>> Problem
>> ---
>> The JavaFX CSS system applies the following order of precedence to
>> determine the value of a styleable property (in ascending
>> specificity):
>> 1. user-agent stylesheets
>> 2. values set from code
>> 3. Scene stylesheets
>> 4. Parent stylesheets
>> 5. inline styles
>> 
>> While this system works quite well in general, applications sometimes
>> need to override individual property values from code. However, this
>> doesn't work reliably in the presence of Scene or Parent stylesheets.
>> There are two usual workarounds to solve this problem:
>> 
>> A) Use an inline style instead of setting the property value directly.
>> 
>> This is obviously not a good solution, as you'll lose the strong
>> typing afforded by the Java language. Additionally, the value must be
>> a true constant, it can't be an expression or the result of a
>> computation.
>> 
>> B) Create an `ObservableValue` instance that holds the 

Re: Headless glass platform

[Kevin Rushforth]

Yeah, this is a better place for discussion than JBS.

JavaFX has long lacked a real headless test platform, so it will be cool 
to see where this goes.



 - Is there a JEP/tutorial for the new mode?


It's probably premature, given the early prototype nature...

-- Kevin


On 1/30/2024 8:14 AM, Andy Goryachev wrote:


Excellent development, Johan, thank you!

I’ve asked a few questions in the ticket 
https://bugs.openjdk.org/browse/JDK-8324941


I suppose I should also do it here:

- How do you get information on a (virtual) screen?
- How would one control how many virtual screens are there?
- Would there be any other way of simulating user input apart from Robot?
- Is the graphics still accelerated?
- Are there any functional gaps between Headless and headful modes 
(fonts, rendering, etc.)?


Most importantly,
- Is there a JEP/tutorial for the new mode?

Thank you

-andy

*From: *openjfx-dev  on behalf of Johan 
Vos 

*Date: *Tuesday, January 30, 2024 at 03:47
*To: *openjfx-dev 
*Subject: *Headless glass platform

Hi,

I created a branch in the jfx-sandbox repository for experimenting 
with a headless glass platform: 
https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless


This addresses https://bugs.openjdk.org/browse/JDK-8324941 where I 
suggest a POC for a Headless platform.


There are a number of usecases for this, including:
1. applications that require JavaFX rendering without presenting this 
to a window (and instead send it to a printer for example)


2. running tests without requiring a window manager.

Regarding the second usecase, we already did some basic experiments 
using a modified version of TestFX where instead of the Monocle 
Headless subplatform, the POC Headless platform is used.


By using a first-class Headless glass platform instead of a Monocle 
subplatform, it should be easier to use by developers.


The monocle code contains very platform/os specific parts, which often 
don't make sense outside the target platform. This is very valuable, 
but it is also a very different usecase than a headless platform and 
it requires a much more complex build procedure.


I added an initial, limited HeadlessRobot to do some basic tests. That 
code is mainly taken from the existing Monocle implementation, but I 
want to be careful to avoid anything that is not applicable to the 
headless scenarios.


- Johan

Re: RFR: 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on macOS [v3]

[Ambarish Rapte]

On Wed, 17 Jan 2024 12:57:22 GMT, Kevin Rushforth  wrote:

>> As noted in the JBS bug, this is a follow-on to 
>> [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011) that I discovered 
>> while testing the fix for 
>> [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) (a deadlock in 
>> the IME code when using WebView in a JFXPanel on macOS).
>> 
>> I have tested this in connection with with the proposed fix for JDK-8221261, 
>> although it is a valid fix regardless.
>> 
>> This expands the fix done in 
>> [JDK-8221261](https://bugs.openjdk.org/browse/JDK-8221261) to call all of 
>> the WebKit methods on the right thread. Additionally, we sometimes see 
>> spurious exceptions where the committed text is coming back as null, so I 
>> changed the log level to "fine" rather than "severe" for those exceptions. 
>> I'll file a follow-up bug  to see if any of these are real problems or not.
>
> 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 four additional 
> commits since the last revision:
> 
>  - Revert change to log message when exception occurs
>  - Merge branch 'master' into 8322703-webkit-ime-crash
>  - Merge remote-tracking branch 'upstream/master' into 
> 8322703-webkit-ime-crash
>  - 8322703: Intermittent crash in WebView in a JFXPanel from IME calls on 
> macOS

Marked as reviewed by arapte (Reviewer).

-

PR Review: https://git.openjdk.org/jfx/pull/1321#pullrequestreview-1851759370

Re: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2]

[Andy Goryachev]

On Sat, 27 Jan 2024 19:19:48 GMT, Martin Fox  wrote:

>> In the Mac glass code the presence of "marked" text (which is tracked in the 
>> nsAttrBuffer) signals that an IME is active. In this state the current code 
>> assumes that when NSTextInputContext handles a `keyDown:` it will either 
>> generate a call to `insertText:replacementRange:` or one of the routines 
>> that manipulates the marked (composed) text. But this bug shows that 
>> sometimes the IME acts on the event without generating any calls back into 
>> glass at all.
>> 
>> In this PR the logic is simplified: if the NSTextInputContext handles the 
>> `keyDown:` and there's marked (composed) text we don't generate a KeyEvent. 
>> Otherwise we do. This PR removes the `shouldProcessKeyEvent` flag since it 
>> no longer assumes we can catch callbacks to update it correctly.
>> 
>> The existing code also assumes that the composition phase ends when the 
>> NSTextInputContext calls `insertText:replacementRange` to commit the text. 
>> This is true but if the user tries to use a dead-key sequence to generate a 
>> non-existent character (like an accented 'q') the context will call 
>> `insertText` twice while handling one key down event. In that case we can't 
>> exit the composition mode upon seeing the first `insertText` call since it 
>> will cause us to mis-handle the second one. This PR defers exiting 
>> composition mode until the end of `keyDown:`.
>> 
>> I also updated a few deprecated constants so this file no longer generates 
>> compiler warnings.
>
> Martin Fox has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   When IM enabled state changes we dismiss the IM window.

> [JDK-8320912](https://bugs.openjdk.org/browse/JDK-8320912). I put together a 
> fix for that bug but decided not to roll it into this PR.

Are these two bugs independent?  Should JDK-8320912 be resolved first?

-

PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1917331034

Re: RFR: 8301900: TextArea: Committing text with ENTER in an IME window inserts newline [v2]

[Martin Fox]

On Mon, 29 Jan 2024 19:04:10 GMT, Andy Goryachev  wrote:

>> Martin Fox has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   When IM enabled state changes we dismiss the IM window.
>
> ... and scenarios described in JDK-8088172 and JDK-8089803 seem to have been 
> fixed.

@andy-goryachev-oracle The behavior you're seeing when clicking on another 
control is a manifestation of https://bugs.openjdk.org/browse/JDK-8320912. I 
put together a fix for that bug but decided not to roll it into this PR. If it 
would help testing I could do that.

The current code to disable the IME happens *after* focus has already moved to 
the node that doesn't want IME input. So the commit that's fired off by 
`unmarkText` targets the wrong node. The fix is to implement 
finishInputMethodComposition so we do the cleanup before the focus changes.

-

PR Comment: https://git.openjdk.org/jfx/pull/1351#issuecomment-1917084109

Re: RFR: 8324879: Platform-specific preferences keys are incorrect for Windows toolkit

[Andy Goryachev]

On Tue, 30 Jan 2024 01:10:56 GMT, Kevin Rushforth  wrote:

> do you want to be the second reviewer?

will do

-

PR Comment: https://git.openjdk.org/jfx/pull/1353#issuecomment-1917335686

Re: Headless glass platform

[Andy Goryachev]

Excellent development, Johan, thank you!

I’ve asked a few questions in the ticket 
https://bugs.openjdk.org/browse/JDK-8324941

I suppose I should also do it here:

- How do you get information on a (virtual) screen?
- How would one control how many virtual screens are there?
- Would there be any other way of simulating user input apart from Robot?
- Is the graphics still accelerated?
- Are there any functional gaps between Headless and headful modes (fonts, 
rendering, etc.)?

Most importantly,
- Is there a JEP/tutorial for the new mode?

Thank you
-andy


From: openjfx-dev  on behalf of Johan Vos 

Date: Tuesday, January 30, 2024 at 03:47
To: openjfx-dev 
Subject: Headless glass platform
Hi,

I created a branch in the jfx-sandbox repository for experimenting with a 
headless glass platform: 
https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless

This addresses https://bugs.openjdk.org/browse/JDK-8324941 where I suggest a 
POC for a Headless platform.

There are a number of usecases for this, including:
1. applications that require JavaFX rendering without presenting this to a 
window (and instead send it to a printer for example)
2. running tests without requiring a window manager.

Regarding the second usecase, we already did some basic experiments using a 
modified version of TestFX where instead of the Monocle Headless subplatform, 
the POC Headless platform is used.

By using a first-class Headless glass platform instead of a Monocle 
subplatform, it should be easier to use by developers.
The monocle code contains very platform/os specific parts, which often don't 
make sense outside the target platform. This is very valuable, but it is also a 
very different usecase than a headless platform and it requires a much more 
complex build procedure.

I added an initial, limited HeadlessRobot to do some basic tests. That code is 
mainly taken from the existing Monocle implementation, but I want to be careful 
to avoid anything that is not applicable to the headless scenarios.

- Johan

Re: Headless glass platform

[Sean M Phillips]

This is very cool Johan.  I have some questions if you have time to answer:

Do you believe your headless platform POC would allow the use of the
snapshot method for exporting visuals of a scene to a png?
If so do you have any early indications of performance therein? (number of
snapshots per second etc)
Will the headless platform support the 3D Nodes/Camera etc?

Thank you for your work and your time answering in advance.

Sean

On Tue, Jan 30, 2024 at 6:47 AM Johan Vos  wrote:

> Hi,
>
> I created a branch in the jfx-sandbox repository for experimenting with a
> headless glass platform:
> https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
>
> This addresses https://bugs.openjdk.org/browse/JDK-8324941 where I
> suggest a POC for a Headless platform.
>
> There are a number of usecases for this, including:
> 1. applications that require JavaFX rendering without presenting this to a
> window (and instead send it to a printer for example)
> 2. running tests without requiring a window manager.
>
> Regarding the second usecase, we already did some basic experiments using
> a modified version of TestFX where instead of the Monocle Headless
> subplatform, the POC Headless platform is used.
>
> By using a first-class Headless glass platform instead of a Monocle
> subplatform, it should be easier to use by developers.
> The monocle code contains very platform/os specific parts, which often
> don't make sense outside the target platform. This is very valuable, but it
> is also a very different usecase than a headless platform and it requires a
> much more complex build procedure.
>
> I added an initial, limited HeadlessRobot to do some basic tests. That
> code is mainly taken from the existing Monocle implementation, but I want
> to be careful to avoid anything that is not applicable to the headless
> scenarios.
>
> - Johan
>
>

Build artifacts for Linux aarch64

[Armin Schrenk]

Hey,

in the past there were releases for the platform linux aarch64. But I 
can't find those anymore, neither in maven central, nor on the Gluon 
javafx page, which provides prebuild jmods/SDKs. Is this platform not 
supported anymore?


Best regards,

Armin Schrenk

--
Armin Schrenk

Skymatic GmbH, Am Hauptbahnhof 6, 53111 Bonn
Sitz der Gesellschaft: Bonn; Amtsgericht Bonn, HRB 22635



smime.p7s
Description: Kryptografische S/MIME-Signatur

Re: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v3]

[Karthik P K]

On Tue, 30 Jan 2024 09:27:32 GMT, Karthik P K  wrote:

>> Laurent Bourgès has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   fixed copyright years of modified files + fixed comments in 
>> DMarlinPrismUtils
>
> Tests in BidirectionalBindingTest with following exception. (Note: This was 
> during the first JavaFX pre-submit test for this PR)
> 
> BidirectionalBindingTest > [0] > testDoubleBrokenBind[0] STANDARD_ERROR
> Exception in thread "Test worker" java.lang.RuntimeException: 
> Bidirectional binding failed together with an attempt to restore the source 
> property to the previous value. Removing the bidirectional binding from 
> properties BooleanProperty [bound, value: false] and BooleanProperty [bound, 
> value: true]
>   at 
> javafx.base@23-internal/com.sun.javafx.binding.BidirectionalBinding$BidirectionalBooleanBinding.invalidated(BidirectionalBinding.java:286)
>   at 
> javafx.base@23-internal/com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:147)
>   at 
> javafx.base@23-internal/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
>   at 
> javafx.base@23-internal/javafx.beans.property.BooleanPropertyBase.fireValueChangedEvent(BooleanPropertyBase.java:104)
>   at 
> javafx.base@23-internal/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:111)
>   at 
> javafx.base@23-internal/javafx.beans.property.BooleanPropertyBase.bind(BooleanPropertyBase.java:177)
>   at 
> test.com.sun.javafx.binding.BidirectionalBindingTest.testDoubleBrokenBind(BidirectionalBindingTest.java:293)
>   at 
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>   at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
>   ...

> @karthikpandelu The exception that you listed in your comment is not a 
> failing test. When you say "the test failure that we saw here in JavaFX 
> pre-submit tests" did you mean the earlier GHA run test failure? That was 
> just a mismatch in the package name and the file name of the system test 
> class. The GHA test build does not run the system tests (those are all 
> headful tests), but it _does_ verify all of the package names. It was that 
> validation that failed.

Yes Kevin, I was referring to the GHA run test failure. I got it now. Thanks 
for the details.

-

PR Comment: https://git.openjdk.org/jfx/pull/1348#issuecomment-1916883675

Re: Binding properties to constant values

[John Hendrikx]

Hi Michael,

I think we first need to decide what the correct behavior is for CSS 
properties, as the "bind" solution IMHO is a bug.


The StyleOrigin enum encodes the relative priorities of styles and user 
set values, but it is incomplete and not fully enforced.  There is 
(currently) actually a 5th level (next to USER_AGENT, USER, AUTHOR and 
INLINE) where it checks the binding state (it has no choice, as it will 
get an exception otherwise, or has to call `unbind` first).  Whether 
that's a bug or should more formally be accepted as the correct behavior 
remains to be seen.  Also the AUTHOR and INLINE levels are only best 
effort, as setting a value in code (USER level) will override AUTHOR and 
INLINE values **temporarily** until the next CSS pass...


So first questions to answer IMHO are:

1) Does it make sense to treat values set in code (which IMHO should 
always be the last word on anything) as less important than values from 
AUTHOR and INLINE styles?  This is specified in the CSS document, but 
not fully enforced.


2) Should bound values (which IMHO fall under "values set from code") be 
able to override AUTHOR and INLINE styles?  Why are they being treated 
differently at all?  Which StyleOrigin level do they fall under?  
"USER"?  A 5th level with higher priority than "INLINE"?


3) Should properties which hold an AUTHOR or INLINE value reject calls 
to `setValue` (to make it clear they are temporary and that your code is 
probably wrong)?  This currently is not in line with the CSS document.  
Note that this will be slightly annoying for the CSS engine as it may 
not be able to "reset" such values as easily as before (which is 
probably the reason it currently works the way it does, but that's no 
excuse IMHO).


As for your potential solution, if you introduce a constant binding 
system (to solve a CSS problem), does that make sense for properties as 
a whole?  What can be achieved with `bindConstant` that can't be done 
with `setValue`?  `bindConstant` will become the "setter" that always 
works (never throws an exception...), but probably at a higher cost than 
using `setValue`.  Would it not make more sense to only have such 
methods on the Styleable properties (which can then also signal this by 
using an even higher precedence StyleOrigin instead of relying on 
bound/unbound) once there is agreement on the above questions?


In other words, I'd look more in the direction of providing users with a 
better "setter" only for CSS properties, that also uses a different 
StyleOrigin, and to bring both binding and setting in line with the CSS 
document's specification (or alternatively, to change that 
specification).  This means that the normal setter provided next to the 
property method (ie. setXXX) would have to default to some standard 
behavior, while a more specific setter provided on the property itself 
can have an overriding behavior, something like:


    setX() -> calls cssProperty.setValue()
    cssProperty.setValue() -> sets values if not originated from an 
AUTHOR or INLINE stylesheet, otherwise throws exception (as if bound)
    cssProperty.forceValue() -> sets value unconditionally, setting 
StyleOrigin to some new to introduce 5th level 
(StyleOrigin.FORCED/DEVELOPER/DEBUG/CONSTANT/FINAL)


Binding can then either be categorized as the StyleOrigin.FORCED or if 
it is StyleOrigin.USER, the CSS engine is free to **unbind** if the need 
arises.


--John


On 30/01/2024 09:25, Michael Strauß wrote:

Hi everyone,

I'm interested in hearing your thoughts on the following proposal,
which could increase the expressiveness of the JavaFX Property API:

Problem
---
The JavaFX CSS system applies the following order of precedence to
determine the value of a styleable property (in ascending
specificity):
1. user-agent stylesheets
2. values set from code
3. Scene stylesheets
4. Parent stylesheets
5. inline styles

While this system works quite well in general, applications sometimes
need to override individual property values from code. However, this
doesn't work reliably in the presence of Scene or Parent stylesheets.
There are two usual workarounds to solve this problem:

A) Use an inline style instead of setting the property value directly.

This is obviously not a good solution, as you'll lose the strong
typing afforded by the Java language. Additionally, the value must be
a true constant, it can't be an expression or the result of a
computation.

B) Create an `ObservableValue` instance that holds the desired value,
and bind the property to it.

This is a much better solution. However, what we really want is just
the binding semantics: the bound property becomes unmodifiable and has
the highest precedence in the CSS cascade. But the API only gives us
binding semantics if we give it an `ObservableValue`.


Solution

I'm proposing to separate the toggles "binding semantics" and
"observability". While observability requires you to provide an
`ObservableValue`, binding 

Re: Platform preferences theme detection

[Nir Lisker]

>
>  I'm under the impression that the last available 22+ea maven release,
> which is now almost 3 months old, does not contain the platform preferences
> API
>

You are correct, the new API was added a month after the latest ea build.
Versions 11-21 all had at least 1 ea release per month on average. Not sure
why 22 doesn't.

Johan, do you do these releases or are they part of OpenJFX?

On Tue, Jan 30, 2024 at 2:39 PM Christopher Schnick 
wrote:

> Hello Nir,
>
> I'm not entirely familiar with every ea build, but I'm under the
> impression that the last available 22+ea maven release, which is now almost
> 3 months old, does not contain the platform preferences API and also does
> not contain the kinda important css performance regression fixes.
> On 1/30/2024 1:33 PM, Nir Lisker wrote:
>
> Hi Christopher,
>
> Looking at Maven Central,
> https://mvnrepository.com/artifact/org.openjfx/javafx, JavaFX releases ea
> builds there, which I sometimes use myself from Maven/Gradle. Version 21
> had 6 ea versions, and 22 has 3. The release cycle is 6 months per final
> version (aligned with OpenJDK).
>
> - Nir
>
> On Tue, Jan 30, 2024 at 2:18 PM Christopher Schnick 
> wrote:
>
>> Alright I will try out the new ea release once the fix is integrated.
>> Other than that, everything works fine for me so far with observing colors
>> using the platform-specific strings.
>>
>> As a side note, I think the community would have caught this issue
>> earlier if there were more frequent maven releases of ea builds. As of
>> right now, the only way to properly use recent ea features is downloading
>> the jars and jmods manually from the jdk.java.net site, which is
>> cumbersome. I don't know how much of the maven release pipeline is
>> automated and how much work more frequent ea releases would be, but it
>> would definitely help with early testing and adoption.
>> On 1/29/2024 11:09 PM, Michael Strauß wrote:
>>
>> I see that the names of the platform mappings defined in
>> WinApplication::getPlatformKeyMappings() are simply wrong
>> ("Windows.UIColor.ForegroundColor" instead of
>> "Windows.UIColor.Foreground"), so the platform mappings are not applied to
>> the properties.
>>
>> That's quite surprising, and it's a change that must have slipped into
>> the feature at a very late stage during development, so that it went
>> unnoticed by all reviewers.
>> I'll file a bug and prepare a fix for this issue.
>>
>>
>> On Mon, Jan 29, 2024 at 10:45 PM Christopher Schnick 
>> wrote:
>>
>>> Hello Michael,
>>>
>>> I took a look at the implementation and tried to find the issue. From
>>> what I can see, the mappings returned are correct:
>>>
>>>
>>>
>>> but it seems like they are somehow not applied the PreferencesProperties:
>>>
>>> Let me know whether I can help with anything to debug this issue.
>>>
>>>

[jfx22] Integrated: 8324658: Allow animation play/start/stop/pause methods to be called on any thread

[Nir Lisker]

On Tue, 30 Jan 2024 12:08:41 GMT, Nir Lisker  wrote:

> Hi all,
> 
> This pull request contains a backport of commit 
> [c5ab220b](https://github.com/openjdk/jfx/commit/c5ab220bbc885f2aa99d8c1d5ed8f1753e39251f)
>  from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Nir Lisker on 30 Jan 2024 and was 
> reviewed by Kevin Rushforth and Jose Pereda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 648dfd54
Author:Nir Lisker 
URL:   
https://git.openjdk.org/jfx/commit/648dfd540cde6bc8127df333fe30b2cac5b022e6
Stats: 422 lines in 7 files changed: 225 ins; 148 del; 49 mod

8324658: Allow animation play/start/stop/pause methods to be called on any 
thread

Reviewed-by: kcr
Backport-of: c5ab220bbc885f2aa99d8c1d5ed8f1753e39251f

-

PR: https://git.openjdk.org/jfx/pull/1354

Re: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v3]

[Kevin Rushforth]

On Tue, 30 Jan 2024 09:27:32 GMT, Karthik P K  wrote:

>> Laurent Bourgès has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   fixed copyright years of modified files + fixed comments in 
>> DMarlinPrismUtils
>
> Tests in BidirectionalBindingTest with following exception. (Note: This was 
> during the first JavaFX pre-submit test for this PR)
> 
> BidirectionalBindingTest > [0] > testDoubleBrokenBind[0] STANDARD_ERROR
> Exception in thread "Test worker" java.lang.RuntimeException: 
> Bidirectional binding failed together with an attempt to restore the source 
> property to the previous value. Removing the bidirectional binding from 
> properties BooleanProperty [bound, value: false] and BooleanProperty [bound, 
> value: true]
>   at 
> javafx.base@23-internal/com.sun.javafx.binding.BidirectionalBinding$BidirectionalBooleanBinding.invalidated(BidirectionalBinding.java:286)
>   at 
> javafx.base@23-internal/com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:147)
>   at 
> javafx.base@23-internal/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
>   at 
> javafx.base@23-internal/javafx.beans.property.BooleanPropertyBase.fireValueChangedEvent(BooleanPropertyBase.java:104)
>   at 
> javafx.base@23-internal/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:111)
>   at 
> javafx.base@23-internal/javafx.beans.property.BooleanPropertyBase.bind(BooleanPropertyBase.java:177)
>   at 
> test.com.sun.javafx.binding.BidirectionalBindingTest.testDoubleBrokenBind(BidirectionalBindingTest.java:293)
>   at 
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>   at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
>   ...

@karthikpandelu The exception that you listed in your comment is not a failing 
test. When you say "the test failure that we saw here in JavaFX pre-submit 
tests" did you mean the earlier GHA run test failure? That was just a mismatch 
in the package name and the file name of the system test class. The GHA test 
build does not run the system tests (those are all headful tests), but it 
_does_ verify all of the package names. It was that validation that failed.

-

PR Comment: https://git.openjdk.org/jfx/pull/1348#issuecomment-1916780646

Re: [jfx22] RFR: 8324658: Allow animation play/start/stop/pause methods to be called on any thread

[Kevin Rushforth]

On Tue, 30 Jan 2024 12:08:41 GMT, Nir Lisker  wrote:

> Hi all,
> 
> This pull request contains a backport of commit 
> [c5ab220b](https://github.com/openjdk/jfx/commit/c5ab220bbc885f2aa99d8c1d5ed8f1753e39251f)
>  from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Nir Lisker on 30 Jan 2024 and was 
> reviewed by Kevin Rushforth and Jose Pereda.
> 
> Thanks!

Marked as reviewed by kcr (Lead).

-

PR Review: https://git.openjdk.org/jfx/pull/1354#pullrequestreview-1851121948

Re: Platform preferences theme detection

[Christopher Schnick]

Hello Nir,

I'm not entirely familiar with every ea build, but I'm under the 
impression that the last available 22+ea maven release, which is now 
almost 3 months old, does not contain the platform preferences API and 
also does not contain the kinda important css performance regression fixes.


On 1/30/2024 1:33 PM, Nir Lisker wrote:

Hi Christopher,

Looking at Maven Central, 
https://mvnrepository.com/artifact/org.openjfx/javafx, JavaFX releases 
ea builds there, which I sometimes use myself from Maven/Gradle. 
Version 21 had 6 ea versions, and 22 has 3. The release cycle is 6 
months per final version (aligned with OpenJDK).


- Nir

On Tue, Jan 30, 2024 at 2:18 PM Christopher Schnick 
 wrote:


Alright I will try out the new ea release once the fix is
integrated. Other than that, everything works fine for me so far
with observing colors using the platform-specific strings.

As a side note, I think the community would have caught this issue
earlier if there were more frequent maven releases of ea builds.
As of right now, the only way to properly use recent ea features
is downloading the jars and jmods manually from the jdk.java.net
 site, which is cumbersome. I don't know how
much of the maven release pipeline is automated and how much work
more frequent ea releases would be, but it would definitely help
with early testing and adoption.

On 1/29/2024 11:09 PM, Michael Strauß wrote:

I see that the names of the platform mappings defined in
WinApplication::getPlatformKeyMappings() are simply wrong
("Windows.UIColor.ForegroundColor" instead of
"Windows.UIColor.Foreground"), so the platform mappings are not
applied to the properties.

That's quite surprising, and it's a change that must have slipped
into the feature at a very late stage during development, so that
it went unnoticed by all reviewers.
I'll file a bug and prepare a fix for this issue.


On Mon, Jan 29, 2024 at 10:45 PM Christopher Schnick
 wrote:

Hello Michael,

I took a look at the implementation and tried to find the
issue. From what I can see, the mappings returned are correct:



but it seems like they are somehow not applied the
PreferencesProperties:

Let me know whether I can help with anything to debug this issue.

Re: Platform preferences theme detection

[Nir Lisker]

Hi Christopher,

Looking at Maven Central,
https://mvnrepository.com/artifact/org.openjfx/javafx, JavaFX releases ea
builds there, which I sometimes use myself from Maven/Gradle. Version 21
had 6 ea versions, and 22 has 3. The release cycle is 6 months per final
version (aligned with OpenJDK).

- Nir

On Tue, Jan 30, 2024 at 2:18 PM Christopher Schnick 
wrote:

> Alright I will try out the new ea release once the fix is integrated.
> Other than that, everything works fine for me so far with observing colors
> using the platform-specific strings.
>
> As a side note, I think the community would have caught this issue earlier
> if there were more frequent maven releases of ea builds. As of right now,
> the only way to properly use recent ea features is downloading the jars and
> jmods manually from the jdk.java.net site, which is cumbersome. I don't
> know how much of the maven release pipeline is automated and how much work
> more frequent ea releases would be, but it would definitely help with early
> testing and adoption.
> On 1/29/2024 11:09 PM, Michael Strauß wrote:
>
> I see that the names of the platform mappings defined in
> WinApplication::getPlatformKeyMappings() are simply wrong
> ("Windows.UIColor.ForegroundColor" instead of
> "Windows.UIColor.Foreground"), so the platform mappings are not applied to
> the properties.
>
> That's quite surprising, and it's a change that must have slipped into the
> feature at a very late stage during development, so that it went unnoticed
> by all reviewers.
> I'll file a bug and prepare a fix for this issue.
>
>
> On Mon, Jan 29, 2024 at 10:45 PM Christopher Schnick 
> wrote:
>
>> Hello Michael,
>>
>> I took a look at the implementation and tried to find the issue. From
>> what I can see, the mappings returned are correct:
>>
>>
>>
>> but it seems like they are somehow not applied the PreferencesProperties:
>>
>> Let me know whether I can help with anything to debug this issue.
>>
>>

Re: Platform preferences theme detection

[Christopher Schnick]

Alright I will try out the new ea release once the fix is integrated. 
Other than that, everything works fine for me so far with observing 
colors using the platform-specific strings.


As a side note, I think the community would have caught this issue 
earlier if there were more frequent maven releases of ea builds. As of 
right now, the only way to properly use recent ea features is 
downloading the jars and jmods manually from the jdk.java.net site, 
which is cumbersome. I don't know how much of the maven release pipeline 
is automated and how much work more frequent ea releases would be, but 
it would definitely help with early testing and adoption.


On 1/29/2024 11:09 PM, Michael Strauß wrote:
I see that the names of the platform mappings defined in 
WinApplication::getPlatformKeyMappings() are simply wrong 
("Windows.UIColor.ForegroundColor" instead of 
"Windows.UIColor.Foreground"), so the platform mappings are not 
applied to the properties.


That's quite surprising, and it's a change that must have slipped into 
the feature at a very late stage during development, so that it went 
unnoticed by all reviewers.

I'll file a bug and prepare a fix for this issue.


On Mon, Jan 29, 2024 at 10:45 PM Christopher Schnick 
 wrote:


Hello Michael,

I took a look at the implementation and tried to find the issue.
From what I can see, the mappings returned are correct:



but it seems like they are somehow not applied the
PreferencesProperties:

Let me know whether I can help with anything to debug this issue.

[jfx22] RFR: 8324658: Allow animation play/start/stop/pause methods to be called on any thread

[Nir Lisker]

Hi all,

This pull request contains a backport of commit 
[c5ab220b](https://github.com/openjdk/jfx/commit/c5ab220bbc885f2aa99d8c1d5ed8f1753e39251f)
 from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Nir Lisker on 30 Jan 2024 and was 
reviewed by Kevin Rushforth and Jose Pereda.

Thanks!

-

Commit messages:
 - Backport c5ab220bbc885f2aa99d8c1d5ed8f1753e39251f

Changes: https://git.openjdk.org/jfx/pull/1354/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx=1354=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324658
  Stats: 422 lines in 7 files changed: 225 ins; 148 del; 49 mod
  Patch: https://git.openjdk.org/jfx/pull/1354.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1354/head:pull/1354

PR: https://git.openjdk.org/jfx/pull/1354

[jfx22u] Integrated: 8324337: Cherry-pick WebKit 617.1 stabilization fixes

[Hima Bindu Meda]

On Tue, 30 Jan 2024 11:56:35 GMT, Hima Bindu Meda  wrote:

> Clean Backport

This pull request has now been integrated.

Changeset: a247278f
Author:Hima Bindu Meda 
URL:   
https://git.openjdk.org/jfx22u/commit/a247278f9818265e1d012981ea7a6fcc2748185a
Stats: 1297 lines in 161 files changed: 752 ins; 111 del; 434 mod

8324337: Cherry-pick WebKit 617.1 stabilization fixes

Backport-of: 52840a17dee6a92fb9b1f3ff1b314b0ae228b95f

-

PR: https://git.openjdk.org/jfx22u/pull/7

[jfx22u] RFR: 8324337: Cherry-pick WebKit 617.1 stabilization fixes

[Hima Bindu Meda]

Clean Backport

-

Commit messages:
 - Backport 52840a17dee6a92fb9b1f3ff1b314b0ae228b95f

Changes: https://git.openjdk.org/jfx22u/pull/7/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx22u=7=00
  Issue: https://bugs.openjdk.org/browse/JDK-8324337
  Stats: 1297 lines in 161 files changed: 752 ins; 111 del; 434 mod
  Patch: https://git.openjdk.org/jfx22u/pull/7.diff
  Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/7/head:pull/7

PR: https://git.openjdk.org/jfx22u/pull/7

Headless glass platform

[Johan Vos]

Hi,

I created a branch in the jfx-sandbox repository for experimenting with a
headless glass platform:
https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless

This addresses https://bugs.openjdk.org/browse/JDK-8324941 where I suggest
a POC for a Headless platform.

There are a number of usecases for this, including:
1. applications that require JavaFX rendering without presenting this to a
window (and instead send it to a printer for example)
2. running tests without requiring a window manager.

Regarding the second usecase, we already did some basic experiments using a
modified version of TestFX where instead of the Monocle Headless
subplatform, the POC Headless platform is used.

By using a first-class Headless glass platform instead of a Monocle
subplatform, it should be easier to use by developers.
The monocle code contains very platform/os specific parts, which often
don't make sense outside the target platform. This is very valuable, but it
is also a very different usecase than a headless platform and it requires a
much more complex build procedure.

I added an initial, limited HeadlessRobot to do some basic tests. That code
is mainly taken from the existing Monocle implementation, but I want to be
careful to avoid anything that is not applicable to the headless scenarios.

- Johan

Re: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v3]

[Karthik P K]

On Mon, 29 Jan 2024 21:29:31 GMT, Laurent Bourgès  wrote:

>> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java
>
> Laurent Bourgès has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   fixed copyright years of modified files + fixed comments in 
> DMarlinPrismUtils

Tests in BidirectionalBindingTest with following exception. (Note: This was 
during the first JavaFX pre-submit test for this PR)

BidirectionalBindingTest > [0] > testDoubleBrokenBind[0] STANDARD_ERROR
Exception in thread "Test worker" java.lang.RuntimeException: Bidirectional 
binding failed together with an attempt to restore the source property to the 
previous value. Removing the bidirectional binding from properties 
BooleanProperty [bound, value: false] and BooleanProperty [bound, value: true]
at 
javafx.base@23-internal/com.sun.javafx.binding.BidirectionalBinding$BidirectionalBooleanBinding.invalidated(BidirectionalBinding.java:286)
at 
javafx.base@23-internal/com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(ExpressionHelper.java:147)
at 
javafx.base@23-internal/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
at 
javafx.base@23-internal/javafx.beans.property.BooleanPropertyBase.fireValueChangedEvent(BooleanPropertyBase.java:104)
at 
javafx.base@23-internal/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:111)
at 
javafx.base@23-internal/javafx.beans.property.BooleanPropertyBase.bind(BooleanPropertyBase.java:177)
at 
test.com.sun.javafx.binding.BidirectionalBindingTest.testDoubleBrokenBind(BidirectionalBindingTest.java:293)
at 
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at 
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at 
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at 
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at 
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at 
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:107)
at 
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at 
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at 
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at 
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at 

Integrated: 8324658: Allow animation play/start/stop/pause methods to be called on any thread

[Nir Lisker]

On Fri, 26 Jan 2024 23:59:50 GMT, Nir Lisker  wrote:

> Added a utility method to run code on the FX thread if it's not already, and 
> changed the animation methods to use it.

This pull request has now been integrated.

Changeset: c5ab220b
Author:Nir Lisker 
URL:   
https://git.openjdk.org/jfx/commit/c5ab220bbc885f2aa99d8c1d5ed8f1753e39251f
Stats: 422 lines in 7 files changed: 225 ins; 148 del; 49 mod

8324658: Allow animation play/start/stop/pause methods to be called on any 
thread

Reviewed-by: kcr, jpereda

-

PR: https://git.openjdk.org/jfx/pull/1352

Re: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v3]

[Laurent Bourgès]

On Mon, 29 Jan 2024 21:29:31 GMT, Laurent Bourgès  wrote:

>> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java
>
> Laurent Bourgès has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   fixed copyright years of modified files + fixed comments in 
> DMarlinPrismUtils

Which test are failing ?

-

PR Comment: https://git.openjdk.org/jfx/pull/1348#issuecomment-1916398127

Re: RFR: 8312603: ArrayIndexOutOfBoundsException in Marlin when scaleX is 0 [v3]

[Karthik P K]

On Mon, 29 Jan 2024 21:29:31 GMT, Laurent Bourgès  wrote:

>> Fixed scale=0 in DMarlinPrismUtils + added new test Scale0Test.java
>
> Laurent Bourgès has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   fixed copyright years of modified files + fixed comments in 
> DMarlinPrismUtils

In my local system I couldn't reproduce the test failure that we saw here in 
JavaFX pre-submit tests. Since the fix was done in system test for the test 
failure, I was wondering how the unit tests failed in the first place. Could be 
a one time failure due to some other issue but same tests failed in all the 3 
platforms. 
Could you please check if the failure was due to any code change?

-

PR Comment: https://git.openjdk.org/jfx/pull/1348#issuecomment-1916385345

Re: RFR: 8324658: Allow animation play/start/stop/pause methods to be called on any thread [v17]

[Jose Pereda]

On Tue, 30 Jan 2024 01:24:52 GMT, Nir Lisker  wrote:

>> Added a utility method to run code on the FX thread if it's not already, and 
>> changed the animation methods to use it.
>
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update tests

Looks good!

-

Marked as reviewed by jpereda (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1352#pullrequestreview-1850577924

Binding properties to constant values

[Michael Strauß]

Hi everyone,

I'm interested in hearing your thoughts on the following proposal,
which could increase the expressiveness of the JavaFX Property API:

Problem
---
The JavaFX CSS system applies the following order of precedence to
determine the value of a styleable property (in ascending
specificity):
1. user-agent stylesheets
2. values set from code
3. Scene stylesheets
4. Parent stylesheets
5. inline styles

While this system works quite well in general, applications sometimes
need to override individual property values from code. However, this
doesn't work reliably in the presence of Scene or Parent stylesheets.
There are two usual workarounds to solve this problem:

A) Use an inline style instead of setting the property value directly.

This is obviously not a good solution, as you'll lose the strong
typing afforded by the Java language. Additionally, the value must be
a true constant, it can't be an expression or the result of a
computation.

B) Create an `ObservableValue` instance that holds the desired value,
and bind the property to it.

This is a much better solution. However, what we really want is just
the binding semantics: the bound property becomes unmodifiable and has
the highest precedence in the CSS cascade. But the API only gives us
binding semantics if we give it an `ObservableValue`.


Solution

I'm proposing to separate the toggles "binding semantics" and
"observability". While observability requires you to provide an
`ObservableValue`, binding semantics should work with both observable
and regular values.

This is a powerful addition to the Property API, since it increases
the expressiveness of the API in a natural way:

// instead of:
rect.setStyle("-fx-fill: red; -fx-width: 200");

// you can use strongly-typed Java code:
rect.fillProperty().bindConstant(Color.RED);
rect.widthProperty().bindConstant(200);

Since the `bindConstant` method accepts a value of the property type,
all features of the Java language can be used to fill in the value.


Implementation
--
The following method will be added to the `Property` interface:

default void bindConstant(T value) {
bind(ObjectConstant.valueOf(value));
}

Specialized methods will be added to `BooleanProperty`,
`DoubleProperty`, `FloatProperty`, `IntegerProperty`, and
`LongProperty`, each with one of the preexisting constant wrappers
that are already in the framework.
Some wrappers can be deduplicated (we only ever need two wrapper
instances for boolean values).