Re: RFR: 8319996: Update to GCC 13.2.0 on Linux [v2]

[Joeri Sykora]

On Wed, 15 Nov 2023 12:35:50 GMT, Kevin Rushforth  wrote:

>> This PR updates the compiler on Linux to GCC 13.2.0 (from 12.2.0) to match 
>> JDK 22.
>> 
>> I've run headless and headful tests on Ubuntu 16.04, 20.04, and 22.04.
>
> Kevin Rushforth has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into 8319996-gcc-13.2
>  - 8319996: Update to GCC 13.2.0 on Linux

Marked as reviewed by sykora (Author).

-

PR Review: https://git.openjdk.org/jfx/pull/1286#pullrequestreview-1733629767

Re: RFR: 8282290: TextField Cursor Position one off [v2]

[Karthik P K]

On Wed, 15 Nov 2023 19:47:28 GMT, Marius Hanl  wrote:

>> this might be problematic, as it uses undocumented aspect of 
>> Text/Flow.caretShape().  the current implementation returns either a single 
>> line, or two lines (moveto,lineto,moveto,lineto) in the case of split/dual 
>> caret.  But this may not be true in the future!  If we add a directional 
>> indicator to the caret this logic will break.
>> 
>> What we may need is to invent a new API possibly that gives us more 
>> information about the caret - whether it's a single or split one, or whether 
>> it has a directionality indicator, information about the adjacent text 
>> segments (rtl,ltr), etc.
>> 
>> We can keep this logic for now, to be fixed once (and if) we add the more 
>> detailed caret API.
>
> Yes, right now it is a bit magic. At least the first if can be simplified 
> still, as `!= 4` will also handle `== 0`.

I agree with Andy here. However the first condition can be simplified without 
any side effects but I had seen some side effects if we remove second 
condition. Hence simplified the first condition as suggested above and 
maintained second condition as it is.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1287#discussion_r1395222766

Re: RFR: 8282290: TextField Cursor Position one off [v2]

[Karthik P K]

> The change listener on caretPositionProperty() was not getting invoked on 
> replacing the content with same text as there was no change in caret 
> position. Since the textProperty invalidation sets the forward bias to true 
> by default, incorrect caret position was  calculated when the same text was 
> replaced after clicking on the trailing edge of last character or empty space 
> in the TextField.
> 
> Since caretShapeProperty invalidation listener gets invoked without changing 
> the caret position, updating the caretBiasProperty on this listener solves 
> the issue.
> 
> Since the caret position value will be same when the caret is present after 
> the last character or before the last character, it can not be validated 
> using unit test.
> The fix can be validated using MonkeyTester.
> Steps to select TextField option in Monkey Tester.
> 
> - Open the MonkeyTester app and select TextField from the left option pane.
> - Select Short from Text selection option and click on the TextField to bring 
> it into focus.
> - Select all using cmd(ctrl) + a and copy using cmd(ctrl) + c
> - Click on empty space in the TextField after the present content.
> - Select all again using the keyboard shortcut and paste using cmd(ctrl) + v
> - The caret should be displayed after the last character. Without the fix 
> caret gets displayed before the last character.

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

  Code review

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1287/files
  - new: https://git.openjdk.org/jfx/pull/1287/files/306487cd..79f2fe82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1287&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1287&range=00-01

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

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

Re: ToolBar rendering bug

[Christopher Schnick]

Alright, I will see what I can do. I was not able to reproduce it every 
time, so I hope it doesn't get too tricky.


On 11/16/2023 12:20 AM, Andy Goryachev wrote:


Dear Christopher:

You application does look nice!

Please understand that without an SCCE, it would be nearly impossible 
for us to do anything.  I can help in creating a bug, but a minimal 
reproducible example is absolute must.


-andy

*From: *openjfx-dev  on behalf of 
Christopher Schnick 

*Date: *Monday, November 13, 2023 at 17:46
*To: *openjfx-dev@openjdk.org 
*Subject: *ToolBar rendering bug

Hello,

I recently stumbled upon a weird rendering issue and managed to
reproduce it, at least inside my own application:
https://www.youtube.com/watch?v=BcMVIOkk-84 . Sadly I don't have the
time to create a minimal reproducible example right now.

I suspect the problem occurs when a ToolBar is width-constrained and has
to wrap some of its content. If a node in the toolbar that is not
wrapped changes its width but no wrapping change occurs, as shown in the
video when I try to open the search bar, the calculations break and
somehow corrupt all nodes to the right of it.

The application is running with JavaFX 21.0.1 on Windows 10.

Best regards, Christopher

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Martin Fox]

On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox  wrote:

> A KeyCharacterCombination should match a key if the target character is 
> printed on that key. For example, the user should be able to invoke the 
> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
> key that has '+' printed on it. This should work even if '+' is a shifted 
> symbol but the user doesn't hold down the Shift key. 
> 
> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
> discover the relationship between keys and characters. Currently the system 
> only records the character the user typed and no other characters on the same 
> key. This means a shortcut targeting a shifted character may not work until 
> the user types that character using Shift so the system learns the 
> relationship.
> 
> This PR keeps the same mechanism in place but always records the shifted and 
> unshifted character for each keystroke.
> 
> For the Mac the KeyboardTest app was modified to remove tests for characters 
> accessed using Option. We don't look for these characters because under the 
> hood just about every key has some symbol assigned to the Option modifier 
> that the user probably isn't even aware of. For these character we fall back 
> to the existing logic; once the user types the character it will start 
> working as a shortcut.

I created [JDK-8320216](https://bugs.openjdk.org/browse/JDK-8320216) for adding 
instructions to the test app.

It would be nice to have a non-Latin language in the test so I will look into 
adding Russian, Arabic, or Hebrew.

I have no idea where to begin with IME-based languages like Japanese and am 
concerned that the resulting tests would be very platform-specific. In any case 
that would be an entirely different test app.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813575324

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Andy Goryachev]

On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox  wrote:

> A KeyCharacterCombination should match a key if the target character is 
> printed on that key. For example, the user should be able to invoke the 
> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
> key that has '+' printed on it. This should work even if '+' is a shifted 
> symbol but the user doesn't hold down the Shift key. 
> 
> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
> discover the relationship between keys and characters. Currently the system 
> only records the character the user typed and no other characters on the same 
> key. This means a shortcut targeting a shifted character may not work until 
> the user types that character using Shift so the system learns the 
> relationship.
> 
> This PR keeps the same mechanism in place but always records the shifted and 
> unshifted character for each keystroke.
> 
> For the Mac the KeyboardTest app was modified to remove tests for characters 
> accessed using Option. We don't look for these characters because under the 
> hood just about every key has some symbol assigned to the Option modifier 
> that the user probably isn't even aware of. For these character we fall back 
> to the existing logic; once the user types the character it will start 
> working as a shortcut.

Marked as reviewed by angorya (Reviewer).

definitely as a follow-up.  this PR looks good to me.

-

PR Review: https://git.openjdk.org/jfx/pull/1209#pullrequestreview-1733269777
PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813512442

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Kevin Rushforth]

On Thu, 16 Nov 2023 00:20:16 GMT, Andy Goryachev  wrote:

> Do you think some other layouts should be added to the keyboard test? 
> (Suggestion: Arabic, Hebrew, Japanese, French, Russian)
> 
> Another suggestion: maybe add the instructions to the KeyboardTest window?

Those both sound like good suggestions. I recommend taking them in a follow-up 
issue rather than as part of this PR.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813511451

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Andy Goryachev]

On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox  wrote:

> A KeyCharacterCombination should match a key if the target character is 
> printed on that key. For example, the user should be able to invoke the 
> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
> key that has '+' printed on it. This should work even if '+' is a shifted 
> symbol but the user doesn't hold down the Shift key. 
> 
> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
> discover the relationship between keys and characters. Currently the system 
> only records the character the user typed and no other characters on the same 
> key. This means a shortcut targeting a shifted character may not work until 
> the user types that character using Shift so the system learns the 
> relationship.
> 
> This PR keeps the same mechanism in place but always records the shifted and 
> unshifted character for each keystroke.
> 
> For the Mac the KeyboardTest app was modified to remove tests for characters 
> accessed using Option. We don't look for these characters because under the 
> hood just about every key has some symbol assigned to the Option modifier 
> that the user probably isn't even aware of. For these character we fall back 
> to the existing logic; once the user types the character it will start 
> working as a shortcut.

0 failures with German.

Do you think some other layouts should be added to the keyboard test?
(Suggestion: Arabic, Hebrew, Japanese, French, Russian)

Another suggestion: maybe add the instructions to the KeyboardTest window?

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813506093

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Andy Goryachev]

On Thu, 16 Nov 2023 00:10:24 GMT, Martin Fox  wrote:

> as long as the test and your selected keyboard match.

ah!  my fault, did not read the javadoc.  let me try again.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813501958

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Martin Fox]

On Wed, 15 Nov 2023 23:08:44 GMT, Andy Goryachev  wrote:

> 1. Using French keyboard on mac (and windows), Ctrl-- is expected to produce 
> the key code RIGHT_PARENTHESIS, correct?

Yes, that key turns into right parenthesis with a French layout.

>  2. Using KeyboardTest, I am getting:

You should not see any failures as long as the test and your selected keyboard 
match. It looks like you were running the French, German, and Spanish tests 
while your keyboard was set to U.S. English. Unfortunately you have to change 
the keyboard layout manually, there's no API in Java that allows me to do it. 
That's also why I can't run all the tests in one go.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813497442

Re: Public Behavior API proposal

[Andy Goryachev]

Dear colleagues:

I wanted to share some of the feedback we received which might be relevant to 
the input map / behavior discussion (and sorry for not sending it earlier).  
Email addresses in DM are redacted (though some of the responses might be from 
this mailing list anyway).



Robert REDACTED REDACTED @gmail.com
Very much appreciated from my side.
I can still remember hacking my way into the the InputMap of some controls to 
change unwanted behaviour.
Generally speaking: Making JavaFX more open is (for me) more important than 
keeping it 100% backwards compatible / super stable.

...





Pedro REDACTED REDACTED @gmail.com

Yes Input Map would be a welcome addition.

...



Buried in
https://github.com/FXMisc/RichTextFX/issues/1167#issuecomment-1435450535

  *   There is no way in TextFlow to provide key/action mappings. This becomes 
a complex area for rich text, for example turning a number of selected Nodes 
into something suitable for cut/copy/paste is not straight forward.


-andy

Re: ToolBar rendering bug

[Andy Goryachev]

Dear Christopher:

You application does look nice!

Please understand that without an SCCE, it would be nearly impossible for us to 
do anything.  I can help in creating a bug, but a minimal reproducible example 
is absolute must.

-andy


From: openjfx-dev  on behalf of Christopher 
Schnick 
Date: Monday, November 13, 2023 at 17:46
To: openjfx-dev@openjdk.org 
Subject: ToolBar rendering bug
Hello,

I recently stumbled upon a weird rendering issue and managed to
reproduce it, at least inside my own application:
https://www.youtube.com/watch?v=BcMVIOkk-84 . Sadly I don't have the
time to create a minimal reproducible example right now.

I suspect the problem occurs when a ToolBar is width-constrained and has
to wrap some of its content. If a node in the toolbar that is not
wrapped changes its width but no wrapping change occurs, as shown in the
video when I try to open the search bar, the calculations break and
somehow corrupt all nodes to the right of it.

The application is running with JavaFX 21.0.1 on Windows 10.

Best regards, Christopher

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Andy Goryachev]

On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox  wrote:

> A KeyCharacterCombination should match a key if the target character is 
> printed on that key. For example, the user should be able to invoke the 
> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
> key that has '+' printed on it. This should work even if '+' is a shifted 
> symbol but the user doesn't hold down the Shift key. 
> 
> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
> discover the relationship between keys and characters. Currently the system 
> only records the character the user typed and no other characters on the same 
> key. This means a shortcut targeting a shifted character may not work until 
> the user types that character using Shift so the system learns the 
> relationship.
> 
> This PR keeps the same mechanism in place but always records the shifted and 
> unshifted character for each keystroke.
> 
> For the Mac the KeyboardTest app was modified to remove tests for characters 
> accessed using Option. We don't look for these characters because under the 
> hood just about every key has some symbol assigned to the Option modifier 
> that the user probably isn't even aware of. For these character we fall back 
> to the existing logic; once the user types the character it will start 
> working as a shortcut.

All right, so I see "HI" printed twice on macOS and Windows.  I guess we are 
good here.

A couple of other observations:

1. Using French keyboard on mac (and windows), Ctrl-- is expected to produce 
the key code RIGHT_PARENTHESIS, correct?

KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=CONTROL, control}
KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=RIGHT_PARENTHESIS, 
control}
KeyEvent{type=KEY_TYPED, character=<\u1B>, text=, code=UNDEFINED, control}  <-- 
missing on Windows, as expected
KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=RIGHT_PARENTHESIS, 
control}
KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=CONTROL}


2. Using KeyboardTest, I am getting:

|Layout|w/o combinations|w/o keypad combinations|with all combinations|
|---|---|---|---|
|US|0|0|0

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813415079

Re: My JavaFX Christmas Wishlist

[Andy Goryachev]

In the spirit of the season, here is my wish list (in no particular order):

- bundling javafx with jdk by default
- playback/display of all the modern A/V/I formats (webp, heic, svg, ...)
- application framework: settings, ui preferences, actions, programmatic css, 
platform api
- cross-platform jpackage, at least for win/linux/macos
- improvements to the core platform: better focus management, actions, text 
enhancements, ...

:-)

-andy




From: openjfx-dev  on behalf of David Alayachew 

Date: Wednesday, November 15, 2023 at 11:31
To: Dirk Lemmermann 
Cc: Nir Lisker , openjfx-dev 
Subject: Re: My JavaFX Christmas Wishlist
My bigger question is asking what you lose by having AWT in JavaFX. Is there 
something fundamentally problematic about it that its removal would 
solve/alleviate a problem?

Whereas on the other hand, AWT has some very useful libraries that are in use 
by nearly all Java GUI frameworks. For example, if you want to do anything 
really complex with 2D Image work, you will inevitably end up using 
java.awt.BufferedImage. It's simple, but very fast.

On Wed, Nov 15, 2023 at 12:18 PM Dirk Lemmermann 
mailto:dlemmerm...@gmail.com>> wrote:
3D: unfortunately that is completely out of my comfort zone … for this feature 
request I am merely the messenger.
AWT: I was thinking that this is mostly a refactoring and probably code 
duplication?

Dirk


Am 15.11.2023 um 14:28 schrieb Nir Lisker 
mailto:nlis...@gmail.com>>:

3D line and point primitives

I filed https://bugs.openjdk.org/browse/JDK-8316398 for this already. As noted, 
it requires a somewhat complex computation for intersections and possibly for 
contains. If you would like to write these Mesh classes, like the current 
TriangleMesh, I can write the rest.

removal of AWT

Isn't that *a lot* of work? All the image IO is AWT, no?

On Wed, Nov 15, 2023 at 10:48 AM Dirk Lemmermann 
mailto:dlemmerm...@gmail.com>> wrote:
Hi guys,

I already mentioned this at the JavaFX BOF at DEVOXX and also posted this on 
Twitter but wanna make sure it gets the visibility it deserves:

All I want for Christmas is … / what I think is needed for JavaFX going forward 
...

- removal of AWT
- a tray API (tray icon)
- undecorated interactive stage style
- blur support for stages
- WebP image format support
- native embedded browser (Chromium)
- 3D line and point primitives
- injection support in FXML for custom controls
- TableView improvements, aka. TableView2

(order of items does not imply priority)

Dirk

Re: RFR: 8313556: Create implementation of NSAccessibilitySlider protocol [v6]

[Alexander Zuev]

> Create implementation for Slider and Stepper accessibility protocols.
> Fix mapping.
> Fix performAction parameter type in declaration.

Alexander Zuev has updated the pull request incrementally with one additional 
commit since the last revision:

  Adding accessibilityMinValue and accessibilityMaxValue

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1226/files
  - new: https://git.openjdk.org/jfx/pull/1226/files/73bf00af..140efce5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1226&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1226&range=04-05

  Stats: 34 lines in 2 files changed: 32 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1226.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1226/head:pull/1226

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

Re: RFR: 8313556: Create implementation of NSAccessibilitySlider protocol [v5]

[Alexander Zuev]

> Create implementation for Slider and Stepper accessibility protocols.
> Fix mapping.
> Fix performAction parameter type in declaration.

Alexander Zuev 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 seven additional 
commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8313556
 - Merge pull request #7 from openjdk/master
   
   Merge
 - - Added accessibilityTitle method
   - Removed some debug output generation
 - Merge remote-tracking branch 'origin/master' into JDK-8313556
 - Fixing warnings during build
 - Add commented out debug statements.
 - 8313556:  Create implementation of NSAccessibilitySlider protocol
   
   Create implementation for Slider and Stepper accessibility protocols.
   Fix mapping.
   Fix performAction parameter type in declaration.

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1226/files
  - new: https://git.openjdk.org/jfx/pull/1226/files/d890b2cb..73bf00af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1226&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1226&range=03-04

  Stats: 964 lines in 44 files changed: 831 ins; 72 del; 61 mod
  Patch: https://git.openjdk.org/jfx/pull/1226.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1226/head:pull/1226

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

Re: RFR: 8313556: Create implementation of NSAccessibilitySlider protocol [v4]

[Alexander Zuev]

> Create implementation for Slider and Stepper accessibility protocols.
> Fix mapping.
> Fix performAction parameter type in declaration.

Alexander Zuev has updated the pull request with a new target base due to a 
merge or a rebase. The incremental webrev excludes the unrelated changes 
brought in by the merge/rebase. The pull request contains five additional 
commits since the last revision:

 - - Added accessibilityTitle method
   - Removed some debug output generation
 - Merge remote-tracking branch 'origin/master' into JDK-8313556
 - Fixing warnings during build
 - Add commented out debug statements.
 - 8313556:  Create implementation of NSAccessibilitySlider protocol
   
   Create implementation for Slider and Stepper accessibility protocols.
   Fix mapping.
   Fix performAction parameter type in declaration.

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1226/files
  - new: https://git.openjdk.org/jfx/pull/1226/files/59135171..d890b2cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1226&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1226&range=02-03

  Stats: 11156 lines in 194 files changed: 8862 ins; 1370 del; 924 mod
  Patch: https://git.openjdk.org/jfx/pull/1226.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1226/head:pull/1226

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

Re: My JavaFX Christmas Wishlist

[Chad Preisler]

I agree with Wayland. It is inevitable, and I want JavaFX to perform well
on Linux.

On Wed, Nov 15, 2023 at 2:16 PM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:

> Hi,
>
> I would choose:
>
> - Wayland
> - Vulkan rendering
> - Copyable labels
> - A pay raise for Kevin :)
>
>
>
>
>
>
>
>
> Em qua., 15 de nov. de 2023 07:25, Dirk Lemmermann 
> escreveu:
>
>> Hi guys,
>>
>> I already mentioned this at the JavaFX BOF at DEVOXX and also posted this
>> on Twitter but wanna make sure it gets the visibility it deserves:
>>
>> All I want for Christmas is … / what I think is needed for JavaFX going
>> forward ...
>>
>> - removal of AWT
>> - a tray API (tray icon)
>> - undecorated interactive stage style
>> - blur support for stages
>> - WebP image format support
>> - native embedded browser (Chromium)
>> - 3D line and point primitives
>> - injection support in FXML for custom controls
>> - TableView improvements, aka. TableView2
>>
>> (order of items does not imply priority)
>>
>> Dirk
>>
>>

Re: My JavaFX Christmas Wishlist

[Michael Strauß]

- more reviewers to tackle the perpetual review bottleneck

[jfx21u] Integrated: 8319762: Update to Visual Studio 2022 version 17.6.5 on Windows

[Kevin Rushforth]

On Wed, 15 Nov 2023 19:50:34 GMT, Kevin Rushforth  wrote:

> Clean backport of compiler update to jfx21u

This pull request has now been integrated.

Changeset: f78ee4e7
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx21u/commit/f78ee4e798c4202f59e656b370bd343e0b3df486
Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8319762: Update to Visual Studio 2022 version 17.6.5 on Windows

Backport-of: 2d4b494ea9cee1acd0407b9de61f0af9163f5d62

-

PR: https://git.openjdk.org/jfx21u/pull/29

[jfx21u] RFR: 8319762: Update to Visual Studio 2022 version 17.6.5 on Windows

[Kevin Rushforth]

Clean backport of compiler update to jfx21u

-

Commit messages:
 - Backport 2d4b494ea9cee1acd0407b9de61f0af9163f5d62

Changes: https://git.openjdk.org/jfx21u/pull/29/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=29&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319762
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx21u/pull/29.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/29/head:pull/29

PR: https://git.openjdk.org/jfx21u/pull/29

[jfx21u] Integrated: 8319669: [macos14] Running any JavaFX app prints Secure coding warning

[Kevin Rushforth]

On Wed, 15 Nov 2023 14:07:36 GMT, Kevin Rushforth  wrote:

> Clean backport of critical macOS 14 fix to 21u.

This pull request has now been integrated.

Changeset: 4953439f
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx21u/commit/4953439fab81fc1808ad071fb1665103929f2fe1
Stats: 22 lines in 2 files changed: 20 ins; 0 del; 2 mod

8319669: [macos14] Running any JavaFX app prints Secure coding warning

Backport-of: 986ec4f9b632f950111015be9445d0bae73042eb

-

PR: https://git.openjdk.org/jfx21u/pull/28

Re: RFR: 8282290: TextField Cursor Position one off

[Marius Hanl]

On Wed, 15 Nov 2023 19:02:09 GMT, Andy Goryachev  wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java
>>  line 248:
>> 
>>> 246: textNode.caretShapeProperty().addListener(observable -> {
>>> 247: 
>>> caretPath.getElements().setAll(textNode.caretShapeProperty().get());
>>> 248: if (caretPath.getElements().size() == 0 || 
>>> caretPath.getElements().size() != 4) {
>> 
>> I think this can be simplified to:
>> 
>> 
>> if (caretPath.getElements().size() != 4) {
>> // The caret pos is invalid.
>> updateTextNodeCaretPos(control.getCaretPosition());
>> } else {
>> caretWidth = Math.round(caretPath.getLayoutBounds().getWidth());
>> }
>
> this might be problematic, as it uses undocumented aspect of 
> Text/Flow.caretShape().  the current implementation returns either a single 
> line, or two lines (moveto,lineto,moveto,lineto) in the case of split/dual 
> caret.  But this may not be true in the future!  If we add a directional 
> indicator to the caret this logic will break.
> 
> What we may need is to invent a new API possibly that gives us more 
> information about the caret - whether it's a single or split one, or whether 
> it has a directionality indicator, information about the adjacent text 
> segments (rtl,ltr), etc.
> 
> We can keep this logic for now, to be fixed once (and if) we add the more 
> detailed caret API.

Yes, right now it is a bit magic. At least the first if can be simplified 
still, as `!= 4` will also handle `== 0`.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1287#discussion_r1394717069

[jfx21u] Integrated: 8318984: Update to Xcode 14.3.1 on macOS

[Kevin Rushforth]

On Tue, 14 Nov 2023 20:52:55 GMT, Kevin Rushforth  wrote:

> Clean backport of compiler update to jfx21u

This pull request has now been integrated.

Changeset: 5a1a12a9
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx21u/commit/5a1a12a91618a2198b31afbdcb4cda2d7967
Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod

8318984: Update to Xcode 14.3.1 on macOS

Backport-of: d24e96a66f1908b5a1a1a7d48ee938ba1c782e6c

-

PR: https://git.openjdk.org/jfx21u/pull/27

Re: My JavaFX Christmas Wishlist

[David Alayachew]

My bigger question is asking what you lose by having AWT in JavaFX. Is
there something fundamentally problematic about it that its removal would
solve/alleviate a problem?

Whereas on the other hand, AWT has some very useful libraries that are in
use by nearly all Java GUI frameworks. For example, if you want to do
anything really complex with 2D Image work, you will inevitably end up
using java.awt.BufferedImage. It's simple, but very fast.

On Wed, Nov 15, 2023 at 12:18 PM Dirk Lemmermann 
wrote:

> 3D: unfortunately that is completely out of my comfort zone … for this
> feature request I am merely the messenger.
> AWT: I was thinking that this is mostly a refactoring and probably code
> duplication?
>
> Dirk
>
> Am 15.11.2023 um 14:28 schrieb Nir Lisker :
>
> 3D line and point primitives
>>
>
> I filed https://bugs.openjdk.org/browse/JDK-8316398 for this already. As
> noted, it requires a somewhat complex computation for intersections and
> possibly for contains. If you would like to write these Mesh classes, like
> the current TriangleMesh, I can write the rest.
>
> removal of AWT
>>
>
> Isn't that *a lot* of work? All the image IO is AWT, no?
>
> On Wed, Nov 15, 2023 at 10:48 AM Dirk Lemmermann 
> wrote:
>
>> Hi guys,
>>
>> I already mentioned this at the JavaFX BOF at DEVOXX and also posted this
>> on Twitter but wanna make sure it gets the visibility it deserves:
>>
>> All I want for Christmas is … / what I think is needed for JavaFX going
>> forward ...
>>
>> - removal of AWT
>> - a tray API (tray icon)
>> - undecorated interactive stage style
>> - blur support for stages
>> - WebP image format support
>> - native embedded browser (Chromium)
>> - 3D line and point primitives
>> - injection support in FXML for custom controls
>> - TableView improvements, aka. TableView2
>>
>> (order of items does not imply priority)
>>
>> Dirk
>>
>>
>

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Andy Goryachev]

On Mon, 14 Aug 2023 16:28:20 GMT, Martin Fox  wrote:

> A KeyCharacterCombination should match a key if the target character is 
> printed on that key. For example, the user should be able to invoke the 
> `Shortcut+'+' ` combination by holding down the Shortcut key and pressing a 
> key that has '+' printed on it. This should work even if '+' is a shifted 
> symbol but the user doesn't hold down the Shift key. 
> 
> The Mac implements KeyCharacterCombinations by monitoring keystrokes to 
> discover the relationship between keys and characters. Currently the system 
> only records the character the user typed and no other characters on the same 
> key. This means a shortcut targeting a shifted character may not work until 
> the user types that character using Shift so the system learns the 
> relationship.
> 
> This PR keeps the same mechanism in place but always records the shifted and 
> unshifted character for each keystroke.
> 
> For the Mac the KeyboardTest app was modified to remove tests for characters 
> accessed using Option. We don't look for these characters because under the 
> hood just about every key has some symbol assigned to the Option modifier 
> that the user probably isn't even aware of. For these character we fall back 
> to the existing logic; once the user types the character it will start 
> working as a shortcut.

let me test with #1264 integrated.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1813121386

Integrated: 8303478: DatePicker throws uncatchable exception on tab out from garbled text

[brunesto]

On Tue, 31 Oct 2023 19:20:48 GMT, brunesto  wrote:

> The fix prevents the DatePicker from losing focus if the date is not parsable.

This pull request has now been integrated.

Changeset: 59c86bbe
Author:brunesto 
Committer: Andy Goryachev 
URL:   
https://git.openjdk.org/jfx/commit/59c86bbe2b83a6e76f0dfc357f3197fe7af79e6c
Stats: 32 lines in 2 files changed: 31 ins; 0 del; 1 mod

8303478: DatePicker throws uncatchable exception on tab out from garbled text

Reviewed-by: angorya

-

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

Re: RFR: 8282290: TextField Cursor Position one off

[Andy Goryachev]

On Wed, 15 Nov 2023 18:20:14 GMT, Marius Hanl  wrote:

>> The change listener on caretPositionProperty() was not getting invoked on 
>> replacing the content with same text as there was no change in caret 
>> position. Since the textProperty invalidation sets the forward bias to true 
>> by default, incorrect caret position was  calculated when the same text was 
>> replaced after clicking on the trailing edge of last character or empty 
>> space in the TextField.
>> 
>> Since caretShapeProperty invalidation listener gets invoked without changing 
>> the caret position, updating the caretBiasProperty on this listener solves 
>> the issue.
>> 
>> Since the caret position value will be same when the caret is present after 
>> the last character or before the last character, it can not be validated 
>> using unit test.
>> The fix can be validated using MonkeyTester.
>> Steps to select TextField option in Monkey Tester.
>> 
>> - Open the MonkeyTester app and select TextField from the left option pane.
>> - Select Short from Text selection option and click on the TextField to 
>> bring it into focus.
>> - Select all using cmd(ctrl) + a and copy using cmd(ctrl) + c
>> - Click on empty space in the TextField after the present content.
>> - Select all again using the keyboard shortcut and paste using cmd(ctrl) + v
>> - The caret should be displayed after the last character. Without the fix 
>> caret gets displayed before the last character.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java
>  line 248:
> 
>> 246: textNode.caretShapeProperty().addListener(observable -> {
>> 247: 
>> caretPath.getElements().setAll(textNode.caretShapeProperty().get());
>> 248: if (caretPath.getElements().size() == 0 || 
>> caretPath.getElements().size() != 4) {
> 
> I think this can be simplified to:
> 
> 
> if (caretPath.getElements().size() != 4) {
> // The caret pos is invalid.
> updateTextNodeCaretPos(control.getCaretPosition());
> } else {
> caretWidth = Math.round(caretPath.getLayoutBounds().getWidth());
> }

this might be problematic, as it uses undocumented aspect of 
Text/Flow.caretShape().  the current implementation returns either a single 
line, or two lines (moveto,lineto,moveto,lineto) in the case of split/dual 
caret.  But this may not be true in the future!  If we add a directional 
indicator to the caret this logic will break.

What we may need is to invent a new API possibly that gives us more information 
about the caret - whether it's a single or split one, or whether it has a 
directionality indicator, information about the adjacent text segments 
(rtl,ltr), etc.

We can keep this logic for now, to be fixed once (and if) we add the more 
detailed caret API.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1287#discussion_r1394656378

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v7]

[brunesto]

> The fix prevents the DatePicker from losing focus if the date is not parsable.

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

  import

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1274/files
  - new: https://git.openjdk.org/jfx/pull/1274/files/a2be8791..cc559143

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=05-06

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

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

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v7]

[Andy Goryachev]

On Wed, 15 Nov 2023 18:58:02 GMT, brunesto  wrote:

>> The fix prevents the DatePicker from losing focus if the date is not 
>> parsable.
>
> brunesto has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   import

perfection achieved :-)

-

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1274#pullrequestreview-1732724400

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v6]

[brunesto]

On Wed, 15 Nov 2023 18:52:17 GMT, brunesto  wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java 
>> line 32:
>> 
>>> 30: import java.time.LocalDate;
>>> 31: import java.time.DateTimeException;
>>> 32: import java.time.format.DateTimeParseException;
>> 
>> is this import still needed?
>
> probably not :) I will remove it...

indeed it was not necessary, so it is removed

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1394649862

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v6]

[Andy Goryachev]

On Wed, 15 Nov 2023 18:52:17 GMT, brunesto  wrote:

>> The fix prevents the DatePicker from losing focus if the date is not 
>> parsable.
>
> brunesto has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   DatePicker on focus lost catches all exceptions around commit

modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 
32:

> 30: import java.time.LocalDate;
> 31: import java.time.DateTimeException;
> 32: import java.time.format.DateTimeParseException;

is this import still needed?

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1394646376

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v6]

[brunesto]

On Wed, 15 Nov 2023 18:51:28 GMT, Andy Goryachev  wrote:

>> brunesto has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   DatePicker on focus lost catches all exceptions around commit
>
> modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java 
> line 32:
> 
>> 30: import java.time.LocalDate;
>> 31: import java.time.DateTimeException;
>> 32: import java.time.format.DateTimeParseException;
> 
> is this import still needed?

probably not :) I will remove it...

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1394647159

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v6]

[brunesto]

> The fix prevents the DatePicker from losing focus if the date is not parsable.

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

  DatePicker on focus lost catches all exceptions around commit

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1274/files
  - new: https://git.openjdk.org/jfx/pull/1274/files/f0880b95..a2be8791

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=04-05

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

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

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v4]

[Andy Goryachev]

On Wed, 15 Nov 2023 18:15:51 GMT, Marius Hanl  wrote:

> I just wonder if we want to catch `Exception` here as well, as it was done in 
> the old code.
> The contract then would be: If a converter throws any exception, we cancel 
> the edit.

There might be some discussion on that, but yes, I'd rather catch(Exception) 
because there might unchecked RuntimeExceptions...

-

PR Comment: https://git.openjdk.org/jfx/pull/1274#issuecomment-1813072001

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v4]

[brunesto]

On Wed, 15 Nov 2023 18:10:28 GMT, Marius Hanl  wrote:

>> brunesto has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   inlined
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/DatePickerTest.java
>  line 765:
> 
>> 763: // check that value remains unchanged, and text is reverted
>> 764: assertEquals(LocalDate.of(2015, 03, 25),datePicker.getValue());
>> 765: assertEquals("3/25/2015",datePicker.getEditor().getText());
> 
> Minor: A space after comma is missing

ok, I have committed the changes in the test class

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1394636485

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v5]

[brunesto]

> The fix prevents the DatePicker from losing focus if the date is not parsable.

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

  minor

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1274/files
  - new: https://git.openjdk.org/jfx/pull/1274/files/8bbdacc6..f0880b95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=03-04

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

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

Re: My JavaFX Christmas Wishlist

[Mark Raynsford]

On Wed, 2023-11-15 at 15:37 -0300, Thiago Milczarek Sayão wrote:
> - Vulkan rendering

Seconded!

> - A pay raise for Kevin :)

Seconded!


-- 
Mark Raynsford | https://www.io7m.com

Re: My JavaFX Christmas Wishlist

[Andy Goryachev]

+1 for pay raise for Kevin

:-)


-andy

From: openjfx-dev  on behalf of Thiago Milczarek 
Sayão 
Date: Wednesday, November 15, 2023 at 10:38
To: Dirk Lemmermann 
Cc: openjfx-dev 
Subject: Re: My JavaFX Christmas Wishlist
Hi,

I would choose:

- Wayland
- Vulkan rendering
- Copyable labels
- A pay raise for Kevin :)








Em qua., 15 de nov. de 2023 07:25, Dirk Lemmermann 
mailto:dlemmerm...@gmail.com>> escreveu:
Hi guys,

I already mentioned this at the JavaFX BOF at DEVOXX and also posted this on 
Twitter but wanna make sure it gets the visibility it deserves:

All I want for Christmas is … / what I think is needed for JavaFX going forward 
...

- removal of AWT
- a tray API (tray icon)
- undecorated interactive stage style
- blur support for stages
- WebP image format support
- native embedded browser (Chromium)
- 3D line and point primitives
- injection support in FXML for custom controls
- TableView improvements, aka. TableView2

(order of items does not imply priority)

Dirk

Re: My JavaFX Christmas Wishlist

[Thiago Milczarek Sayão]

Hi,

I would choose:

- Wayland
- Vulkan rendering
- Copyable labels
- A pay raise for Kevin :)








Em qua., 15 de nov. de 2023 07:25, Dirk Lemmermann 
escreveu:

> Hi guys,
>
> I already mentioned this at the JavaFX BOF at DEVOXX and also posted this
> on Twitter but wanna make sure it gets the visibility it deserves:
>
> All I want for Christmas is … / what I think is needed for JavaFX going
> forward ...
>
> - removal of AWT
> - a tray API (tray icon)
> - undecorated interactive stage style
> - blur support for stages
> - WebP image format support
> - native embedded browser (Chromium)
> - 3D line and point primitives
> - injection support in FXML for custom controls
> - TableView improvements, aka. TableView2
>
> (order of items does not imply priority)
>
> Dirk
>
>

Re: RFR: 8282290: TextField Cursor Position one off

[Marius Hanl]

On Tue, 14 Nov 2023 10:24:20 GMT, Karthik P K  wrote:

> The change listener on caretPositionProperty() was not getting invoked on 
> replacing the content with same text as there was no change in caret 
> position. Since the textProperty invalidation sets the forward bias to true 
> by default, incorrect caret position was  calculated when the same text was 
> replaced after clicking on the trailing edge of last character or empty space 
> in the TextField.
> 
> Since caretShapeProperty invalidation listener gets invoked without changing 
> the caret position, updating the caretBiasProperty on this listener solves 
> the issue.
> 
> Since the caret position value will be same when the caret is present after 
> the last character or before the last character, it can not be validated 
> using unit test.
> The fix can be validated using MonkeyTester.
> Steps to select TextField option in Monkey Tester.
> 
> - Open the MonkeyTester app and select TextField from the left option pane.
> - Select Short from Text selection option and click on the TextField to bring 
> it into focus.
> - Select all using cmd(ctrl) + a and copy using cmd(ctrl) + c
> - Click on empty space in the TextField after the present content.
> - Select all again using the keyboard shortcut and paste using cmd(ctrl) + v
> - The caret should be displayed after the last character. Without the fix 
> caret gets displayed before the last character.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java
 line 248:

> 246: textNode.caretShapeProperty().addListener(observable -> {
> 247: 
> caretPath.getElements().setAll(textNode.caretShapeProperty().get());
> 248: if (caretPath.getElements().size() == 0 || 
> caretPath.getElements().size() != 4) {

I think this can be simplified to:


if (caretPath.getElements().size() != 4) {
// The caret pos is invalid.
updateTextNodeCaretPos(control.getCaretPosition());
} else {
caretWidth = Math.round(caretPath.getLayoutBounds().getWidth());
}

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1287#discussion_r1394603088

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v4]

[Marius Hanl]

On Wed, 15 Nov 2023 09:37:23 GMT, brunesto  wrote:

>> The fix prevents the DatePicker from losing focus if the date is not 
>> parsable.
>
> brunesto has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   inlined

Looks good to me, just some minor things.
I also dug into the code and found out how this worked in JavaFX 8:


...
try {
value = c.fromString(text);
} catch (Exception ex) {
// Most likely a parsing error, such as DateTimeParseException
}
...


So this approach looks correct to me!
I just wonder if we want to catch `Exception` here as well, as it was done in 
the old code.
The contract then would be: If a converter throws any exception, we cancel the 
edit.
@andy-goryachev-oracle any objections here from your side?

modules/javafx.controls/src/test/java/test/javafx/scene/control/DatePickerTest.java
 line 746:

> 744: @Test
> 745: public void testFocusLostWithTypo() {
> 746: //datePicker.setEditable(true); // other test cases have it .is 
> this necessary?

Looks like you can remove this

modules/javafx.controls/src/test/java/test/javafx/scene/control/DatePickerTest.java
 line 753:

> 751: // initial value
> 752: datePicker.setValue(LocalDate.of(2015, 03, 25));
> 753: assertEquals("3/25/2015",datePicker.getEditor().getText());

Minor: A space after comma is missing

modules/javafx.controls/src/test/java/test/javafx/scene/control/DatePickerTest.java
 line 756:

> 754: 
> 755: // set misformatted text
> 756: //stageLoader.getStage().requestFocus(); // other test cases 
> have it . is this necessary?

same here, remove as it works without :)

modules/javafx.controls/src/test/java/test/javafx/scene/control/DatePickerTest.java
 line 764:

> 762: 
> 763: // check that value remains unchanged, and text is reverted
> 764: assertEquals(LocalDate.of(2015, 03, 25),datePicker.getValue());

Minor: A space after comma is missing

modules/javafx.controls/src/test/java/test/javafx/scene/control/DatePickerTest.java
 line 765:

> 763: // check that value remains unchanged, and text is reverted
> 764: assertEquals(LocalDate.of(2015, 03, 25),datePicker.getValue());
> 765: assertEquals("3/25/2015",datePicker.getEditor().getText());

Minor: A space after comma is missing

-

PR Review: https://git.openjdk.org/jfx/pull/1274#pullrequestreview-1732643564
PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1394584158
PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1394585258
PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1394584665
PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1394585403
PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1394585502

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Martin Fox]

On Wed, 15 Nov 2023 00:54:26 GMT, Martin Fox  wrote:

>> @beldenfox thank you.  I still not entirely sure what issue is being tested 
>> and how to fix it, between this PR and JBS.
>> For example, when I run the application listed in JBS description with your 
>> fix, I get one "HI" - is it expected?  (I also get 1 "HI" on Windows)
>> 
>> On macOS, new KeyCodeCombination(KeyCode.MINUS, KeyCombination.CONTROL_DOWN) 
>> does not equal to new KeyCharacterCombination("-", 
>> KeyCombination.CONTROL_DOWN) (same on Windows)
>> 
>> Interestingly, Ctrl+- on macOS with the US keyboard produces
>> 
>> 
>> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=CONTROL, control}
>> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=MINUS, control}
>> KeyEvent{type=KEY_TYPED, character=<\u1F>, text=, code=UNDEFINED, control}
>> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=MINUS, control}
>> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=CONTROL}
>> 
>> 
>> but on Windows, we don't get KEY_TYPED event:
>> 
>> 
>> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=, code=CONTROL, control, 
>> shortcut}
>> KeyEvent{type=KEY_PRESSED, character=<\u00>, text=-, code=MINUS, control, 
>> shortcut}
>> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=-, code=MINUS, control, 
>> shortcut}
>> KeyEvent{type=KEY_RELEASED, character=<\u00>, text=, code=CONTROL}
>> 
>> 
>> 
>> is this expected?
>> 
>> And yes, it would help if we can extract any other issues into their own 
>> tickets (unless they all being fixed by this change).
>> 
>> If I may make one suggestion - for the sake of reviewers - to re-phrase the 
>> JBS ticket in the format of
>> - steps to reproduce
>> - expected outcome
>> - observed outcome
>> 
>> it would help a lot!
>> 
>> Thanks!
>
> @andy-goryachev-oracle What keyboard layout do you normally use on Windows? 
> And Mac? When talking about the behavior of punctuation this is a crucial bit 
> of information.
> 
>> but on Windows, we don't get KEY_TYPED event:
>> is this expected?
> 
> When you hold down Ctrl and press a key the platform may or may not generate 
> a low-ASCII control code. JavaFX has never tried to make the platforms 
> consistent here, Glass just passes on whatever the OS generates. In any case 
> the TextInputControls treat these TYPED events as nuisances, if you look in 
> TextInputControlBehavior.java and read `defaultKeyTyped` you'll see how it 
> tries to filter out control codes and anything else that looks like it was 
> associated with a shortcut.

> @beldenfox thank you. I still not entirely sure what issue is being tested 
> and how to fix it, between this PR and JBS. For example, when I run the 
> application listed in JBS description with your fix, I get one "HI" - is it 
> expected? (I also get 1 "HI" on Windows)

When you run the application in the JBS description and press Ctrl-'-' on the 
main keyboard (not the numeric keypad) you should see "HI" printed twice, once 
for the MINUS KeyCode combination and once for the '-' KeyCharacter 
combination. I'm not sure why that's not working for you on Windows with a U.S. 
layout. With that said, on Windows KeyCharacter combinations for punctuation 
can be uncertain unless you're running a build with PR #1264 which was just 
integrated.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1812925964

Re: RFR: 8087700: [KeyCombination, Mac] KeyCharacterCombinations behave erratically

[Andy Goryachev]

On Wed, 15 Nov 2023 00:54:26 GMT, Martin Fox  wrote:

> What keyboard layout do you normally use on Windows?

US layout on both, at least when the events were captured in the previous 
comment.

-

PR Comment: https://git.openjdk.org/jfx/pull/1209#issuecomment-1812868772

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v4]

[Andy Goryachev]

On Wed, 15 Nov 2023 09:37:23 GMT, brunesto  wrote:

>> The fix prevents the DatePicker from losing focus if the date is not 
>> parsable.
>
> brunesto has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   inlined

Looks good, thank you for making the changes!

-

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1274#pullrequestreview-1732369970

Re: My JavaFX Christmas Wishlist

[Dirk Lemmermann]

3D: unfortunately that is completely out of my comfort zone … for this feature 
request I am merely the messenger.
AWT: I was thinking that this is mostly a refactoring and probably code 
duplication?

Dirk

> Am 15.11.2023 um 14:28 schrieb Nir Lisker :
> 
>> 3D line and point primitives
> 
> I filed https://bugs.openjdk.org/browse/JDK-8316398 for this already. As 
> noted, it requires a somewhat complex computation for intersections and 
> possibly for contains. If you would like to write these Mesh classes, like 
> the current TriangleMesh, I can write the rest.
> 
>> removal of AWT
> 
> Isn't that *a lot* of work? All the image IO is AWT, no? 
> 
> On Wed, Nov 15, 2023 at 10:48 AM Dirk Lemmermann  > wrote:
>> Hi guys,
>> 
>> I already mentioned this at the JavaFX BOF at DEVOXX and also posted this on 
>> Twitter but wanna make sure it gets the visibility it deserves:
>> 
>> All I want for Christmas is … / what I think is needed for JavaFX going 
>> forward ...
>> 
>> - removal of AWT 
>> - a tray API (tray icon) 
>> - undecorated interactive stage style 
>> - blur support for stages 
>> - WebP image format support 
>> - native embedded browser (Chromium) 
>> - 3D line and point primitives 
>> - injection support in FXML for custom controls 
>> - TableView improvements, aka. TableView2
>> 
>> (order of items does not imply priority)
>> 
>> Dirk
>> 

[jfx21u] RFR: 8319669: [macos14] Running any JavaFX app prints Secure coding warning

[Kevin Rushforth]

Clean backport of critical macOS 14 fix to 21u.

-

Commit messages:
 - Backport 986ec4f9b632f950111015be9445d0bae73042eb

Changes: https://git.openjdk.org/jfx21u/pull/28/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=28&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319669
  Stats: 22 lines in 2 files changed: 20 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx21u/pull/28.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/28/head:pull/28

PR: https://git.openjdk.org/jfx21u/pull/28

Re: My JavaFX Christmas Wishlist

[Nir Lisker]

>
> 3D line and point primitives
>

I filed https://bugs.openjdk.org/browse/JDK-8316398 for this already. As
noted, it requires a somewhat complex computation for intersections and
possibly for contains. If you would like to write these Mesh classes, like
the current TriangleMesh, I can write the rest.

removal of AWT
>

Isn't that *a lot* of work? All the image IO is AWT, no?

On Wed, Nov 15, 2023 at 10:48 AM Dirk Lemmermann 
wrote:

> Hi guys,
>
> I already mentioned this at the JavaFX BOF at DEVOXX and also posted this
> on Twitter but wanna make sure it gets the visibility it deserves:
>
> All I want for Christmas is … / what I think is needed for JavaFX going
> forward ...
>
> - removal of AWT
> - a tray API (tray icon)
> - undecorated interactive stage style
> - blur support for stages
> - WebP image format support
> - native embedded browser (Chromium)
> - 3D line and point primitives
> - injection support in FXML for custom controls
> - TableView improvements, aka. TableView2
>
> (order of items does not imply priority)
>
> Dirk
>
>

Re: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2]

[Nir Lisker]

On Thu, 9 Nov 2023 02:45:34 GMT, Michael Strauß  wrote:

>> Nir Lisker has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Addressed review comments
>
> modules/javafx.graphics/src/main/native-prism-d3d/D3DPhongMaterial.cc line 39:
> 
>> 37: for (int i = 0; i < map_type::num_map_types; i++) {
>> 38: map[i] = NULL;
>> 39: }
> 
> The size of the array is statically known, you could use `memset(map, 0, 
> sizeof(map))` (or, if you use `std::array`, it's simply `map.fill(NULL)`). 
> However, why is there a destructor at all? It doesn't seem to do anything 
> useful.

There is all sorts of unused code in the native layer. I think that there are 
whole classes that aren't needed. It will require another PR.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1394176878

Re: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2]

[Nir Lisker]

On Mon, 13 Nov 2023 01:23:13 GMT, Michael Strauß  wrote:

>> About 2, I tried that initially and got into problems iterating over the 
>> enum in `D3DMeshView.cc` line 293. How would you perform the iteration?
>
> You're right, there's no implicit conversion from scoped enums to integers. 
> While one could get very creative with C++, maybe just using an unscoped enum 
> is easier. You might want to prefix the constants with `MT_` or something 
> like that.

The constants are referred as `MapType::BUMP` etc. I don't see what adding a 
prefix will achieve.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1394169100

Integrated: 8319341: [Linux] Remove operation to show or hide children because it is unnecessary

[Thiago Milczarek Sayao]

On Thu, 2 Nov 2023 19:49:52 GMT, Thiago Milczarek Sayao  
wrote:

> Observed that the window manager takes care of showing and hiding children 
> because we set `gtk_window_set_transient_for`.
> 
> Works since Ubuntu 16.04.
> 
> This PR removes the code to show or hide children because it "duplicates" the 
> operation and might lead to unknown bugs.

This pull request has now been integrated.

Changeset: c6783b1d
Author:Thiago Milczarek Sayao 
URL:   
https://git.openjdk.org/jfx/commit/c6783b1d8626c883d157b567460cfe4972a963e2
Stats: 31 lines in 4 files changed: 0 ins; 31 del; 0 mod

8319341: [Linux] Remove operation to show or hide children because it is 
unnecessary

Reviewed-by: kcr, lkostyra

-

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

Re: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2]

[Lukasz Kostyra]

On Fri, 10 Nov 2023 15:24:13 GMT, Nir Lisker  wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/paint/TextureData.java
>>  line 12:
>> 
>>> 10:  */
>>> 11: // Here we can support mipmaps, wrapping modes (which exists internally 
>>> and can be pulled out), addressing modes etc.
>>> 12: public class TextureData {
>> 
>> 1. This type could be a record.
>> 2. There's no actual texture data (i.e. pixels) here, maybe a better name 
>> would be `SamplerParameters` or something like that.
>
> 1. Not when it will be promoted to public API. Adding record components 
> breaks backwards compatibility, so making this a record will not allow adding 
> more configuration later on. What might be possible is making it an interface 
> and using a record as an implementation.
> 2. I think that this class can go beyond sampler configurations. For example, 
> wrapping is a render state, not a sampler state. Maybe something more general 
> like "TextureParameters" can work.

I agree with 2. and I also think that `TextureParameters` would be a better 
name for this.

This should also follow in below method names and such (ex. 
`setTextureParameters()` instead of `setTextureData()`)

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1394084664

Re: RFR: 8092272: [D3D 3D] Need a robust 3D states management for texture [v2]

[Lukasz Kostyra]

On Fri, 10 Nov 2023 23:39:21 GMT, Nir Lisker  wrote:

>> Moves the filter setting of the samplers from the device parameters 
>> configuration to the use-site, allowing for dynamic changes in the sampler. 
>> This PR does internal plumbing work only to bring it close to the ES2 
>> pipeline. A followup PR will create the public API.
>> 
>> Summary of the changes:
>> * Created a new (internal for now) `TextureData` object that is intended to 
>> contain all the data of texture (map) of `PhongMaterial`, such as filters, 
>> addressing, wrapping mode, mipmaps etc. **This PR deals only with filters** 
>> as a starting point, more settings can be added later.
>> * Creates an update mechanism from the Java side material to the native D3D 
>> layer. The public API `PhoneMaterial` is *not* changed yet. The peer 
>> `NGPhongMaterial` is configured to receive update from the public 
>> `PhongMaterial` when the public API is created via new 
>> `ObjectProperty` properties.
>> * Small refactoring in the D3D layer with a new map types enum to control 
>> the texture settings more easily.
>> 
>> The JBS issue lists some regressions in a comment, but I couldn't reproduce 
>> them. It looks like the sampler settings needed to be added anywhere, and 
>> that was the easiest to do at the time. Now they were just moved.
>
> Nir Lisker has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Addressed review comments

Changes requested by lkostyra (Committer).

modules/javafx.graphics/src/main/native-prism-d3d/D3DMeshView.cc line 307:

> 305: if (context->state.wireframe != wireframe) {
> 306: context->state.wireframe = wireframe;
> 307: SUCCEEDED(device->SetRenderState(D3DRS_FILLMODE, wireframe ? 
> D3DFILL_WIREFRAME : D3DFILL_SOLID));

I think this formatting change should not be a part of this PR.

-

PR Review: https://git.openjdk.org/jfx/pull/1281#pullrequestreview-1731852656
PR Review Comment: https://git.openjdk.org/jfx/pull/1281#discussion_r1394152305

Re: RFR: 8319996: Update to GCC 13.2.0 on Linux [v2]

[Kevin Rushforth]

> This PR updates the compiler on Linux to GCC 13.2.0 (from 12.2.0) to match 
> JDK 22.
> 
> I've run headless and headful tests on Ubuntu 16.04, 20.04, and 22.04.

Kevin Rushforth has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into 8319996-gcc-13.2
 - 8319996: Update to GCC 13.2.0 on Linux

-

Changes: https://git.openjdk.org/jfx/pull/1286/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1286&range=01
  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1286.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1286/head:pull/1286

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

Integrated: 8319762: Update to Visual Studio 2022 version 17.6.5 on Windows

[Kevin Rushforth]

On Mon, 13 Nov 2023 18:47:14 GMT, Kevin Rushforth  wrote:

> This PR updates the compiler on Windows to Visual Studio 2022 17.6.5 (from 
> 17.5.0) to match JDK 22.
> 
> I've run headless and headful tests.

This pull request has now been integrated.

Changeset: 2d4b494e
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx/commit/2d4b494ea9cee1acd0407b9de61f0af9163f5d62
Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8319762: Update to Visual Studio 2022 version 17.6.5 on Windows

Reviewed-by: sykora, arapte

-

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

Integrated: 8319669: [macos14] Running any JavaFX app prints Secure coding warning

[Kevin Rushforth]

On Wed, 8 Nov 2023 15:04:44 GMT, Kevin Rushforth  wrote:

> Fix [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) as follows:
> 
> 1. Override the `NSApplicationDelegate` method 
> `applicationSupportsSecureRestorableState` in `GlassApplication` and return 
> `YES`. This silences the warning that FX applications now get on macOS 14.
> 2. Create and initialize an `NSApplicationFX` subclass of `NSApplication` 
> with no additional functionality. This stops AWT from overwriting the 
> NSApplicationDelegate (`GlassApplication`) that JavaFX sets during toolkit 
> initialization in the case where the AWT toolkit is used from a JavaFX 
> Application (e.g., when using SwingNode or other Swing functionality), and is 
> necessary in order to safely do the above. It also fixes other problems that 
> can result from the delegate being overwritten.
> 
> As noted in the bug report, this PR solves the following problems:
> 
> * Eliminates the "Secure coding is not enabled for restorable state" warning 
> on macOS 14
> * The assertion error reported in 
> [JDK-8318129](https://bugs.openjdk.org/browse/JDK-8318129)
> 
> * The FX application stops getting messages when the application is hidden, 
> deactivated, reactivated, etc. We currently don't do anything with these 
> messages once the application is running, but we might do so in the future.
> 
> * Probably related to the above, we sometimes get an odd behavior when trying 
> to hide an application on macOS 13 using the CMD-H key after the AWT Toolkit 
> has been initialized. Instead of hiding the window, it pops up a finder 
> window with a folder icon and a label that shows the version of Java.
> 
> * If AWT and FX return a different answer from their delegate's 
> `applicationSupportsSecureRestorableState` method, it will crash on macOS 
> 13.x.
> 
> This is the FX equivalent of 
> [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854) in AWT.

This pull request has now been integrated.

Changeset: 986ec4f9
Author:Kevin Rushforth 
URL:   
https://git.openjdk.org/jfx/commit/986ec4f9b632f950111015be9445d0bae73042eb
Stats: 22 lines in 2 files changed: 20 ins; 0 del; 2 mod

8319669: [macos14] Running any JavaFX app prints Secure coding warning

Reviewed-by: honkar, prr, kizune

-

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

Re: My JavaFX Christmas Wishlist

[Mark Raynsford]

On Wed, 2023-11-15 at 09:47 +0100, Dirk Lemmermann wrote:
> 
> All I want for Christmas is … / what I think is needed for JavaFX
> going forward ...

Is it sad that all I really want for Christmas is to be able to specify
that text under a certain size threshold shouldn't be antialiased? My
JavaFX console components look very blurry. :)

-- 
Mark Raynsford | https://www.io7m.com

Re: RFR: 8319341: [Linux] Remove operation to show or hide children because it is unnecessary

[Lukasz Kostyra]

On Thu, 2 Nov 2023 19:49:52 GMT, Thiago Milczarek Sayao  
wrote:

> Observed that the window manager takes care of showing and hiding children 
> because we set `gtk_window_set_transient_for`.
> 
> Works since Ubuntu 16.04.
> 
> This PR removes the code to show or hide children because it "duplicates" the 
> operation and might lead to unknown bugs.

LGTM

-

Marked as reviewed by lkostyra (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1279#pullrequestreview-1731848269

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v3]

[brunesto]

On Tue, 14 Nov 2023 21:31:59 GMT, Andy Goryachev  wrote:

>> brunesto has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   minor
>
> modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java 
> line 151:
> 
>> 149: focusedProperty().addListener(o -> {
>> 150: if (!isFocused()) {
>> 151: commitValueOnFocusLost();
> 
> minor: I don't know if it's worth creating a new method here - try .. catch 
> can simply be moved here.

I have removed the `commitValueOnFocusLost()` method.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1274#discussion_r1393920300

Re: RFR: 8303478: DatePicker throws uncatchable exception on tab out from garbled text [v4]

[brunesto]

> The fix prevents the DatePicker from losing focus if the date is not parsable.

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

  inlined

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1274/files
  - new: https://git.openjdk.org/jfx/pull/1274/files/decc7226..8bbdacc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1274&range=02-03

  Stats: 14 lines in 1 file changed: 4 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1274.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1274/head:pull/1274

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

My JavaFX Christmas Wishlist

[Dirk Lemmermann]

Hi guys,

I already mentioned this at the JavaFX BOF at DEVOXX and also posted this on 
Twitter but wanna make sure it gets the visibility it deserves:

All I want for Christmas is … / what I think is needed for JavaFX going forward 
...

- removal of AWT 
- a tray API (tray icon) 
- undecorated interactive stage style 
- blur support for stages 
- WebP image format support 
- native embedded browser (Chromium) 
- 3D line and point primitives 
- injection support in FXML for custom controls 
- TableView improvements, aka. TableView2

(order of items does not imply priority)

Dirk