RFR: 8325093: Update CONTRIBUTING.md for build jdk version

[Ao Qi]

[JDK-8297068](https://bugs.openjdk.org/browse/JDK-8297068) updated boot JDK to 
19.0.1 from 18.0.2, and 
[JDK-8321434](https://bugs.openjdk.org/browse/JDK-8321434) updated boot JDK to 
21.0.1. `CONTRIBUTING.md` should be updated correspondingly.

-

Commit messages:
 - 8325093: Update CONTRIBUTING.md for build jdk version

Changes: https://git.openjdk.org/jfx/pull/1357/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx=1357=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325093
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1357.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1357/head:pull/1357

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

Re: RFR: 8320912: IME should commit on focus change

[Martin Fox]

On Wed, 31 Jan 2024 21:49:32 GMT, Andy Goryachev  wrote:

>>>notice how the underline under あ is still there in the first text field.
>> 
>> That behavior surprised me the first time I saw it but I eventually figured 
>> out that it's a feature, not a bug. If you switch back to the original 
>> window by clicking on the title bar you should pick up composition exactly 
>> where you left off e.g. the IM window should appear showing the same 
>> candidates it was showing earlier. That's the way native Mac apps like 
>> TextEdit work (most of the time, every now and then clicking on the title 
>> bar commits the text).
>> 
>> On a technical level the focusOwner for the Scene isn't changing so JavaFX 
>> doesn't think there's any reason to finish composition. And apparently the 
>> OS agrees and relies on Glass to retain enough state that it can pick up 
>> where it left off.
>
>> e.g. the IM window should appear showing the same candidates it was showing 
>> earlier.
> 
> Thank you for clarification!
> The behavior is different, let me explain:
> 
> using the MonkeyTester, open TextField page and the Native-to-ascii tool 
> (Tools -> Native-to-ascii).
> 1. switch to Japanese input
> 2. type "su" into the text field in the main window
> 3. click on a "native" text area in the other window
> 4. type "zu" in the native window
> 5. **unexpectedly**, the text field in the main window shows the symbol still 
> underlined
> 6. click on the main window title to focus back on the original text field.  
> type "zuki"
> EXPECTED:
> - the text field should contain 鈴木
> ACTUAL:
> - the text is すずき, the last two symbols underlined:
> 
> ![Screenshot 2024-01-31 at 13 43 
> 41](https://github.com/openjdk/jfx/assets/107069028/60eac972-252d-40b0-b8ed-76dcb6672bac)
> 
> It looks like the text was indeed committed (despite it being displayed 
> underlined at step 5), and getting back to it from another window does not 
> restore the IME to the state expected at the step 2.
> 
> Interestingly, if instead of going to a different window of the same javafx 
> application, the user clicks elsewhere on some other application window and 
> then goes back to javafx by clicking on the title bar, the IME window is 
> indeed gets back to the expected state.

@andy-goryachev-oracle You're right, I missed a detail and ended up testing 
something else. I did some more testing and it looks like the JavaFX behavior 
is consistent with other apps like TextEdit. If you move focus away from a 
window in the middle of IM composition the composed text is left underlined. If 
you restore focus to that window *before* typing anything the IM will pick up 
where it left off. But if you type something in another window before restoring 
focus the IM will commit the text the moment focus returns. This seems to be 
driven by the OS since TextEdit behaves the same way.

-

PR Comment: https://git.openjdk.org/jfx/pull/1356#issuecomment-1920268535

Re: Binding properties to constant values

[John Hendrikx]

Hi Nir,

On 31/01/2024 22:36, Nir Lisker wrote:


I would wait with the ramifications of setting competing values from 
different origins until the question of precedence is answered. 
Perhaps emitting warnings is better, though I can see some scenarios 
in which they will be annoying.


The way I see the order:
1. Setting from code should always take precedence (including the 
current bindings over setter order of course).

2. INLINE origin (via setStyle).
3. Stylesheets according to their StyleOrigin as specified by the 
non-javafx css specifications [3]: AUTHOR > USER > USER_AGENT (see 
below for INLINE).


2 and 3 are already (more or less) specified in JavaFX's css as far as 
I can see. However, 1 is not css, hence I don't think StyleOrigin 
should be applicable here even. Even more, 2 isn't really css either, 
it mimics html tags and shouldn't count as a css StyleOrigin in my 
opinion.
StyleOrigin is more of an internal thing that got exposed, so I wouldn't 
worry too much about what is CSS and what isn't.  I agree that the above 
order would make more sense. I suspect the reasoning why it wasn't done 
is that setters are getting called to set up defaults, which if they by 
default override all, would conflict with style sheets set by the user.
Note also that a Stylesheet can set its origin [4], even to INLINE, so 
it takes precedence over java property setters and conflicts with 
'setStyle' "real" INLINE. I'm not sure if this is a bug because the 
javafx css specs say that "Inline styles are specified via the Node 
setStyle AP".


The CSS API is weird. It has many seemingly useful and public bits, but 
they are isolated from the rest of FX.


Take StyleSheet for example.  You can convert them (using File to File) 
from regular to binary, then load a binary file and get a StyleSheet 
reference with a public API.  You can then change its origin.  However, 
it stops there.  You can't feed such a modified StyleSheet to FX via any 
public API.


It almost looks like a lot of the CSS public API is there for a possibly 
previously integrated Scene Builder type application, which was later 
split off.




So, if I were to able to do anything I wanted, I would have restricted 
Stylesheets to the options in 3, remove INLINE from a public 
perspective and apply it only behind the scenes to 'setStyle' calls, 
and stop treating java settings in the css hierarchy (which means 
removing the USER StyleOrigin from them). Obviously that breaks a lot 
of code, but this behavior would be my general goal. As for how to 
represent it, maybe a constant can be added to StyleOrigin to 
represent java code settings, but that's not a real css origin. I 
guess we could call INLINE and the hypothetical JAVA constants 
"pseudo-origins", because they don't apply to stylesheets, and are 
only used internally. Or just don't check StyleOrigin when the value 
is set from java. There are probably more ways.


StyleOrigin really is only there for the CSS engine to distinguish if it 
can replace a value or not with something else depending on precedence. 
It probably shouldn't have been public at all, aside from the fact that 
StyleableProperty being an interface forced it to be public.


Oddly enough, the StyleableProperty interface is public, but it is again 
never returned anywhere (didn't check extensively). So you can't 
actually do "label.textAlignment().applyStyle( ... )" even though text 
alignment is a styleable property.


If `textAlignment()` did return a StyleableProperty, then you could do 
`label.textAlignment().applyStyle(StyleOrigin.CODE, value)` for a 
permanent override of the value which the CSS engine will respect.




I also wonder if StyleOrigin should implement Comparable for 
the precedence calculations of stylesheets.


It sort of already does, they are defined in the order of least to 
highest precedence, so an integer comparator on its ordinal can be used.


--John

Re: RFR: 8320912: IME should commit on focus change

[Andy Goryachev]

On Wed, 31 Jan 2024 20:55:16 GMT, Martin Fox  wrote:

> e.g. the IM window should appear showing the same candidates it was showing 
> earlier.

Thank you for clarification!
The behavior is different, let me explain:

using the MonkeyTester, open TextField page and the Native-to-ascii tool (Tools 
-> Native-to-ascii).
1. switch to Japanese input
2. type "su" into the text field in the main window
3. click on a "native" text area in the other window
4. type "zu" in the native window
5. **unexpectedly**, the text field in the main window shows the symbol still 
underlined
6. click on the main window title to focus back on the original text field.  
type "zuki"
EXPECTED:
- the text field should contain 鈴木
ACTUAL:
- the text is すずき, the last two symbols underlined:

![Screenshot 2024-01-31 at 13 43 
41](https://github.com/openjdk/jfx/assets/107069028/60eac972-252d-40b0-b8ed-76dcb6672bac)

It looks like the text was indeed committed (despite it being displayed 
underlined at step 5), and getting back to it from another window does not 
restore the IME to the state expected at the step 2.

Interestingly, if instead of going to a different window of the same javafx 
application, the user clicks elsewhere on some other application window and 
then goes back to javafx by clicking on the title bar, the IME window is indeed 
gets back to the expected state.

-

PR Comment: https://git.openjdk.org/jfx/pull/1356#issuecomment-1920033399

Re: Binding properties to constant values

[Nir Lisker]

>
> 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).


You mean the ones in com.sun.javafx.binding [1]?

I use both constant bindings and inline css to override stylesheets and I
like neither, but I'm not sure that exposing constant binding is the
solution. Like John said, it's specific for css and doesn't make much sense
semantically.

About the order of css origins, there was a relevant discussion on JBS [2].

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.


I think that the specifications chose the wrong order. They say "The
implementation allows designers to style an application by using style
sheets to override property values set from code." and I think this was a
poor and mostly surprising choice. I see that John and Scott agree with
that too. I've seen many StackOverflow questions about this confusion, many
can be found by searching "javafx override css from code". I don't know if
it can be changed, as it's a breaking change. I wonder what the original
writer's thoughts were, and what use case they had in mind. Perhaps they
thought that setting values from the java side is akin to specifying a user
stylesheet to the browser, which takes precedence over the browser's style
sheet, but not over the author's stylesheet.

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"?
>

I don't see how anything should override bound values since they update on
every change and throw an exception if something tries to set the value of
a bound value.

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).


I would wait with the ramifications of setting competing values from
different origins until the question of precedence is answered. Perhaps
emitting warnings is better, though I can see some scenarios in which they
will be annoying.

The way I see the order:
1. Setting from code should always take precedence (including the current
bindings over setter order of course).
2. INLINE origin (via setStyle).
3. Stylesheets according to their StyleOrigin as specified by the
non-javafx css specifications [3]: AUTHOR > USER > USER_AGENT (see below
for INLINE).

2 and 3 are already (more or less) specified in JavaFX's css as far as I
can see. However, 1 is not css, hence I don't think StyleOrigin should be
applicable here even. Even more, 2 isn't really css either, it mimics html
tags and shouldn't count as a css StyleOrigin in my opinion.
Note also that a Stylesheet can set its origin [4], even to INLINE, so it
takes precedence over java property setters and conflicts with 'setStyle'
"real" INLINE. I'm not sure if this is a bug because the javafx css specs
say that "Inline styles are specified via the Node setStyle AP".

So, if I were to able to do anything I wanted, I would have restricted
Stylesheets to the options in 3, remove INLINE from a public perspective
and apply it only behind the scenes to 'setStyle' calls, and stop treating
java settings in the css hierarchy (which means removing the USER
StyleOrigin from them). Obviously that breaks a lot of code, but this
behavior would be my general goal. As for how to represent it, maybe a
constant can be added to StyleOrigin to represent java code settings, but
that's not a real css origin. I guess we could call INLINE and the
hypothetical JAVA constants "pseudo-origins", because they don't apply to
stylesheets, and are only used internally. Or just don't check StyleOrigin
when the value is set from java. There are probably more ways.

I also wonder if StyleOrigin should implement Comparable for the precedence
calculations of stylesheets.

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?
>

Another good point. I don't really use FXML, so I can't say what I would
expect. There are several options for this.

[1]

Re: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v7]

[Andy Goryachev]

On Wed, 31 Jan 2024 10:24:20 GMT, Karthik P K  wrote:

>> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation 
>> conditions were not considered, hence hit test values such as character 
>> index and insertion index values were incorrect.
>> 
>> Added checks for RTL orientation of nodes and  fixed the issue in 
>> `getHitInfo()` to calculate correct hit test values.
>> 
>> Added system tests to validate the changes.
>
> Karthik P K has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix issue with multiline text

... and got an exception hovering over "Rich Text" text on the TextFlow page:


Exception in thread "JavaFX Application Thread" 
java.lang.IllegalArgumentException: offset is out of bounds: 7
at 
java.base/sun.util.locale.provider.BreakIteratorProviderImpl$GraphemeBreakIterator.following(BreakIteratorProviderImpl.java:255)
at 
javafx.graphics/com.sun.javafx.text.PrismTextLayout.getHitInfo(PrismTextLayout.java:582)
at javafx.graphics/javafx.scene.text.Text.hitTest(Text.java:1035)
at 
monkey_tester/com.oracle.tools.fx.monkey.pages.TextFlowPage.handleMouseEvent(TextFlowPage.java:252)
at 
javafx.base/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
at 
javafx.base/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
at 
javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:232)
at 
javafx.base/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:189)
at 
javafx.base/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
at 
javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
at 
javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at 
javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at 
javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at 
javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at 
javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
javafx.base/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at 
javafx.base/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at 
javafx.base/com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
at 
javafx.base/com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
at javafx.base/javafx.event.Event.fireEvent(Event.java:198)
at javafx.base/com.sun.javafx.event.EventQueue.fire(EventQueue.java:48)
at 
javafx.graphics/javafx.scene.Scene$MouseHandler.handleEnterExit(Scene.java:3901)
at 
javafx.graphics/javafx.scene.Scene$MouseHandler.process(Scene.java:3972)
at javafx.graphics/javafx.scene.Scene.processMouseEvent(Scene.java:1893)
at 
javafx.graphics/javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2711)
at 
javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411)
at 
javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:1)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
at 
javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$2(GlassViewEventHandler.java:450)
at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:430)
at 
javafx.graphics/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449)
at javafx.graphics/com.sun.glass.ui.View.handleMouseEvent(View.java:551)
at javafx.graphics/com.sun.glass.ui.View.notifyMouse(View.java:937)
at 
javafx.graphics/com.sun.glass.ui.mac.MacView.notifyMouse(MacView.java:127)


![Screenshot 2024-01-31 at 13 30 
14](https://github.com/openjdk/jfx/assets/107069028/7f374c71-820f-4186-98a5-6d328cafa525)

-

PR Comment: 

Re: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v7]

[Andy Goryachev]

On Wed, 31 Jan 2024 10:24:20 GMT, Karthik P K  wrote:

>> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation 
>> conditions were not considered, hence hit test values such as character 
>> index and insertion index values were incorrect.
>> 
>> Added checks for RTL orientation of nodes and  fixed the issue in 
>> `getHitInfo()` to calculate correct hit test values.
>> 
>> Added system tests to validate the changes.
>
> Karthik P K has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix issue with multiline text

Almost works!  At least all tests where only text segments are present: bidi, 
RTL, mixed text, multi line.
It does fail when a Node is added to TextFlow, will explain in a separate 
comment.

Inline Nodes mess up computation.  In this example, the Text.hitInfo shows 
bogus values anywhere in the word "trailing":

![Screenshot 2024-01-31 at 13 25 
10](https://github.com/openjdk/jfx/assets/107069028/5210576b-4d92-4cc9-902d-b0ed0c5b83d2)

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java 
line 513:

> 511: if ((x > run.getWidth() && (!isMultiRunText 
> || run.getStart() == curRunStart)) || textWidthPrevLine > 0) {
> 512: getBounds(run.getTextSpan(), textBounds);
> 513: x -= (runs[0].getLocation().x - 
> textBounds.getMinX());

suggestion: we are still in the for loop, so perhaps it makes sense to extract 
`(runs[0].getLocation().x - textBounds.getMinX());`
to a variable outside of the loop

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java 
line 517:

> 515: for (int j = runs.length - 1; j > i; j--) {
> 516: if (runs[j].getStart() != curRunStart && 
> runs[j].getTextSpan().getText().equals(text) && !runs[j].isLinebreak()) {
> 517: ltrIndex += runs[j].getLength();

runs[j] is repeated 4 times... should it be a local variable?

-

PR Review: https://git.openjdk.org/jfx/pull/1323#pullrequestreview-1854843704
PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-192439
PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1473468220
PR Review Comment: https://git.openjdk.org/jfx/pull/1323#discussion_r1473469342

Re: RFR: 8320912: IME should commit on focus change

[Martin Fox]

On Wed, 31 Jan 2024 20:07:05 GMT, Andy Goryachev  wrote:

> Another problem I see, and it might be a totally separate issue, is that 
> sometimes when I launch the Monkey Tester and switch to Japanese input, 
> TextField is still receives US input, despite the IME window appearing.

That behavior happens any time the focus is on anything other than a TextInput 
control and you start using an IM. Glass is told that the IM should be disabled 
but it still sends events to the input context. That's a long standing bug. The 
fix for that is part of PR #1351 (in keyDown: I check the IM enabled state 
before sending key events to the input context).

-

PR Comment: https://git.openjdk.org/jfx/pull/1356#issuecomment-1919949874

Re: RFR: 8320912: IME should commit on focus change

[Martin Fox]

On Wed, 31 Jan 2024 18:44:55 GMT, Andy Goryachev  wrote:

>notice how the underline under あ is still there in the first text field.

That behavior surprised me the first time I saw it but I eventually figured out 
that it's a feature, not a bug. If you switch back to the original window by 
clicking on the title bar you should pick up composition exactly where you left 
off e.g. the IM window should appear showing the same candidates it was showing 
earlier. That's the way native Mac apps like TextEdit work (most of the time, 
every now and then clicking on the title bar commits the text).

On a technical level the focusOwner for the Scene isn't changing so JavaFX 
doesn't think there's any reason to finish composition. And apparently the OS 
agrees and relies on Glass to retain enough state that it can pick up where it 
left off.

-

PR Comment: https://git.openjdk.org/jfx/pull/1356#issuecomment-1919942747

Re: RFR: 8320912: IME should commit on focus change

[Andy Goryachev]

On Tue, 30 Jan 2024 20:32:36 GMT, Martin Fox  wrote:

> 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.

Another problem I see, and it might be a totally separate issue, is that 
sometimes when I launch the Monkey Tester and switch to Japanese input, 
TextField is still receives US input, despite the IME window appearing.

When this happens, the IME window appears somewhere in a corner, in another 
screen.  It is also difficult to reproduce.  I first thought it might be 
related to

[JDK-8324666](https://bugs.openjdk.org/browse/JDK-8324666) JFXPanel: Japanese 
IME window initially shown in the corner (Windows) 

except the latter is a JFXPanel issue on Windows.

(it's also possibly I am doing something wrong, though I am doing  a clean 
gradle build, followed by a full refresh and rebuild in Eclipse)

-

PR Comment: https://git.openjdk.org/jfx/pull/1356#issuecomment-1919862497

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

[Laurent Bourgès]

On Wed, 31 Jan 2024 18:40:29 GMT, Kevin Rushforth  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
>
> I don't have any concerns. @arapte said that he would review it. Once he 
> does, and after @karthikpandelu completes the review, you can integrate it 
> (it needs two reviewers).

Of course @kevinrushforth but does a 'common' typo worth a round-trip: boot 
linux, change 1 typo, build, git push,... review.
Sorry, laurent

-

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

Re: [External] : Re: Headless glass platform

[Andy Goryachev]

Thank you for clarifications, Johan!

- Would there be any other way of simulating user input apart from Robot?

Not sure I understand the question. In theory, input with mouse etc would be 
possible but then that would be sort of a duplication/rewrite of the Robot. I'm 
missing the usecase for this I guess?

I was thinking of accepting keystrokes from the actual keyboard, i.e. launch a 
headless application and type something in the console/terminal.  Would that 
work?

Thanks!
-andy


From: Johan Vos 
Date: Wednesday, January 31, 2024 at 01:24
To: Andy Goryachev 
Cc: openjfx-dev 
Subject: [External] : Re: Headless glass platform


On Tue, Jan 30, 2024 at 5:14 PM Andy Goryachev 
mailto:andy.goryac...@oracle.com>> 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?

Good questions. This is currently hardcoded in 
HeadlessApplication.staticScreen_getScreens() but that can be extended to take 
input via environment variables or System properties.

- Would there be any other way of simulating user input apart from Robot?

Not sure I understand the question. In theory, input with mouse etc would be 
possible but then that would be sort of a duplication/rewrite of the Robot. I'm 
missing the usecase for this I guess?

- Is the graphics still accelerated?

Yes, the headless platform does not influence the prism settings. If will still 
use the hw acceleration by default, and fall back to sw-rendering if hw fails, 
or if prism.order is set to explicitly use sw rendering.

- Are there any functional gaps between Headless and headful modes (fonts, 
rendering, etc.)?

Not as far as I know, as that functionality is not in Glass.

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

Thank you
-andy


From: openjfx-dev 
mailto:openjfx-dev-r...@openjdk.org>> on behalf 
of Johan Vos mailto:johan@gluonhq.com>>
Date: Tuesday, January 30, 2024 at 03:47
To: openjfx-dev mailto:openjfx-dev@openjdk.org>>
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: 8320912: IME should commit on focus change

[Andy Goryachev]

On Tue, 30 Jan 2024 20:32:36 GMT, Martin Fox  wrote:

> 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.

Noticed two issues:

1. using the MonkeyTester, open TextField page and the Native-to-ascii tool 
(Tools ->  Native-to-ascii).
2. switch to Japanese input
3. type "a" into the text field in the main window
4. click on a "native" text area in the other window
PROBLEM 1:
notice how the underline under あ is still there in the first text field.  the 
input might have been committed, because when I click back on the first text 
field, the underline disappears.  It works correctly when clicking on the 
second text field *in the same* window (add 

op.option(new TextField());

to TextFieldPage:111 in the Monkey Tester 
https://github.com/andy-goryachev-oracle/MonkeyTest


![Screenshot 2024-01-31 at 10 36 
32](https://github.com/openjdk/jfx/assets/107069028/96861c47-e5b2-4dfd-967f-97ab4b098b1e)

-

PR Comment: https://git.openjdk.org/jfx/pull/1356#issuecomment-1919719343

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

[Kevin Rushforth]

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

I don't have any concerns. @arapte said that he would review it. Once he does, 
and after @karthikpandelu completes the review, you can integrate it (it needs 
two reviewers).

-

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

Withdrawn: 8319340: [Linux] Disabled windows should not allow window operations (minimize, resize, maximize, close)

[duke]

On Thu, 2 Nov 2023 19:13:58 GMT, Thiago Milczarek Sayao  
wrote:

> JavaFX on Linux is allowing disabled windows to be minimized.
> 
> Currently close does nothing as it should, maximize disappears (on MS Windows 
> it's greyed out - it's a platform behavior difference) and minimize is being 
> allowed.
> 
> Thins PR removes WM functions when window is disabled and restores it back 
> when it's re-enabled.

This pull request has been closed without being integrated.

-

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

[jfx22u] Integrated: 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).

This pull request has now been integrated.

Changeset: 37695a2c
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx22u/commit/37695a2ce89d90ca0e1a3bb1d8d7547669b7f2e7
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

Backport-of: 40809a3f84d5f9f91b265f455a95d045e5b4f692

-

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

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 The `/approve` command had a syntax error. It should be: `/approve 
yes` (in a new comment, since Skara won't reprocess edited comments).

-

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

Re: Build artifacts for Linux aarch64

[Armin Schrenk]

Since those are early access, i would prefer to use JFX 21 releases 
since they are used for an open-source project.


I'm not talking about commercial support (although with JFX 22 Gluon 
seems to split the releases into supported and unsupported ones). 
Additionally, as i already said, there are also no maven releases for 
JFX 21.0.2 for linux arm64. Or are the maven releases also made by Gluon?


Does anybody have some info?

Best regards,

Armin Schrenk

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

Am 30.01.2024 um 18:46 schrieb 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


smime.p7s
Description: Kryptografische S/MIME-Signatur

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

[Laurent Bourgès]

On Tue, 30 Jan 2024 12:52:09 GMT, Kevin Rushforth  wrote:

>> 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...
>
> @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.

@kevinrushforth @johanvos is it good to go ?

-

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

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

I have added a minor comment, otherwise the PR looks good to me.
Once all the changes are done, I can approve.

tests/system/src/test/java/test/com/sun/marlin/Scale0Test.java line 82:

> 80: 
> 81: System.setProperty("prism.verbose", "false");
> 82: // enable Marlin logging & internal checks:

Minor: First letter can be made capital.

-

PR Review: https://git.openjdk.org/jfx/pull/1348#pullrequestreview-1853424690
PR Review Comment: https://git.openjdk.org/jfx/pull/1348#discussion_r1472634802

Re: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v6]

[Karthik P K]

On Mon, 29 Jan 2024 07:31:53 GMT, Karthik P K  wrote:

>> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation 
>> conditions were not considered, hence hit test values such as character 
>> index and insertion index values were incorrect.
>> 
>> Added checks for RTL orientation of nodes and  fixed the issue in 
>> `getHitInfo()` to calculate correct hit test values.
>> 
>> Added system tests to validate the changes.
>
> Karthik P K has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Fix issue with RTL text within LTR text

The issue should be fixed now. I tested using monkey tester, my local 
standalone tests and system tests.
Let me know if you find issue in any case.

-

PR Comment: https://git.openjdk.org/jfx/pull/1323#issuecomment-1918809350

Re: RFR: 8319844 : Text/TextFlow.hitTest() is incorrect in RTL orientation [v7]

[Karthik P K]

> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation 
> conditions were not considered, hence hit test values such as character index 
> and insertion index values were incorrect.
> 
> Added checks for RTL orientation of nodes and  fixed the issue in 
> `getHitInfo()` to calculate correct hit test values.
> 
> Added system tests to validate the changes.

Karthik P K has updated the pull request incrementally with one additional 
commit since the last revision:

  Fix issue with multiline text

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1323/files
  - new: https://git.openjdk.org/jfx/pull/1323/files/a58f754e..52ee61cc

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

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1323.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1323/head:pull/1323

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

Re: Headless glass platform

[Johan Vos]

On Tue, Jan 30, 2024 at 5:14 PM 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?
>

Good questions. This is currently hardcoded in
HeadlessApplication.staticScreen_getScreens() but that can be extended to
take input via environment variables or System properties.


> - Would there be any other way of simulating user input apart from Robot?
>

Not sure I understand the question. In theory, input with mouse etc would
be possible but then that would be sort of a duplication/rewrite of the
Robot. I'm missing the usecase for this I guess?


> - Is the graphics still accelerated?
>

Yes, the headless platform does not influence the prism settings. If will
still use the hw acceleration by default, and fall back to sw-rendering if
hw fails, or if prism.order is set to explicitly use sw rendering.


> - Are there any functional gaps between Headless and headful modes (fonts,
> rendering, etc.)?
>

Not as far as I know, as that functionality is not in Glass.

>
> 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

[Johan Vos]

Hi Sean,

On Tue, Jan 30, 2024 at 5:09 PM Sean M Phillips 
wrote:

> 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?
>

Yes, that is one of the usecases indeed. I tested it with a print job, and
that worked. So snapshots should work too.


> If so do you have any early indications of performance therein? (number of
> snapshots per second etc)
>

I don't, but keep in mind that the headless platform is only a replacement
in Glass. The rendering part is done in Prism. The headless platform does
not interfere with that. So if the performance of your application is
rendering-bounded, I expect it to be the same. However, since you don't
need a window system with the headless platform, it's easier to run
applications on headless cloud instances, for example.


> Will the headless platform support the 3D Nodes/Camera etc?
>

Yes, that is outside the Glass platform.

>
> 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
>>
>>