Re: RFR: 8271865: SortedList::getViewIndex behaves not correctly for some index values

[Lukasz Kostyra]

On Sun, 24 Mar 2024 15:11:29 GMT, drmarmac  wrote:

> This PR adds the missing checks, as well as code documentation that an 
> IndexOutOfBoundsException may be thrown.

LGTM

-

Marked as reviewed by lkostyra (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1432#pullrequestreview-2016405149

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

[John Hendrikx]

On Mon, 22 Apr 2024 16:52:16 GMT, Andy Goryachev  wrote:

> 2. resolve the problems with the fonts (could we pick the font(s) that are 
> available via some utility method?)

I already left a comment on this before, see here: 
https://github.com/openjdk/jfx/pull/1236#issuecomment-1939200760

The `TextLayoutTest` tests the reflow logic in `PrismTextLayout`. The code 
under test is not platform or font specific, it doesn't have different branches 
for different fonts or platforms.  Adding more fonts for specific platforms 
therefore would exercise the exact same code paths twice without a tangible 
benefit.  If the tests fail for Tahoma, the same tests would fail for Monaco.  
If it fails on one platform, the exact same failures would occur on another 
platform.

Duplicating the tests for a new font would require running the tests, checking 
all the exact metric values, and copying those to the duplicated test.  Adding 
new tests becomes more of a maintenance burden as now two tests need to be 
maintained and updated (both would fail if one fails).

Ideally, these tests should be real Unit tests, with a Font definition stored 
in `src/test/resources` and without requiring the FX platform to run -- the 
tested code is just some maths after all.  However, FX is insufficiently 
abstracted to allow for loading certain classes without the platform running, 
and storing a specific font in the repository may not be possible due to 
licensing issues (even just to check IF there are licensing issues).

-

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2071460931

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

[John Hendrikx]

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

John Hendrikx has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains 26 commits:

 - Make some tests conditional on platform
 - Fix typo
 - Merge branch 'master' of https://git.openjdk.org/jfx into 
feature/wrapped-aligned-text-rendering
 - Change test to use the more common Arial font and add assumptions
 - Add failing test to confirm build is running the TextLayoutTest
 - Fix test description
 - Improve test
   
   - Test TextSpans (rich text) and String text (plain text)
   - Add test cases for leading spaces, tabs
   - Fix justified test to take hard wrapped lines into account correctly
 - Convert class to record
 - Add some clarifying documentation
 - Do not collapse trailing spaces of last line (where no soft wrap occurs)
 - ... and 16 more: https://git.openjdk.org/jfx/compare/5182ea16...c3ca720c

-

Changes: https://git.openjdk.org/jfx/pull/1236/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=15
  Stats: 1007 lines in 7 files changed: 762 ins; 231 del; 14 mod
  Patch: https://git.openjdk.org/jfx/pull/1236.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236

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

Re: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]

[Karthik P K]

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv  wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which 
>> go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by 
>> ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the 
>> node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the 
>> ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

Marked as reviewed by kpk (Committer).

Created [JDK-8330859](https://bugs.openjdk.org/browse/JDK-8330859) for tracking 
focus handling issue in toolbar

-

PR Review: https://git.openjdk.org/jfx/pull/1434#pullrequestreview-2016271085
PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2071442595

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

[John Hendrikx]

On Mon, 12 Feb 2024 10:00:57 GMT, Karthik P K  wrote:

>> John Hendrikx has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Change test to use the more common Arial font and add assumptions
>
> I ran the tests in my Mac system with macOS 14.3 and found 2 tests are 
> failing with following error:
> 
> 
> TextLayoutTest > caseTest(Case) > 
> test.com.sun.javafx.text.TextLayoutTest.caseTest(Case)[10] FAILED
> org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 
> 0 for Parameters[text=The quick brown लोमड़ी jumps over the lazy कुत्ता, 
> wrapWidth=160.0, lineWidths=[158.1914, 93.134766]] ==> expected:  { minX:0.0, minY:-10.863281, maxX:158.1914, maxY:2.9355469} (w:158.1914, 
> h:13.798828)> but was:  maxX:155.3047, maxY:2.9355469} (w:155.3047, h:13.798828)>
> at 
> app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> at 
> app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
> at 
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
> at 
> app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
> at 
> app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:501)
> 
> TextLayoutTest > caseTest(Case) > 
> test.com.sun.javafx.text.TextLayoutTest.caseTest(Case)[11] FAILED
> org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 
> 0 for Parameters[text=The quick brown लोमड़ी jumps   over the lazy 
> कुत्ता, wrapWidth=160.0, lineWidths=[158.1914, 93.134766]] ==> expected: 
>  (w:158.1914, h:13.798828)> but was:  maxX:155.3047, maxY:2.9355469} (w:155.3047, h:13.798828)>
> at 
> app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
> at 
> app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
> at 
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
> at 
> app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
> at 
> app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:501)
> 
> TextLayoutTest > fixedComplexTestsToEnsureNoFurtherRegressions() SKIPPED
> 
> TextLayoutTest > complexTestsThatAreBrokenSince2013() SKIPPED
> 
> 
> The failing tests are SOFT_WRAP_WITH_COMPLEX_TEXT and 
> SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_SPACE.
> 
> Added a minor comment inline as well.

@karthikpandelu @kevinrushforth @andy-goryachev-oracle 

I split the failing Mac tests into Windows and Mac variants.  However, the Mac 
specific tests probably still fail. If one of you could post the test errors, I 
can fix the values used as I don't have a Mac to test on.

-

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2071440980

Re: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v3]

[Alexander Matveev]

On Mon, 22 Apr 2024 15:05:07 GMT, n-gabe  wrote:

>> There is a ConcurrentModificationException in MediaPlayer when removing a 
>> MediaView from it. The root cause is that you can't iterate over a HashSet 
>> with for (WeakReference vref : viewRefs) and removing items from 
>> the collection by viewRefs.remove(vref); within this loop.
>
> n-gabe has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   Remove needless copyright year

Looks good.

-

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1377#pullrequestreview-2015678699

Re: Wayland

[Nir Lisker]

Not sure it helps with warmup, but marking a foreign function as critical
can improve performance:
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean)
.

On Mon, Apr 22, 2024 at 10:02 PM Philip Race  wrote:

> No, it wasn't. I didn't even use jextracted code.
> The startup cost is around initialisation of FFM - around 70 ms (IIRC)
> overhead on my MacBook
> Then creation of VarHandles and MethodHandles - 2-5 ms each is what I
> measured, so do these lazily if you can.
> And warmup cost is that it takes about 1 iterations to get code fully
> compiled.
>
> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>  intx CompileThreshold =
> 1  {pd product} {default}
> double CompileThresholdScaling  =
> 1.00  {product} {default}
> uintx IncreaseFirstTierCompileThresholdAt  =
> 50{product} {default}
>  intx Tier2CompileThreshold=
> 0 {product} {default}
>  intx Tier3CompileThreshold=
> 2000  {product} {default}
>  intx Tier4CompileThreshold=
> 15000 {product} {default}
>
> -phil.
>
>
> On 4/22/24 11:45 AM, Thiago Milczarek Sayão wrote:
>
> I think the startup time might be related to all static symbol lookups.
> So I'm manually including just what is needed:
>
> jextract --output src -t com.sun.glass.wayland.extracted \
>   --header-class-name GlassWayland \
>   `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
>   `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \
>glass-wayland.h \
>--include-function xdp_portal_initable_new \
>--include-function xdp_session_close \
>--include-function xdp_portal_open_file \
>--include-function xdp_portal_open_file_finish \
>--include-function g_object_unref \
>--include-function g_timeout_add \
>--include-function g_add_idle \
>--include-function g_main_loop_run \
>--include-function g_main_loop_new \
>--include-function g_main_loop_ref \
>--include-function g_main_loop_unref \
>--include-function g_main_loop_quit \
>--include-function g_settings_new \
>--include-function g_settings_get_int \
>--include-function wl_display_connect \
>--include-function wl_display_disconnect \
>--include-function wl_display_roundtrip \
>--include-function wl_display_dispatch_pending \
>--include-typedef GAsyncReadyCallback \
>--include-typedef GSourceFunc \
>--include-typedef GError
>
>
> Em seg., 22 de abr. de 2024 às 13:24, Philip Race 
> escreveu:
>
>> As a reminder, using FFM will require all FX *applications* to specify
>> --enable-native-access on the command line
>> Although this is likely coming to JNI soon too.
>>
>> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>>
>> But one thing to watch out for with FFM is startup + warm up time.
>> I struggled a lot with that in using FFM for just one library in the
>> java.desktop module.
>>
>> -phil
>>
>> On 4/22/24 9:12 AM, Nir Lisker wrote:
>>
>> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the
>> N-1 rule.
>>
>> On Mon, Apr 22, 2024 at 6:03 PM Nir Lisker  wrote:
>>
>>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
>>> with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
>>> very useful for JavaFX, but was told we shouldn't since it's not an LTS
>>> version.
>>>
>>> I have no idea how long the work on Wayland will take including the code
>>> review (a rather long process), but you should be able to request code
>>> reviews with FFM and have it ready for integration by Java 25.
>>>
>>> On Mon, Apr 22, 2024 at 5:49 PM Thiago Milczarek Sayão <
>>> thiago.sa...@gmail.com> wrote:
>>>
 I was just experimenting, but it seems to be less work than going with
 JNI.
 If I am correct, the next Java LTS will be 25, which will be required
 on JavaFX 29 to be released on September/29.

 It's 7 years - that's really too much.

 Maybe it's still worthwhile to prototype using FFM and then port
 everything to JNI.

 -- Thiago.


 Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth <
 kevin.rushfo...@oracle.com> escreveu:

> Note also that we cannot use Panama in the JavaFX internals yet, since
> the minimum version of the JDK is 21.
>
> -- Kevin
>
>
> On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
> > Hi,
> >
> > I did a small test app to explore Wayland client and portals (for
> > Robot and dialogs such as file open/save).
> >
> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
> >
>

Re: Wayland

[Philip Race]

No, it wasn't. I didn't even use jextracted code.
The startup cost is around initialisation of FFM - around 70 ms (IIRC) 
overhead on my MacBook
Then creation of VarHandles and MethodHandles - 2-5 ms each is what I 
measured, so do these lazily if you can.
And warmup cost is that it takes about 1 iterations to get code 
fully compiled.


java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
 intx CompileThreshold = 
1  {pd product} {default}
    double CompileThresholdScaling  = 
1.00  {product} {default}
    uintx IncreaseFirstTierCompileThresholdAt  = 
50    {product} {default}
 intx Tier2CompileThreshold    = 
0 {product} {default}
 intx Tier3CompileThreshold    = 
2000  {product} {default}
 intx Tier4CompileThreshold    = 
15000 {product} {default}


-phil.


On 4/22/24 11:45 AM, Thiago Milczarek Sayão wrote:

I think the startup time might be related to all static symbol lookups.
So I'm manually including just what is needed:
jextract --output src -t com.sun.glass.wayland.extracted \
   --header-class-name GlassWayland \
   `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client`  \
   `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client`  \
glass-wayland.h \
--include-function xdp_portal_initable_new \
--include-function xdp_session_close \
--include-function xdp_portal_open_file \
--include-function xdp_portal_open_file_finish \
--include-function g_object_unref \
--include-function g_timeout_add \
--include-function g_add_idle \
--include-function g_main_loop_run \
--include-function g_main_loop_new \
--include-function g_main_loop_ref \
--include-function g_main_loop_unref \
--include-function g_main_loop_quit \
--include-function g_settings_new \
--include-function g_settings_get_int \
--include-function wl_display_connect \
--include-function wl_display_disconnect \
--include-function wl_display_roundtrip \
--include-function wl_display_dispatch_pending \
--include-typedef GAsyncReadyCallback \
--include-typedef GSourceFunc \
--include-typedef GError

Em seg., 22 de abr. de 2024 às 13:24, Philip Race 
 escreveu:


As a reminder, using FFM will require all FX *applications* to
specify --enable-native-access on the command line
Although this is likely coming to JNI soon too.

https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html

But one thing to watch out for with FFM is startup + warm up time.
I struggled a lot with that in using FFM for just one library in
the java.desktop module.

-phil

On 4/22/24 9:12 AM, Nir Lisker wrote:

Sorry, we bumped to Java 21 in JavaFX 22 I think since we
preserve the N-1 rule.

On Mon, Apr 22, 2024 at 6:03 PM Nir Lisker  wrote:

I think that we'll be able to bump to Java 25 in JavaFX 25,
like we did with 21. I suggested initially to bump to Java 22
exactly for FFM as it's very useful for JavaFX, but was told
we shouldn't since it's not an LTS version.

I have no idea how long the work on Wayland will take
including the code review (a rather long process), but you
should be able to request code reviews with FFM and have it
ready for integration by Java 25.

On Mon, Apr 22, 2024 at 5:49 PM Thiago Milczarek Sayão
 wrote:

I was just experimenting, but it seems to be less work
than going with JNI.
If I am correct, the next Java LTS will be 25, which will
be required on JavaFX 29 to be released on September/29.

It's 7 years - that's really too much.

Maybe it's still worthwhile to prototype using FFM and
then port everything to JNI.

-- Thiago.


Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth
 escreveu:

Note also that we cannot use Panama in the JavaFX
internals yet, since
the minimum version of the JDK is 21.

-- Kevin


On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
> Hi,
>
> I did a small test app to explore Wayland client
and portals (for
> Robot and dialogs such as file open/save).
>
>
https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>
> It seems it will work as a glass backend, but some
walls will be hit
> on the way :)
>
> I have t

Re: Wayland

[Thiago Milczarek Sayão]

I think the startup time might be related to all static symbol lookups.
So I'm manually including just what is needed:

jextract --output src -t com.sun.glass.wayland.extracted \
  --header-class-name GlassWayland \
  `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
  `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \
   glass-wayland.h \
   --include-function xdp_portal_initable_new \
   --include-function xdp_session_close \
   --include-function xdp_portal_open_file \
   --include-function xdp_portal_open_file_finish \
   --include-function g_object_unref \
   --include-function g_timeout_add \
   --include-function g_add_idle \
   --include-function g_main_loop_run \
   --include-function g_main_loop_new \
   --include-function g_main_loop_ref \
   --include-function g_main_loop_unref \
   --include-function g_main_loop_quit \
   --include-function g_settings_new \
   --include-function g_settings_get_int \
   --include-function wl_display_connect \
   --include-function wl_display_disconnect \
   --include-function wl_display_roundtrip \
   --include-function wl_display_dispatch_pending \
   --include-typedef GAsyncReadyCallback \
   --include-typedef GSourceFunc \
   --include-typedef GError


Em seg., 22 de abr. de 2024 às 13:24, Philip Race 
escreveu:

> As a reminder, using FFM will require all FX *applications* to specify
> --enable-native-access on the command line
> Although this is likely coming to JNI soon too.
>
> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>
> But one thing to watch out for with FFM is startup + warm up time.
> I struggled a lot with that in using FFM for just one library in the
> java.desktop module.
>
> -phil
>
> On 4/22/24 9:12 AM, Nir Lisker wrote:
>
> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the N-1
> rule.
>
> On Mon, Apr 22, 2024 at 6:03 PM Nir Lisker  wrote:
>
>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
>> with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
>> very useful for JavaFX, but was told we shouldn't since it's not an LTS
>> version.
>>
>> I have no idea how long the work on Wayland will take including the code
>> review (a rather long process), but you should be able to request code
>> reviews with FFM and have it ready for integration by Java 25.
>>
>> On Mon, Apr 22, 2024 at 5:49 PM Thiago Milczarek Sayão <
>> thiago.sa...@gmail.com> wrote:
>>
>>> I was just experimenting, but it seems to be less work than going with
>>> JNI.
>>> If I am correct, the next Java LTS will be 25, which will be required on
>>> JavaFX 29 to be released on September/29.
>>>
>>> It's 7 years - that's really too much.
>>>
>>> Maybe it's still worthwhile to prototype using FFM and then port
>>> everything to JNI.
>>>
>>> -- Thiago.
>>>
>>>
>>> Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> escreveu:
>>>
 Note also that we cannot use Panama in the JavaFX internals yet, since
 the minimum version of the JDK is 21.

 -- Kevin


 On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
 > Hi,
 >
 > I did a small test app to explore Wayland client and portals (for
 > Robot and dialogs such as file open/save).
 >
 > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
 >
 > It seems it will work as a glass backend, but some walls will be hit
 > on the way :)
 >
 > I have tried to use jextract (from project Panama) to work directly
 > with java, but it seems it does not support wl_ types.
 >
 > -- Thiago.


>

Re: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]

[Andy Goryachev]

On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev  wrote:

>> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to
>> 
>> - ListView
>> - TreeView
>> - TableView
>> - TreeTableView
>> 
>> to support keyboard-only horizontal scrolling.  The main reason for the 
>> change is to improve accessibility.
>> 
>> **NOTE: For controls in right-to-left orientation, the direction is 
>> reversed.**
>> 
>> As far as I can tell, these key combinations do not interfere with editing.
>> 
>> The proposed solution can be further optimized by adding a public method to 
>> the VirtualFlow class, something like
>> 
>> 
>> public void horizontalUnitScroll(boolean right);
>> 
>> 
>> Q: Does this change require a CSR to explain the change in the controls' 
>> behavior?  We don't yet have the key bindings documented in 
>> /doc-files/behavior
>> 
>> Note:
>> Jenkins headful test passed on all mac configurations, failed on all linux 
>> configurations (master branch failed also, so it is test issue), while 
>> windows configuration is not yet available.
>
> Andy Goryachev 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 14 additional 
> commits since the last revision:
> 
>  - tests
>  - cleanup
>  - node orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - table view behavior
>  - tree view behavior
>  - list view behavior
>  - orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - Merge branch 'master' into 8313138.horizontal
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/8433be17...5bae5e7a

@aghaisas and @arapte could you also review this please?

-

PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2070355489

Re: RFR: 8092102: Labeled: truncated property [v9]

[Andy Goryachev]

On Wed, 10 Apr 2024 21:25:10 GMT, Andy Goryachev  wrote:

>> Adds **Labeled.textTruncated** property which indicates when the text is 
>> visually truncated (and the ellipsis string is inserted) in order to fit the 
>> available width.
>> 
>> The new property reacts to changes in the following properties:
>> - ellipsisString
>> - font
>> - height
>> - text
>> - width
>> - wrapText
>> 
>> I don't think it's worth creating a headful test (headless won't work) due 
>> to relative simplicity of the code.
>> 
>> **Alternative**
>> 
>> The desired functionality can be just as easily achieved on an application 
>> level, by adding a similar property to a subclass.  What is the benefit of 
>> adding this functionality to the core?
>> 
>> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as 
>> well) lives by different rules (TableCellSkinBase:152, 
>> TreeTableCellSkin:126).  The consequence of this is that the new 
>> functionality **cannot** be fully implemented with the public APIs alone.
>> 
>> **See Also**
>> 
>> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow 
>> for tooltip when cell text is truncated
>> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show 
>> Tooltip only when text is shown with ellipsis (...)
>
> Andy Goryachev has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 15 commits:
> 
>  - missing )
>  - review comments
>  - Merge branch 'master' into 8092102.truncated
>  - add exports
>  - added unit tests
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - test
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - Merge branch 'master' into 8092102.truncated
>  - labeled helper
>  - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e

@aghaisas could you take a look at this PR please?

-

PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-2070351050

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

[Andy Goryachev]

On Sat, 10 Feb 2024 17:24:17 GMT, John Hendrikx  wrote:

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

This PR is very close to be ready.  It looks like there are only two things 
that block it:
1. merge conflict
2. resolve the problems with the fonts (could we pick the font(s) that are 
available via some utility method?)

-

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2070214332

Re: Wayland

[Philip Race]

As a reminder, using FFM will require all FX *applications* to specify 
--enable-native-access on the command line

Although this is likely coming to JNI soon too.

https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html

But one thing to watch out for with FFM is startup + warm up time.
I struggled a lot with that in using FFM for just one library in the 
java.desktop module.


-phil

On 4/22/24 9:12 AM, Nir Lisker wrote:
Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the 
N-1 rule.


On Mon, Apr 22, 2024 at 6:03 PM Nir Lisker  wrote:

I think that we'll be able to bump to Java 25 in JavaFX 25, like
we did with 21. I suggested initially to bump to Java 22 exactly
for FFM as it's very useful for JavaFX, but was told we shouldn't
since it's not an LTS version.

I have no idea how long the work on Wayland will take including
the code review (a rather long process), but you should be able to
request code reviews with FFM and have it ready for integration by
Java 25.

On Mon, Apr 22, 2024 at 5:49 PM Thiago Milczarek Sayão
 wrote:

I was just experimenting, but it seems to be less work than
going with JNI.
If I am correct, the next Java LTS will be 25, which will be
required on JavaFX 29 to be released on September/29.

It's 7 years - that's really too much.

Maybe it's still worthwhile to prototype using FFM and then
port everything to JNI.

-- Thiago.


Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth
 escreveu:

Note also that we cannot use Panama in the JavaFX
internals yet, since
the minimum version of the JDK is 21.

-- Kevin


On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
> Hi,
>
> I did a small test app to explore Wayland client and
portals (for
> Robot and dialogs such as file open/save).
>
>
https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>
> It seems it will work as a glass backend, but some walls
will be hit
> on the way :)
>
> I have tried to use jextract (from project Panama) to
work directly
> with java, but it seems it does not support wl_ types.
>
> -- Thiago.

Re: Wayland

[Nir Lisker]

Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the N-1
rule.

On Mon, Apr 22, 2024 at 6:03 PM Nir Lisker  wrote:

> I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
> with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
> very useful for JavaFX, but was told we shouldn't since it's not an LTS
> version.
>
> I have no idea how long the work on Wayland will take including the code
> review (a rather long process), but you should be able to request code
> reviews with FFM and have it ready for integration by Java 25.
>
> On Mon, Apr 22, 2024 at 5:49 PM Thiago Milczarek Sayão <
> thiago.sa...@gmail.com> wrote:
>
>> I was just experimenting, but it seems to be less work than going with
>> JNI.
>> If I am correct, the next Java LTS will be 25, which will be required on
>> JavaFX 29 to be released on September/29.
>>
>> It's 7 years - that's really too much.
>>
>> Maybe it's still worthwhile to prototype using FFM and then port
>> everything to JNI.
>>
>> -- Thiago.
>>
>>
>> Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> escreveu:
>>
>>> Note also that we cannot use Panama in the JavaFX internals yet, since
>>> the minimum version of the JDK is 21.
>>>
>>> -- Kevin
>>>
>>>
>>> On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
>>> > Hi,
>>> >
>>> > I did a small test app to explore Wayland client and portals (for
>>> > Robot and dialogs such as file open/save).
>>> >
>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>> >
>>> > It seems it will work as a glass backend, but some walls will be hit
>>> > on the way :)
>>> >
>>> > I have tried to use jextract (from project Panama) to work directly
>>> > with java, but it seems it does not support wl_ types.
>>> >
>>> > -- Thiago.
>>>
>>>

Re: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v7]

[Kevin Rushforth]

On Fri, 19 Apr 2024 18:27:12 GMT, Oliver Kopp  wrote:

> > I think you need to add
> 
> The mentioned issue is fixed. Now, I get
> 
> ```
> java.lang.UnsatisfiedLinkError: 'void 
> com.sun.glass.ui.win.WinTextRangeProvider._initIDs()'
>   at 
> javafx.graphics@23-internal/com.sun.glass.ui.win.WinTextRangeProvider._initIDs(Native
>  Method)
> ```

Ah, right, sorry for not noticing this earlier. You cannot access glass from 
unit tests in the `javafx.graphics` module. Those tests use the StubToolkit 
which bypasses glass. You will need to move the test to the system tests 
project under `tests/system/src/test/java/`. Those will use the real toolkit 
and the glass libraries will be loaded for you. You will need to explicitly 
start the toolkit (via `Platform.startup` or a call to a utility method to do 
the same) in an `@BeforeAll` method.

@andy-goryachev-oracle or @arapte should be able to help you with the 
transition. You would still use the same shim class, which should remain under 
`javafx.graphics`.

-

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2069976918

Re: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]

[Kevin Rushforth]

On Mon, 22 Apr 2024 15:31:25 GMT, Andy Goryachev  wrote:

> let's try this one:
> 
> Reviewer: @karthikpandelu

Yep.

There is no Skara command to request a review from someone. The `/reviewer` is 
use to credit someone who has not done a review in GitHub (and is not expected 
to), but who has reviewed it via some other means. Such an extra reviewer will 
be credited in the meta-data, but their review will not "count" for the minimum 
number of reviewers.

-

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2069948824

Re: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]

[Andy Goryachev]

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv  wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which 
>> go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by 
>> ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the 
>> node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the 
>> ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

let's try this one:

Reviewer: @karthikpandelu

-

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2069907633

Re: RFR: 8330462: StringIndexOutOfBoundException when typing anything into TextField [v9]

[Andy Goryachev]

On Sat, 20 Apr 2024 14:50:15 GMT, Oliver Kopp  wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java
>>  line 116:
>> 
>>> 114: return fixedMaxEnd;
>>> 115: }
>>> 116: }
>> 
>> Frankly, I have hard time understanding this code (maybe a comment 
>> describing what the method does and why might help).
>> 
>> It looks to me that all we need to do is to guard against a very large 
>> maxLength (which for some reason called here 'requestedSteps' which does not 
>> seem right - should the last two arguments be swapped?)
>> 
>> 
>> public static int getEndIndex(int start, int length, int maxLength) {
>>   if(length > maxLength) {
>> length = maxLength;
>>   }
>>   return start + length;
>> }
>> 
>> 
>> That is, I assume we don't have to worry about start + fixedLength 
>> overflowing, we just need to make sure we don't go beyond maxLength.  Or is 
>> my assumption wrong and start can be negative, or start+fixedLength might 
>> overflow?
>
> Smalltalk 1: I thought this was easier to understand than some byte code 
> generation in the JVM. 😅  (For me being an outsider, JDK and JavaFX are 
> "close" related somehow - sorry for that!!)
> 
> Smalltalk 2: Sometimes, the code for "Calculate a + b, but return c at most" 
> is pretty hard to craft.
> 
> Smalltalk 3: The whole checks stem from possible "out of range" values, 
> especially from the other functions mentioned at 
> https://github.com/openjdk/jfx/pull/1442/#discussion_r1570948582. That was 
> too defensive, as only `requestedSteps` AKA `length` can be out of range.
> 
> OK, I seem to have understood "Also, this doesn't follow the usual pattern of 
> checking for integer overflow" by Kevin wrong. I googled the Java way of the 
> usual pattern for Integer overflow. Since Java 8, there is `Math.addExact`. I 
> thought, that this was meant. -- I found it from 
> https://stackoverflow.com/a/3001879/873282. (Inlining the code of 
> `Math.addExact` seems to have negative performance impact.)
> 
> The proposed code works OKish if strings are not in length area of 
> Integer.MAX_VALUE. I think, we can safely assume that. - It however returns 
> more characters if start is greater then 0. Example: I request start 2, 
> length of 5, but maximum end index  of 3. Then 3 should be returned, not 7.
> 
> ---
> 
> I changed the code accordingly. Also added a comment when an overflow might 
> happen. From the discussion here, it seems, we can ignore these cases.
> 
> Note that the old code returned `0` if `start` was negative. New might return 
> some negative value if `start` is negative enough. However, did not seem to 
> happen, because otherwise, IndexOutOfBounds exceptions might have been seen.

Thank you!  Somehow the code looks much cleaner and clearer now.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1574951836

Re: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]

[Andy Goryachev]

On Mon, 22 Apr 2024 08:34:34 GMT, eduardsdv  wrote:

> closing the overflow-menu with the ESC key when the currently focused Node 
> (e.g. ListView) processes the ESC itself.

On macOS, option-ESC closes the overflow menu.

-

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2069855676

Re: [External] : Re: Wayland

[Kevin Rushforth]

Your math is a bit off: it's 2 years from now, not 7. We recently bumped 
the minimum for JavaFX 23 to JDK 21. Two years from now, we will bump 
the minimum for JavaFX 27 to JDK 25.


We might consider bumping it even earlier to a non-LTS, as an exception 
to our general practice, specifically to enable Panama, given the need 
to get away from sun.misc.Unsafe (used by Marlin), so there is a 
possibility that it could be less than 2 years. That will require a some 
discussion.


-- Kevin


On 4/22/2024 7:49 AM, Thiago Milczarek Sayão wrote:
I was just experimenting, but it seems to be less work than going with 
JNI.
If I am correct, the next Java LTS will be 25, which will be required 
on JavaFX 29 to be released on September/29.


It's 7 years - that's really too much.

Maybe it's still worthwhile to prototype using FFM and then port 
everything to JNI.


-- Thiago.


Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth 
 escreveu:


Note also that we cannot use Panama in the JavaFX internals yet,
since
the minimum version of the JDK is 21.

-- Kevin


On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
> Hi,
>
> I did a small test app to explore Wayland client and portals (for
> Robot and dialogs such as file open/save).
>
> https://github.com/tsayao/wayland-test/blob/main/wayland-test.c


>
> It seems it will work as a glass backend, but some walls will be
hit
> on the way :)
>
> I have tried to use jextract (from project Panama) to work directly
> with java, but it seems it does not support wl_ types.
>
> -- Thiago.

Re: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v2]

[n-gabe]

On Mon, 22 Apr 2024 13:52:39 GMT, Kevin Rushforth  wrote:

>> n-gabe has updated the pull request incrementally with one additional commit 
>> since the last revision:
>> 
>>   Update Copyright
>
> modules/javafx.media/src/main/java/javafx/scene/media/MediaPlayer.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2010, 2022, 2024, Oracle and/or its affiliates. All 
>> rights reserved.
> 
> Copyright lines must have exactly one or two years. Please remove `, 2022`

Oh sorry, I wasn't aware of that. Now it is removed.

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1377#discussion_r1574914527

Re: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v3]

[n-gabe]

> There is a ConcurrentModificationException in MediaPlayer when removing a 
> MediaView from it. The root cause is that you can't iterate over a HashSet 
> with for (WeakReference vref : viewRefs) and removing items from 
> the collection by viewRefs.remove(vref); within this loop.

n-gabe has updated the pull request incrementally with one additional commit 
since the last revision:

  Remove needless copyright year

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1377/files
  - new: https://git.openjdk.org/jfx/pull/1377/files/bdc1af6e..89c56d29

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

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

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

Re: Wayland

[Nir Lisker]

I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
very useful for JavaFX, but was told we shouldn't since it's not an LTS
version.

I have no idea how long the work on Wayland will take including the code
review (a rather long process), but you should be able to request code
reviews with FFM and have it ready for integration by Java 25.

On Mon, Apr 22, 2024 at 5:49 PM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:

> I was just experimenting, but it seems to be less work than going with JNI.
> If I am correct, the next Java LTS will be 25, which will be required on
> JavaFX 29 to be released on September/29.
>
> It's 7 years - that's really too much.
>
> Maybe it's still worthwhile to prototype using FFM and then port
> everything to JNI.
>
> -- Thiago.
>
>
> Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth <
> kevin.rushfo...@oracle.com> escreveu:
>
>> Note also that we cannot use Panama in the JavaFX internals yet, since
>> the minimum version of the JDK is 21.
>>
>> -- Kevin
>>
>>
>> On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
>> > Hi,
>> >
>> > I did a small test app to explore Wayland client and portals (for
>> > Robot and dialogs such as file open/save).
>> >
>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>> >
>> > It seems it will work as a glass backend, but some walls will be hit
>> > on the way :)
>> >
>> > I have tried to use jextract (from project Panama) to work directly
>> > with java, but it seems it does not support wl_ types.
>> >
>> > -- Thiago.
>>
>>

Re: Wayland

[Thiago Milczarek Sayão]

I was just experimenting, but it seems to be less work than going with JNI.
If I am correct, the next Java LTS will be 25, which will be required on
JavaFX 29 to be released on September/29.

It's 7 years - that's really too much.

Maybe it's still worthwhile to prototype using FFM and then port everything
to JNI.

-- Thiago.


Em seg., 22 de abr. de 2024 às 11:21, Kevin Rushforth <
kevin.rushfo...@oracle.com> escreveu:

> Note also that we cannot use Panama in the JavaFX internals yet, since
> the minimum version of the JDK is 21.
>
> -- Kevin
>
>
> On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:
> > Hi,
> >
> > I did a small test app to explore Wayland client and portals (for
> > Robot and dialogs such as file open/save).
> >
> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
> >
> > It seems it will work as a glass backend, but some walls will be hit
> > on the way :)
> >
> > I have tried to use jextract (from project Panama) to work directly
> > with java, but it seems it does not support wl_ types.
> >
> > -- Thiago.
>
>

Re: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v2]

[Kevin Rushforth]

On Sun, 21 Apr 2024 14:39:46 GMT, n-gabe  wrote:

>> There is a ConcurrentModificationException in MediaPlayer when removing a 
>> MediaView from it. The root cause is that you can't iterate over a HashSet 
>> with for (WeakReference vref : viewRefs) and removing items from 
>> the collection by viewRefs.remove(vref); within this loop.
>
> n-gabe has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   Update Copyright

modules/javafx.media/src/main/java/javafx/scene/media/MediaPlayer.java line 2:

> 1: /*
> 2:  * Copyright (c) 2010, 2022, 2024, Oracle and/or its affiliates. All 
> rights reserved.

Copyright lines must have exactly one or two years. Please remove `, 2022`

-

PR Review Comment: https://git.openjdk.org/jfx/pull/1377#discussion_r1574796815

Re: Wayland

[Kevin Rushforth]

Note also that we cannot use Panama in the JavaFX internals yet, since 
the minimum version of the JDK is 21.


-- Kevin


On 4/21/2024 10:51 AM, Thiago Milczarek Sayão wrote:

Hi,

I did a small test app to explore Wayland client and portals (for 
Robot and dialogs such as file open/save).


https://github.com/tsayao/wayland-test/blob/main/wayland-test.c

It seems it will work as a glass backend, but some walls will be hit 
on the way :)


I have tried to use jextract (from project Panama) to work directly 
with java, but it seems it does not support wl_ types.


-- Thiago.

Re: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]

[eduardsdv]

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv  wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which 
>> go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by 
>> ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the 
>> node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the 
>> ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

I tested the focus handling with the MonkeyTest app. I also tested it with a 
ListView in the toolbar (see PR: 
https://github.com/andy-goryachev-oracle/MonkeyTest/pull/2).
All components are reachable with the mouse and the keyboard.
I found only one issue with closing the overflow-menu with the ESC key when the 
currently focused Node (e.g. ListView) processes the ESC itself. This issue is 
also reproducible in the version before PR.

-

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2068811858