Re: JavaFX on Windows ARM

[Philip Race]

Since we at Oracle don't have or produce Windows ARM JDK binaries,
I don't see a road to anyone here being able to work on it for the 
forseeable future.


-phil.

On 6/9/24 2:51 AM, Johan Vos wrote:

Hi Christopher,

The question about Windows. AArch64 increasingly pops up. We did some 
local tests, and the basis modules builds out-of-the-box, but media 
and web modules require more work.
It's definitely helpful that there are GA runners for it now -- 
although the GA is just a basic check.
It would be good to know if someone is compiling media/webkit for 
Win/AArch64.


- Johan


On Sat, Jun 8, 2024 at 10:01 PM Christopher Schnick 
 wrote:


Hello there,

with the latest releases of ARM hardware with Windows I just
wanted to
ask whether there are any plans on officially supporting JavaFX for
Windows on ARM.

There are also now GitHub runners for Windows and Linux that run
on ARM
(see

https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/),

so things have definitely gotten easier with regards to actually
realizing a CI/CD pipeline.

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

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: Proposal: JavaFX Incubator Modules

[Philip Race]

W.r.t to (3) perhaps we could include in the write up an expectation 
that continued incubation implies continued updates.
Meaning if there are no updates in a release then that either means it 
is ready to be final next time round, or that the
author is no longer actively pursuing it and this should inform the 
Project Lead as to what action should be taken next.


-phil.

On 2/21/24 1:55 PM, Kevin Rushforth wrote:

These are all good points.

1. I agree. This seems like a good idea for all the reasons you mention.

2. I'll add the additional information. And I like your suggestion to 
require a JEP (*) to either drop or finalize an incubating feature.


3. Yes, I was deliberately vague on what constitutes a reasonable 
amount of time. Given that we are changing the default to 
"re-incubate" it does make sense to have a "soft timeout" so 
incubating features don't incubate forever without an intentional 
action to keep them alive.


I'll update the proposal accordingly.

Thanks.

-- Kevin

(*) We don't exactly follow the JEP process as described in JEP 2, but 
for larger features we expect a proposal that touches on the important 
points in a JEP-like document and is discussed on the mailing list. 
That's what we mean when we say "needs a JEP".



On 2/21/2024 9:47 AM, Philip Race wrote:
1) The first thing that jumps out at me is the namespace : 
javafx.incubator


The JDK's JEP 11 says "An incubator module is identified by 
the|jdk.incubator.|prefix in its module name"

It says the same about the packages inside the module.
"An incubating API is identified by the|jdk.incubator.|prefix in its 
exported package names".


This is to avoid using the standard namespace prefixes for JDK of 
java. and javax. used for final APIs/modules.


So similarly I think JavaFX incubators should avoid the javafx. 
prefix and I suggest "jfx." be used instead.
This closely mirrors the "jdk." used in JEP 11, taking "java" out of 
the prefix and making it entirely an acronym,

for both module and package names.
The pain of updating your code when the API goes final can be eased 
by IDEs and is something you would

need to do anyway because "incubator" is in all the names in either case.

2) The second thing is you don't say what the steps are to promote 
the incubating module to final.
JEP 11 says a new JEP is needed for that, but it also says a new JEP 
is needed to re-incubate

which is something JavaFX will not require.
So do you expect it will be a new JEP for that ?
I think that would be best to do that as the JEP to propose the 
incubator could be several years old and stale by then.

You also don't say what it takes to drop it.

So how about the basic process is that the first JEP simply proposes 
the incubating module, once

it is in as you say it evolves by normal RFEs across releases ?
Then when it is EITHER ready to go final OR be removed, a new JEP 
must be proposed for that.

A removal JEP should generally be quite short :-)

So I suggest to add a sentence along those lines to the proposal.
"To either make the API of an incubating module final, or to remove 
it, then a new JEP should be submitted,

referencing the incubator JEP".

3) The "reasonably small number of JavaFX releases" is I am sure 
intentionally vague, but perhaps

we could say
(1) Incubators which span beyond a 24 month period and are not yet 
ready will need
a simple public approval from the project lead to remain for some 
additiional period at the discretion
of the Project Lead by adding a simple comment in the JEP, otherwise 
the Project Lead will submit a removal JEP and

(2) the submitter of the JEP can propose to remove it at any time.

-phil.

On 2/21/24 9:37 AM, Kevin Rushforth wrote:
JEP 11 [1] defines a process for delivering non-final JDK APIs in 
incubator modules.


Similarly, some JavaFX APIs would benefit from spending a period of 
time in a JavaFX release prior to being deemed stable. I propose 
JavaFX incubator modules as a means of putting non-final API in the 
hands of developers, while the API progresses towards either 
finalization or removal in a future release. This is especially 
useful for complex features with a large API surface.


The JavaFX proposal is largely the same as the JDK one, but has some 
important differences.


Please take a look at the preliminary proposal [2]. I have also 
created a Draft PR [3], for illustrative purposes only, to show how 
this might work.


Please reply to this message with any feedback.

Thanks.

-- Kevin

[1] https://openjdk.org/jeps/11
[2] 
https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md

[3] https://github.com/openjdk/jfx/pull/1375

Re: Proposal: JavaFX Incubator Modules

[Philip Race]

1) The first thing that jumps out at me is the namespace : javafx.incubator

The JDK's JEP 11 says "An incubator module is identified by 
the|jdk.incubator.|prefix in its module name"

It says the same about the packages inside the module.
"An incubating API is identified by the|jdk.incubator.|prefix in its 
exported package names".


This is to avoid using the standard namespace prefixes for JDK of java. 
and javax. used for final APIs/modules.


So similarly I think JavaFX incubators should avoid the javafx. prefix 
and I suggest "jfx." be used instead.
This closely mirrors the "jdk." used in JEP 11, taking "java" out of the 
prefix and making it entirely an acronym,

for both module and package names.
The pain of updating your code when the API goes final can be eased by 
IDEs and is something you would

need to do anyway because "incubator" is in all the names in either case.

2) The second thing is you don't say what the steps are to promote the 
incubating module to final.
JEP 11 says a new JEP is needed for that, but it also says a new JEP is 
needed to re-incubate

which is something JavaFX will not require.
So do you expect it will be a new JEP for that ?
I think that would be best to do that as the JEP to propose the 
incubator could be several years old and stale by then.

You also don't say what it takes to drop it.

So how about the basic process is that the first JEP simply proposes the 
incubating module, once

it is in as you say it evolves by normal RFEs across releases ?
Then when it is EITHER ready to go final OR be removed, a new JEP must 
be proposed for that.

A removal JEP should generally be quite short :-)

So I suggest to add a sentence along those lines to the proposal.
"To either make the API of an incubating module final, or to remove it, 
then a new JEP should be submitted,

referencing the incubator JEP".

3) The "reasonably small number of JavaFX releases" is I am sure 
intentionally vague, but perhaps

we could say
(1) Incubators which span beyond a 24 month period and are not yet ready 
will need
a simple public approval from the project lead to remain for some 
additiional period at the discretion
of the Project Lead by adding a simple comment in the JEP, otherwise the 
Project Lead will submit a removal JEP and

(2) the submitter of the JEP can propose to remove it at any time.

-phil.

On 2/21/24 9:37 AM, Kevin Rushforth wrote:
JEP 11 [1] defines a process for delivering non-final JDK APIs in 
incubator modules.


Similarly, some JavaFX APIs would benefit from spending a period of 
time in a JavaFX release prior to being deemed stable. I propose 
JavaFX incubator modules as a means of putting non-final API in the 
hands of developers, while the API progresses towards either 
finalization or removal in a future release. This is especially useful 
for complex features with a large API surface.


The JavaFX proposal is largely the same as the JDK one, but has some 
important differences.


Please take a look at the preliminary proposal [2]. I have also 
created a Draft PR [3], for illustrative purposes only, to show how 
this might work.


Please reply to this message with any feedback.

Thanks.

-- Kevin

[1] https://openjdk.org/jeps/11
[2] 
https://github.com/kevinrushforth/jfx/blob/javafx.incubator/INCUBATOR-MODULES.md

[3] https://github.com/openjdk/jfx/pull/1375

Re: The crisp fonts saga

[Philip Race]

I already gave a brief explanation of why FX text rendering is what it is.
I will expand on it a bit but a number of the salient points have 
already been made by others.
It is unlikely we will make anything other than carefully considered 
tweaks, so this is by way of explanation.


I'm not going to try to reply directly every single point made in this 
already very long thread,

I'm just going to tell it as I see it.

My experience is that above anything else in UIs, text rendering is a 
topic that generates a lot

of heat / discussion / etc and some times opinion are colored by experience.

There's the old quote
"You can please some of the people some of the time, all of the people 
some of the time,
some of the people all of the time, but you can never please all of the 
people all of the time."


As applied to font rendering it is more like
"You can please some of the people some of the time" and the quote stops 
right there ! At best !


Some people absolutely insist that being true to the design is what is 
most important

A high contrast is the most important to someone else.
No jaggies is important to another person.
Hinting is essential to some people in some cases. To other people it is 
anathema.

etc, etc.

Every one of these decisions and the consequences is sure to fall foul 
of someone's views,
If you want to reply to a specific point / decision / choice disagreeing 
with it, I'll not be surprised because
opinions differ. Even if you can actually get several people to agree in 
principle on what
they want, someone else will disagree, BUT you'll also run into the 
feasibility of it and consequences.


Overall, FX hasn't tried to look like the platform and to some extent 
that carries over into the text.
Meaning whereas Swing would provide a platform L and go to great 
lengths to use the SAME

font in the SAME way, FX has no contract to do that.
And on top of that it isn't just arbitrary application of the tastes of 
one FX UX architect back in the day.

There are technical issues behind it.

Having said that FX is not trying to emulate the platform, it is 
actually using platform APIs to do all the rendering.
But what is "the" platform API ? On Windows, many people prefer GDI 
rendering, whereas FX
uses the more modern DirectWrite API. And some people are very unhappy 
with DW in general

"https://superuser.com/questions/1484267/permanently-delete-directwrite-from-microsoft-windows;
You can find plenty more examples like this.

And of course Windows itself at the end user configuration level, as 
well as for applications
directly using APIs like DW and freetype often provide some set of knobs 
that affect some aspect of the rendering.

So there is no single true "the platform rendering".

A bit more history.
The first version of FX didn't have its own graphics pipeline, it was a 
wrapper around Java 2D & AWT.

T2K was used by Sun / Oracle JDK since JDK 1.2.
It was written by one of the original TrueType developers at Apple
The hinting support in it came directly from Apple.
So it was in fact quite good at what it did. But it was a snapshot, so 
over time it became old
and we had to maintain it and update it ourselves, fixing bugs, adding 
new features.

So JavaFX used T2K implicitly.

Actually one of the 'knocks' on T2K for FX was that there was some truly 
appalling
rendering of a family of fonts called "Amble" which Sun had commercially 
licensed to
be included with FX applications and provide FX apps with a consistent 
look across platforms.
It turned out that the problem was because those fonts were evaluated on 
the Apple platform
looking at how macOS rendered them. macOS even then ignored hints. And 
it turned out that
these fonts were hinted, and specified in the 'gasp' table to apply 
those hints but the hints were terrible.
The solution was to turn off hinting when using those fonts and then it 
was fine, but by then
there was already a perception of T2K as "poor", when really it was the 
fonts and the mistake

was to have licensed them.

Other commercial font rasteriser products were considered to be included 
instead in FX's own native Prism pipeline.
But using T2K was also considered for FX because licensing an additional 
font technology is extremely expensive.
But the direction of going open source ultimately forced the decision to 
use platform APIs, but
that doesn't make it a bad decision, although it meant you now could 
never have a consistent cross-platform

look that you controlled and had to manage at least 3 implementations.
Open-sourcing also meant the Amble fonts were dropped because they could 
not be open-sourced.
[BTW a similar thing happened when JDK was open sourced : T2K was 
dropped and so were the Lucida fonts]


But what comes out of all of this history is that un-hinted, macOS-like 
rendering is what was
wanted for FX for aesthetic  (yes, such a thing is subjective, I'm just 
telling the story) reasons

Even when hi-dpi displays were rare.

But there were 

Re: The crisp fonts saga

[Philip Race]

Usage of hinting in UIs is on the way out.
macOS stopped applying hints ages ago. Apple also canned LCD text.
High DPI displays are obsoleting the raison d'etre of both of these.
A big problem with hinting is that it distorts both the size and the 
shape, so UIs do not scale evenly

and animations look jerky.
Another is that a poorly hinted font is far worse than no hinting at all.


-phil.


On 12/12/23 6:10 AM, Mark Raynsford wrote:

Hello!

I've never been particularly satisfied with the font rendering in
JavaFX. In particular, on Linux, the text always appears very soft and
blurry compared to non-JavaFX applications on the same system. Even
applications that render antialiased text with Java2D seem to look
better.

I decided to take a look into it to see if anything could be done about
this, and I have some questions. I'm only looking at the Freetype
implementation in Prism currently, as that's all I can realistically
test on at the moment.

For reference, here's how text rendered at 16px using Terminus TTF
looks today:

https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png

I'm not sure if I'm alone on this, but I find this almost migraine-
inducing. No other application on my system, including those that use
Freetype, using that font at that size will render as blurry as that.

Looking at
modules/javafx.graphics/src/main/java/com/sun/javafx/font/freetype/FTFo
ntFile.java, I see this in initGlyph():

```
int flags = OSFreetype.FT_LOAD_RENDER | OSFreetype.FT_LOAD_NO_HINTING |
OSFreetype.FT_LOAD_NO_BITMAP;
```

Additionally, the code might also add the FT_LOAD_TARGET_NORMAL
or FT_LOAD_TARGET_LCD flags later, but I'll assume
FT_LOAD_TARGET_NORMAL for the sake of avoiding combinatorial explosions
in testing at this point.

Essentially, we discard hinting information, and we discard bitmap
information. I'm not sure why we do either of these things. I decided
to try different combinations of flags to see what would happen.

Here's FT_LOAD_RENDER | FT_LOAD_NO_BITMAP (no bitmaps, but using
hinting data):

https://ataxia.io7m.com/2023/12/12/hinting_nobitmaps_normal.png

That's no real improvement. Here's FT_LOAD_RENDER | FT_LOAD_NO_HINTING
(ignore hinting data, but use bitmaps if they are included):

https://ataxia.io7m.com/2023/12/12/nohinting_bitmaps_normal.png

That, to my poor suffering eyes, is already a _vast_ improvement.

Let's try including both hinting and bitmaps (FT_LOAD_RENDER):

https://ataxia.io7m.com/2023/12/12/hinting_bitmaps_normal.png

Inspecting that in an image editor shows the pixels of the text to be
identical.

So, clearly, Terminus TTF includes bitmaps for smaller text sizes.
Let's try another font such as Droid Sans that renders crisply at ~10pt
sizes on my system, and that I'm reasonably confident doesn't include
any bitmaps.

Here's the JavaFX default (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP):

https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps.png

That's pretty nasty. Let's enable hinting (FT_LOAD_NO_BITMAP):

https://ataxia.io7m.com/2023/12/12/droid_12_hinting_nobitmaps.png

That's already a lot better. If you overlay the two images in an image
editor, it's clear that the glyph shapes are not quite the same (with
hinting, some glyphs are ever-so-slightly taller).

For completeness, let's allow bitmaps:

https://ataxia.io7m.com/2023/12/12/droid_12_hinting_bitmaps.png

The rendered glyphs are pixel-identical.

Now, most modern desktops have options to disable antialiasing for text
under a given size. Antialiasing on 10pt text is rarely an improvement
over just not having it as there are so few pixels to work with. I
decided to experiment a bit with turning off antialiasing. This
requires setting the load target to FT_LOAD_TARGET_MONO so that
Freetype returns a monochrome image instead of what amounts to an alpha
coverage map. Unfortunately, this does also change the format of the
image returned to a 1bpp image instead of an 8bpp greyscale image, and
JavaFX isn't equipped to handle that. However, we can do the conversion
manually if we see that bitmap.pixel_mode == 1, and then the rest of
JavaFX doesn't need to care about it:

```
if (bitmap.pixel_mode == 1) {
   byte[] newBuffer = new byte[width * height];
   for (int y = 0; y < height; y++) {
 final var rowOffset = y * width;
 for (int x = 0; x < width; x++) {
   final var byteOffset = rowOffset + x;
   newBuffer[byteOffset] = bitAt(buffer, x, y, pitch);
 }
   }
   buffer = newBuffer;
}

private static byte bitAt(byte[] buffer, int x, int y, int pitch)
{
   final var byteOffset = (y * pitch) + (x / 8);
   final var bitOffset = 7 - (x % 8);
   final var bit = (buffer[byteOffset] >>> bitOffset) & 1;
   return (byte) (bit == 1 ? 0xff : 0x00);
}
```

Here's the JavaFX default of (FT_LOAD_NO_HINTING | FT_LOAD_NO_BITMAP)
combined with FT_LOAD_TARGET_MONO:

https://ataxia.io7m.com/2023/12/12/droid_12_nohinting_nobitmaps_mono.png

That's not a typeface even a mother could love. :)

However, what 

Re: Several GTK issues on latest Ubuntu release

[Philip Race]

There are several open bug reports of problems in AWT on ubuntu 23.10 
(and some on 23.04)


https://bugs.openjdk.org/issues/?jql=project%20%3D%20JDK%20AND%20component%20%3D%20client-libs%20AND%20labels%20in%20(ubuntu23.04%2C%20ubuntu23.10)

Note that GTK is not used to the same extent as it is by FX.
In fact it is used for only 2 things and only one of those can matter in 
your app,
and that is that the Swing GTK L uses it to get the rendering of GTK 
themes.
So if you weren't using the GTK L then a Swing app would likely not 
even load GTK.

But for a mixed FX + Swing app then of course it will still be loaded by FX.

-phil.



On 10/23/23 7:48 AM, Christopher Schnick wrote:


That is good to know that this issue is already being worked on. From 
the description of https://bugs.openjdk.org/browse/JDK-8316423, this 
issue is only tracked as affecting secondary stages? At least in our 
case it affects the primary stage as well, i.e. the one that is 
supplied via Application.start. Also, in this case it's not really 
about the scene dimensions, the stage doesn't even apply its own 
dimensions that were explicitly set before.


On 10/23/2023 4:39 PM, Thiago Milczarek Sayão wrote:

Forgot to mention: except for the system tray, I'm not looking into that.

Em seg., 23 de out. de 2023 11:36, Thiago Milczarek Sayão 
 escreveu:


Hi Cristopher,

https://github.com/openjdk/jfx/pull/1249

We noticed it and I'm working on a fix.

There's one issue that is probably a mutter bug:

https://gitlab.gnome.org/GNOME/mutter/-/issues/3092

-- Thiago

Em seg., 23 de out. de 2023 10:05, Christopher Schnick
 escreveu:

Hello,

a user of our application xpipe
 reported several issues
after upgrading their Ubuntu version and I investigated them
myself. I want to note here that these issues are exclusive
to new Ubuntu versions. I did not observe any of them on
slightly older Ubuntu versions or other Gnome-based desktop
environments. I don't know exactly which versions are
affected, but 22.04 works fine and Ubuntu 23.10 does not.

I'm sorry that I'm not able to create fully reproducible
examples or dig deeper into the causes here, but I'm very
constrained on time right now. For reproduction, I just
installed a new default Ubuntu 23.10 VM and launched the
JavaFX 21 application straight out of the box.

The first issue is that windows do not retain their
information when being hidden and then shown again. I.e.
after being shown for the second time, they will have tiny
dimensions and an GTK error is printed to stderr about height
< 0. For now I temporarily resolve this by doing the
following, which somehow fixes the issue:

    stage.show();

    // Due to some weird GTK bug, we have to set these
sizes every time we show a window again even though they have
been previously set
    stage.setX(stage.getX());
    stage.setY(stage.getY());
    stage.setWidth(stage.getWidth());
    stage.setHeight(stage.getHeight());

Furthermore, while this is technically not purely JavaFX
related, there is also a total freeze of the platform thread
when it calls javax.swing.UIManager.setLookAndFeel as it gets
stuck in some GTK implementation method. This is called by
the fxtrayicon library, which calls this method here

.
Since there is no native JavaFX tray integration, calling
these awt/swing related methods is quite important for
applications trying to use the system tray. This was a very
unfortunate issue for us as it caused applications to not
start up at all on affected systems.
I wasn't able to compare the behavior to Ubuntu 22.04 as
SystemTray.isSupported() returns false on Ubuntu 22.04 but
returns true on Ubuntu 23.10. Should this even return true on
Ubuntu now or is this a bug?

Again, these issues only occur on the very latest Ubuntu
release. I have tested on a lot of other different distros,
old and new, and they all worked flawlessly.

Best regards, Christopher

Re: [External] : Re: Question: bidi navigation

[Philip Race]

The split caret is usually rendered in one color for the strong 
direction and another for the weak.
Color is just one way of distinguishing. Other renderings are possible - 
oh I see the ATSUI
docs use a high half caret and a low half caret. That's a new one but as 
I said ..
I agree a user needs to know the current direction to know everything 
that will happen but it
at least tells them "here, or there" as opposed to "here, or somewhere 
else".

So the combination as Andy indicates might help.
I think the rendering should be a "pennant" rather than rectangular 
"flag" so that it looks a bit like an arrow ..

That's what Swing's rendering looks like.

-phil.

On 10/19/23 11:39 AM, Andy Goryachev wrote:


Maybe, just maybe, we should implement the dual carets with 
directionality indicators (highlighted here for illustration purposes 
only, the actual indicator might look like a flag or a “ г”):


What do you think?

-andy

*From: *Nir Lisker 
*Date: *Thursday, October 19, 2023 at 00:28
*To: *Philip Race 
*Cc: *Andy Goryachev , 
openjfx-dev@openjdk.org 

*Subject: *Re: [External] : Re: Question: bidi navigation

Thanks Andy, the new link works. I read pages 33-36. Page 35 details 
the two approaches: the dual caret you have described (which I had 
never seen before in my life), and the single "jumping" caret, which 
is what I advised to do. The document doesn't show, however, a 
direction indicator for the caret based on the selected language, and 
I think that that's something that should be shown.


Phil, I'm not sure how the split caret can tell a user on its own 
where the text will appear. The user will have to look at which 
language is currently selected to know which of the carets is the real 
indicator. That is, unless I misunderstand how the split caret works.


The "why did it appear over there?" question is common in UI's that 
don't handle the caret indication properly, for example when there is 
no visual difference between the RTL and LTR carets (the direction 
indicator). A jumping caret with a visual direction indicator solves 
100% of the ambiguity and the surprise factor without needing to look 
outside of the text control to check which language is selected.


- Nir

On Wed, Oct 18, 2023 at 10:31 PM Philip Race  
wrote:


So it seems Swing never calls Java2D's TextLayout.getCaretShapes()
API which is what would provide the split carets.

Swing's caret is an instance of javax.swing.text.DefaultCaret
which has support for rendering a "flag" that indicates
the direction of the caret bias.

Split caret is however useful to tell a user where the text of the
other direction would appear.
Otherwise even to someone familiar with editing bi-di text I
except some cases of "oh, why did what I typed appear way over there"?
They might still wonder, but at least they'd know where it was
going to be rendered ahead of time.

-phil

On 10/18/23 10:47 AM, Andy Goryachev wrote:

Thank you, Nir.

Try this link:


https://web.archive.org/web/20120802192035/http://developer.apple.com/legacy/mac/library/documentation/Carbon/Conceptual/ATSUI_Concepts/atsui.pdf

<https://web.archive.org/web/20120802192035/http:/developer.apple.com/legacy/mac/library/documentation/Carbon/Conceptual/ATSUI_Concepts/atsui.pdf>

Curiously, the dual (split) caret capability *is* present in
java2d, but apparently it is not used in Swing as far as I can
tell:


https://docs.oracle.com/javase/tutorial/2d/text/textlayoutbidirectionaltext.html#moving_carets

-andy

*From: *Nir Lisker  <mailto:nlis...@gmail.com>
*Date: *Wednesday, October 18, 2023 at 09:15
*To: *Andy Goryachev 
<mailto:andy.goryac...@oracle.com>
*Cc: *openjfx-dev@openjdk.org 
<mailto:openjfx-dev@openjdk.org>
*Subject: *Re: [External] : Re: Question: bidi navigation

I've never seen this dual caret system. The link you gave
leads to a 404 error.

I can't comment as to the plan without knowing what Prism was
designed to do, but it's rather unusual. The logical
navigation choice seems correct regardless.

On Tue, Oct 17, 2023 at 7:13 PM Andy Goryachev
 wrote:

Dear Nir:

Thank you so much for the information.  I spoke to several
people none of whom, unfortunately, use an environment
configured for RTL mode (but who have keyboard settings
for RTL languages). Based on the very small sample, it
appears that logical navigation is a way to go - which
means the FX behavior (or rather lack thereof due to
https://bugs.openjdk.org/browse/JDK-8296266) needs to
change relative to jfx8.

Regarding the direction indicator - FX impleme

Re: [External] : Re: Question: bidi navigation

[Philip Race]

So it seems Swing never calls Java2D's TextLayout.getCaretShapes() API 
which is what would provide the split carets.


Swing's caret is an instance of javax.swing.text.DefaultCaret which has 
support for rendering a "flag" that indicates

the direction of the caret bias.

Split caret is however useful to tell a user where the text of the other 
direction would appear.
Otherwise even to someone familiar with editing bi-di text I except some 
cases of "oh, why did what I typed appear way over there"?
They might still wonder, but at least they'd know where it was going to 
be rendered ahead of time.


-phil

On 10/18/23 10:47 AM, Andy Goryachev wrote:


Thank you, Nir.

Try this link:

https://web.archive.org/web/20120802192035/http://developer.apple.com/legacy/mac/library/documentation/Carbon/Conceptual/ATSUI_Concepts/atsui.pdf 



Curiously, the dual (split) caret capability *is* present in java2d, 
but apparently it is not used in Swing as far as I can tell:


https://docs.oracle.com/javase/tutorial/2d/text/textlayoutbidirectionaltext.html#moving_carets

-andy

*From: *Nir Lisker 
*Date: *Wednesday, October 18, 2023 at 09:15
*To: *Andy Goryachev 
*Cc: *openjfx-dev@openjdk.org 
*Subject: *Re: [External] : Re: Question: bidi navigation

I've never seen this dual caret system. The link you gave leads to a 
404 error.


I can't comment as to the plan without knowing what Prism was designed 
to do, but it's rather unusual. The logical navigation choice seems 
correct regardless.


On Tue, Oct 17, 2023 at 7:13 PM Andy Goryachev 
 wrote:


Dear Nir:

Thank you so much for the information.  I spoke to several people
none of whom, unfortunately, use an environment configured for RTL
mode (but who have keyboard settings for RTL languages). Based on
the very small sample, it appears that logical navigation is a way
to go - which means the FX behavior (or rather lack thereof due to
https://bugs.openjdk.org/browse/JDK-8296266) needs to change
relative to jfx8.

Regarding the direction indicator - FX implements a dual caret the
logic of which I am still trying to decipher:

(/sliptCaret/ in PrismTextLayout:354)

The closest description I was able to find is in Apple ATSUI
Programming guide


http://developer.apple.com/legacy/mac/library/documentation/Carbon/Conceptual/ATSUI_Concepts/atsui.pdf




on page 35, though I am not sure FX works as described in that
document.

The expectation is that the primary (high) caret is where the
character having the same directionality as the “primary line
direction” is inserted.  It is possible that the text layout
determines the primary line direction based on the text as opposed
to taking a hint from NodeOrientation.

Since this behavior is baked into FX prism text layout, I think
it’s unlikely to change.

To summarize, I think we should switch FX TextInputControl
hierarchy to logical navigation.  What do you think?

-andy

*From: *Nir Lisker 
*Date: *Tuesday, October 17, 2023 at 03:44
*To: *Andy Goryachev 
*Cc: *openjfx-dev@openjdk.org 
*Subject: *Re: [External] : Re: Question: bidi navigation

I have just tested on Win10: Notepad, Wordpad, MSWord 2021,
Discord desktop, WhatsApp desktop, Opera, Eclipse, Gimp 2,
Audacity 2.1.3, and MS VisualStudio 2022 all use logical. Edge
uses logical in text areas and text fields, but visual in the
address bar (seems like a bug, but you can't have spaces in web
addresses anyway). I don't remember ever using a visual navigation
application, maybe it was very long ago. If there ever was a
decision there, it was made long ago, at least on Windows.

It's very important to show the cursor direction because it
resolves ambiguities. It's available in most applications.

My Windows UI is in standard English LTR. I just have an RTL
language installed.

Logical navigation is a bit easier to work with I think. The
behavior at the edge of a word that changes the direction can be
surprising (see the ambiguities above), but that can be helped
with the cursor direction indication. If we can do a custom
implementation, I would go a step further and actually resolve the
position ambiguities by positioning the cursor in accordance with
the selected insertion method (RTL or LTR). This means that the
cursor will jump when switching the language, but it will make
life easier because you will easily know in which direction you're
about to type.

On Mon, Oct 16, 2023 at 6:16 

Re: CFV: New OpenJFX Committer: Lukasz Kostyra

[Philip Race]

Vote: yes

-phil.

Re: My JavaFX app is managed by efficiency cores once reduced in tray icon.

[Philip Race]

Probably there isn't unless the OS has a way of flagging the binary
So what OS and CPU architecture + specific version are you seeing this on ?
Others might want to try to reproduce this.

-phil.

On 5/23/23 12:31 PM, Davide Perini wrote:

As title.
I'm pretty sure that my JavaFX app is managed by efficiency cores once 
reduced in tray icon since its performance drops significantly,
if I open a window and leave it open, the app goes at max speed on 
performance cores.


Is there a way to set the app runs on performance core even without 
leaving a window opened?


Thanks
Davide

Re: CFV: New OpenJFX Reviewer: Andy Goryachev

[Philip Race]

Vote: yes

-phil.

Re: CFV: New OpenJFX Committer: Karthik P K

[Philip Race]

Vote: yes

-phil.

Re: Swing works, but OpenJFX applications not working with screen readers

[Philip Race]

Those tools as I think you've worked out are Windows-only tools which 
use the Windows-only

Java Access Bridge API that ships with JDK.
AccessBridge was designed and built 25 years ago (!) to enable Assistive 
Technologies to

work for Swing applications at a time when no platform could do this.
ATs like JAWS (and others) implemented support for AccessBridge and 
still provide it today

(we still get bug reports from customers using it)
So Java + Swing was a long way ahead of the platforms.

But JavaFX does not use AccessBridge.
By the time it was developed platforms were starting to add AT APIs.
So instead JavaFX implements support for the platform accessibility APIs 
meaning

Narrator on Windows and VoiceOver on macOS.

Therefore JavaFX will not work with those JDK tools which are tied to 
AccessBridge.


> with the screen reader JAWS running, the 
Platform.accessibilityActiveProperty() is "true


I guess this is because JAWS registers itself with windows as the active AT.
Whether JAWS interjects itself into Narrator APIs would depend on 
whether Windows
supports that. If it doesn't then JAWS probably has to do old-fashioned 
screen scraping

and I don't know how well that would work.

A11Y is usually tested at the application level - whereas JavaFX and 
Swing are both
toolkits with which to build applications - but we do try to make things 
work well
with the ATs that each of them use, so Narrator is supposed to work for 
JavaFX

applications on Windows.


-phil.

On 3/5/23 12:36 AM, Don Johnson wrote:

Hi All,

This is accessibility API question. Swing applications like IntelliJ 
IDEA appear in the utilities jaccesswalker, jaccessinspector (JDK/bin) 
and access-bridge-explorer (.NET app at 
https://github.com/google/access-bridge-explorer.git). However, no 
scene graph or accessibility messages in these utilities appear for 
any OpenJFX application I have written. A screen reader needs both to 
know the scene graph and be able to send and receive accessibility 
messages to perform automation and read control descriptions.


I have put these values in the "accessibility.properties" file in the 
JDK lib folder:


    assistive_technologies=com.sun.java.accessibility.AccessBridge
    screen_magnifier_present=true
    screen_reader_present=true

In different test OpenJFX applications running on Windows machines, 
with the screen reader JAWS running, the 
Platform.accessibilityActiveProperty() is "true." When JAWS is not 
running, the value is "false." However, the screen reader cannot 
communicate with the OpenJFX applications.


Why are the OpenJFX applications not communicating across the 
communication channel facilitated by the WindowsAccessBridge-64.dll 
and JavaAccessBridge.dll? Incidentally, the Java Access Bridge is 
enabled with jabswitch.exe. There is some type of Windows IPC used by 
the bridge (COM?) once it is enabled. This bridge facilitates 
communication between the screen reader and a Java application running 
inside of a JVM.


I've also tried explicitly setting roles etc. even though OpenJFX 
graphical object already have default values. For example in the 
"bouncing ball" sample program I set,


    setAccessibleRole(AccessibleRole.BUTTON);
    setAccessibleRoleDescription("Bouncing Ball");
    setAccessibleText("I'm a bouncing ball");
    setAccessibleHelp("This is bouncing ball, use the primary 
action to start animation");


Does anyone have an OpenJFX sample program the shows up in the 
jaccesswalker and jaccessinspector utilities and works with a screen 
reader like JAWS or NVDA? This YouTube presentation implies 
accessibility is already built into OpenJFX, but I can't get it to 
work, see https://youtu.be/iUPPEkD9H1I "The New JavaFX Accessibility 
API." My applications must comply with Section 508 of the 
Rehabilitation Act of 1973 but cannot so far because of this OpenJFX 
accessibility problem.


Thanks,
Don

Re: CFV: New OpenJFX Reviewer: Jose Pereda

[Philip Race]

Vote: yes

-phil

Re: CFV: New OpenJFX Committer: Jay Bhaskar

[Philip Race]

Vote: yes

-phil.

Re: CFV: New OpenJFX Committer: Hima Bindu Meda

[Philip Race]

Vote: yes

-phil.

Re: Some classes could be sealed

[Philip Race]

In the JDK we've only sealed  existing classes which provably could not 
have been extended by application classes,

so I'm not sure about this ..

also I think that might be the first change that absolutely means FX 21 
can only be built with JDK 17 and later ..


-phil

On 2/1/23 8:59 AM, Thiago Milczarek Sayão wrote:
Yes, sorry, I made the email title in plural, but I meant what Michael 
said, Node would be sealed permitting only what is needed for JavaFx 
internally.



-- Thiago


Em qua., 1 de fev. de 2023 às 13:48, Michael Strauß 
 escreveu:


I don't think that's what Thiago is proposing. Only `Node` would
be sealed.
The following subclasses would be non-sealed: Parent, SubScene,
Camera, LightBase, Shape, Shape3D, Canvas, ImageView.
And then there are additional subclasses, which don't fit into this
idea since they are in other modules: SwingNode (in javafx.swing),
MediaView (in javafx.media), Printable (in javafx.web).



On Wed, Feb 1, 2023 at 5:39 PM John Hendrikx
 wrote:
>
> I think this may be a bit unclear from this post, but you're
proposing I think to make `Node`, `Shape` and `Shape3D` sealed. 
For those unaware, you're not allowed to extend these classes
(despite being public).  For example Node says in its documentation:
>
>    * An application should not extend the Node class directly.
Doing so may lead to
>    * an UnsupportedOperationException being thrown.
>
> Currently this is enforced at runtime in NodeHelper.
>
> --John
>
> On 01/02/2023 15:47, Thiago Milczarek Sayão wrote:
>
> Hi,
>
> NodeHelper.java has this:
>
> throw new UnsupportedOperationException(
>         "Applications should not extend the "
>         + nodeType + " class directly.");
>
>
> I think it's replaceable with selead classes. Am I right?
>
> The benefit will be compile time error instead of runtime.
>
>
> -- Thiago.
>

Re: Q: missing APIs needed for implementation of a rich text control

[Philip Race]

Many of the items below (meaning excluding the caret features and app 
control of line spacing) are on my list of

things to work on.

phil

On 1/26/23 12:33 PM, Scott Palmer wrote:

[dupe of private message, now including the mailing list]

I've been using RichTextFX to make my own code editor/IDE.  I see that 
you have asked that project specifically on GitHub, excellent.
One thing that I wanted to do was to use a font like Fira Code that 
combines characters such as != or >= into a single glyph, but there 
are no APIs to request that JavaFX render those optional ligatures. 
Swing APIs automatically do. In fact just implementing some basic font 
selection has been tedious.  Getting the font family from a Font 
object and trying to use it in CSS to specify -fx-font-family simply 
doesn't work sometimes.  Trying to filter the list of available fonts 
to show only those that are fixed-width is tedious.  I tried to hack 
something by measuring a couple different characters from the font 
that would normally be different widths, but this is an unreliable 
hack. Allowing the user to choose a preferred font and then 
configuring components to use it via a CSS stylesheet is simply more 
difficult than it should be.
A few years ago I contributed the changes to make the tab-width 
configurable, which helped with my project a little bit.  Other APIs 
are needed to better control line spacing and measure font baseline 
offsets and that sort of thing.  I see there is an issue for 
caretBlinkRate, what about changing the caret shape? E.g. block, 
underscore, vertical bar, etc.   Should the block be solid or an 
outline? Why is caretShape read-only? Why does it return an array of 
PathElements instead of simply a Shape which by default would be a 
Path?  More control of kerning and general spacing might be nice. I've 
wanted that in the past, not for a rich text control, but for doing 
video titles.  I can see how the two needs overlap though.  I recently 
asked here about rendering emojis.  That's currently very unreliable 
and broken.  Getting something to work consistently cross-platform is 
not easy.  Sometimes emojis are rendered in color, other times not.  
Mac renders color emojis in gray and at the wrong size (since  the 
sub-pixel rendering was turned off to match macOS).  On Windows the 
emojis are never in color.


Regards,

Scott

On Wed, Jan 25, 2023 at 10:41 PM Scott Palmer  wrote:

I've been using RichTextFX to make my own code editor/IDE.  I see
that you have asked that project specifically on GitHub, excellent.
One thing that I wanted to do was to use a font like Fira Code
that combines characters such as != or >= into a single glyph, but
there are no APIs to request that JavaFX render those optional
ligatures. Swing APIs automatically do.  In fact just implementing
some basic font selection has been tedious.  Getting the font
family from a Font object and trying to use it in CSS to specify
-fx-font-family simply doesn't work sometimes.  Trying to filter
the list of available fonts to show only those that are
fixed-width is tedious.  I tried to hack something by measuring a
couple different characters from the font that would normally be
different widths, but this is an unreliable hack. Allowing the
user to choose a preferred font and then configuring components to
use it via a CSS stylesheet is simply more difficult than it
should be.
A few years ago I contributed the changes to make the tab-width
configurable, which helped with my project a little bit.  Other
APIs are needed to better control line spacing and measure font
baseline offsets and that sort of thing.  I see there is an issue
for caretBlinkRate, what about changing the caret shape? E.g.
block, underscore, vertical bar, etc.   Should the block be solid
or an outline? Why is caretShape read-only? Why does it return an
array of PathElements instead of simply a Shape which by
default would be a Path?  More control of kerning and general
spacing might be nice. I've wanted that in the past, not for a
rich text control, but for doing video title.  I can see how the
two needs overlap though.  I recently asked here about rendering
emojis.  That's currently very unreliable and broken.  Getting
something to work consistently cross-platform is not easy. 
Sometimes emojis are rendered in color, other times not.  Mac
renders color emojis in gray and at the wrong size (since  the
sub-pixel rendering was turned off to match macOS).  On Windows
the emojis are never in color.

Regards,

Scott

On Wed, Jan 25, 2023 at 5:38 PM Andy Goryachev
 wrote:

Dear colleagues:

I am trying to identify missing public APIs needed to support
a rich text control.  There is a number of tickets created
already against various parts of JavaFX, collected in

Re: JavaFX Font support for Emojis

[Philip Race]

Can JavaFX render full colour emojis? Is the greyscale rendering on macOS 
intentional?


https://bugs.openjdk.org/browse/JDK-8290866
I was looking at this before we started our winter break, and realised it was
going to be a chunk of work.

So not intentional but anything that ever appeared to work was just 
serendipitous.


Presumably the smaller scale and vertical shift on macOS are bugs?


Not noticed vertical shift but for the size problem this was already reported 
but not yet investigated
https://bugs.openjdk.org/browse/JDK-8291469



Can Swing on Windows render emojis in colour like it does on macOS?


You mean Java 2D ? Swing is "FX Controls" whereas Java 2D is "FX Graphics".
What you see on Windows is because Windows Emoji fonts also contain
standard glyphs and so any font / text code that doesn't know about Emojis
uses those so gets something sensible, just not in colour.t

Apple's Emoji font just contains PNG images at several sizes .. CoreText scales
the closest image of the same size or larger to what is requested.

BTW GDI will never be updated to report Emoji glyphs, but I think Java 2D
on Windows can use freetype for that rather than more complex migration to 
DirectWrite.



(Btw, SwingPane on Windows 11 doesn’t paint at all until it is “provoked” with 
some sort of event,
like dragging the window so it is partially obscured.)


I think Kevin recently discovered this and there's a bug open.

>  And finally, is there any hope to get cross-platform support for 
full colour emojis in a JavaFX application
> via Text nodes, or would it be best to abandon the idea altogether 
and use Image nodes for them instead?


Well, there is not going to be a cross-platform way for this to work 
internally

Some code can be cross-platform but platform-specific code is inevitable.
I mean in the FX implementation. I am not suggesting FX user apps try this

So it is probable that Emoji support will appear one platform at a time but
will always be cross-platform to user code .. it'll just be a matter of 
whether it works or not.


But the goal is (or should be) that they appear in colour in Text nodes 
and UI controls
no matter what the text rendering mode. There may be some challenges 
along the

way to this, but that is the goal.

-phil.

On 1/1/23 11:02 AM, Scott Palmer wrote:

I’ve been experimenting, trying to figure out a cross-platform way of 
displaying emojis in a JavaFX application.  It has been interesting.

I tested on macOS and Windows 11. On macOS I explicitly set the font to “Apple 
Color Emoji”, on Windows 11, I used “Segoe UI Emoji”.  Those appear to be the 
standard fonts for emojis on the respective platforms.
  
On macOS with JavaFX, emojis render in monochrome with shades of grey, smaller than they should be and shifted down slightly, sometimes cropping off the bottom pixels.  With Swing (via SwingPane) they render in full colour the same as native applications.


On Windows with JavaFX the emoji is rendered in black and white (no shading) 
for both JavaFX and Swing.  This is the same as how WordPad renders them, but 
different than Microsoft Word, which will show the emojis in full colour. The 
emojis are the right size and not vertically shift as they are on macOS.

If I set the font to something else, I used “Fira Code” that I downloaded so it 
should be the exact same on both platforms, I get different behaviour.
On Windows 11 with JavaFX the \uFE0F combining character that indicates the previous 
character should be rendered as an emoji causes a blocked ? to print after a 
non-emoji heart character. (To get a “Red Heart” emoji I am using the standard 
Unicode heart “\u2764” followed by "\uFE0F”.)
Swing on macOS still renders full colour emojis, but on Windows 11 it claims it 
can’t render the emoji characters at all - sure enough 
java.awt.Font.canDisplay(codePoint) returns true on macOS and false on Windows 
11, even though the font is the same.

If I use a logical font, e.g. “Monospaced”, Swing renders the emojis the same 
as when using the explicit emoji font on both platforms, as does JavaFX on 
macOS. However, JavaFX on Windows 11 still prints the blocked ? for \uFE0F.

So a few questions:

Can JavaFX render full colour emojis? Is the greyscale rendering on macOS 
intentional?
Presumably the smaller scale and vertical shift on macOS are bugs?
Can Swing on Windows render emojis in colour like it does on macOS?
(Btw, SwingPane on Windows 11 doesn’t paint at all until it is “provoked” with 
some sort of event, like dragging the window so it is partially obscured.)

And finally, is there any hope to get cross-platform support for full colour 
emojis in a JavaFX application via Text nodes, or would it be best to abandon 
the idea altogether and use Image nodes for them instead?

Regards,

Scott

Re: CFV: New OpenJFX Committer: Andy Goryachev

[Philip Race]

Yes

-Phil.

Re: JavaFX @ JavaOne 2022

[Philip Race]

> Very nice! Was the technical session recorded?

In theory, yes, but we are still waiting to see to be sure since so far 
only key notes have been posted.


My understanding is that if works out it'll be on the java dev-rel 
youtube channel


phil.

On 11/1/22 5:50 PM, Nir Lisker wrote:
Very nice! Was the technical session recorded? Were there any 
interesting questions in the Q?


On Tue, Nov 1, 2022 at 11:16 PM Kevin Rushforth 
 wrote:


JavaOne 2022 was the week of Oct 17-20, and there were two
sessions of
interest to JavaFX:

* During the technical keynote [1], I announced that Oracle would
start
delivering JavaFX builds, beginning with JavaFX 20 early access, on
jdk.java.net  [2][3].

* I gave a technical session titled "JavaFX 19 and Beyond". You can
download the presentation [4].

Stay tuned for an upcoming Inside Java [5] podcast covering JavaFX.

-- Kevin

[1] https://inside.java/2022/10/27/the-future-of-java-is-you/
[2] https://inside.java/2022/10/20/javafx-early-access-builds/
[3] https://jdk.java.net/javafx20/
[4]

http://cr.openjdk.java.net/~kcr/presentations/javaone-2022/JavaFX-19_Final.pdf
[5] https://inside.java/podcast/

Re: Support for Ligatures

[Philip Race]

FX does (of course) support required ligatures, meaning those without 
which some script (eg Arabic)

can't even be rendered.

But that is implementation, no API.

So this is about adding an API to request optional ligatures - and other 
OpenType features.

For example I think we'd want to support things like small caps etc.

Of course we'd need to make sure all the measuring code is up to that .. 
and BTW

the APIs to do measurement probably should be in the queue ahead of this ..

And I am not sure about just an API to request ligatures without an API 
to query
if ligatures are available for a font. However that may turn out to be 
tricky for a

few reasons, but we should at least study it.

And to try to answer the "when" question .. it is on a "desired" list in 
my head and maybe

even on a wiki somewhere .. but no concrete timetable exists.

But it is good to get feedback like this so we know it is interesting to 
developers.


-phil.

On 10/24/22 12:07 PM, Scott Palmer wrote:
Something I noticed while experimenting with RichTextFX, when I set it 
to use Fira Code for the font, like I do in NetBeans, I see that 
JavaFX doesn't support ligatures.  I found this issue that's been 
around for quite some time:
[JDK-8091616] Prism: font: ligature and kerning support - Java Bug 
System 

bugs.openjdk.org 
jira-favicon-hires.png 



Is there any drive to get this implemented within the next few 
releases?  I would help, but unfortunately I suspect it will take more 
time than I can commit to it.
I’m hoping that eliminating some of the remaining gaps between what 
JavaFX supports and Swing supports would be a priority, as it removes 
some barriers to JavaFX adoption... but maybe not?


Regards,

Scott

Re: Platform independent deployment

[Philip Race]

> this is Java code after all, why would all Java classes for a 
platform be platform specific?


There absolutely CAN be such things as platform-specific Java classes in 
code that ports to a platform.

OpenJDK is littered with subdirectories named "windows" and "linux" etc.
And it takes great care to build and ship these only on appropriate 
platforms.


In JavaFX such things also exist that are less clear but still 
platform-specific

For example what place does
modules/javafx.graphics/src/main/java/com/sun/javafx/font/coretext have 
in the windows build, or
modules/javafx.graphics/src/main/java/com/sun/javafx/font/directwrite 
have in the macos build ?


None, really, and even though they are there, they really should not be.

So the bottom line is that you should not assume that a platform like 
JavaFX can be

delivered only with platform independent Java code.

-phil


On 10/20/22 1:03 PM, John Hendrikx wrote:
Correct me if I'm wrong, but all the classes in the artifacts for win, 
linux and mac are actually exactly the same -- this is Java code after 
all, why would all Java classes for a platform be platform specific?  
It doesn't matter which one is packaged.  The platform specific stuff 
lives in the native libraries -- my shaded jar just includes all of 
them for all platforms (dll for windows, so for linux, dylib for 
mac).  I'm pretty sure I used this exact same jar to run my software 
on windows and linux.  Never tested mac as I don't own one.


My pom therefore includes all three, like Nir Lisker has, and my 
shaded artifact just packages them all (I get a lot of warnings about 
duplicate classes, but those can just be ignored).


--John

On 20/10/2022 19:03, Thomas Reinhardt wrote:


Hi Nir,

Does not work (I testet it) and it can not work (see below).

Also, this is exactly what my naive test was (I did not use maven to 
copy the artifacts, but the result obviously is the same).


It can not work as the implementation classes have the same name and 
thus the jre can not distinguish which one to load. For example both 
javafx-web-18-win and javafx-web-18-linux define a class 
"javafx.scene.web.WebEngine". From the jre's point of view they are 
the same.


What would be needed is

Either: a class "javafx.scene.web.WebEngine" that is only a thin 
wrapper to javafx.scene.web.linux.WebEngine.


Or: a class that loads only one of the implementations during 
application startup (technically it could load both implementations 
with different classloaders, but lets not go there).


There might be other solutions but I am not aware of any.


I was looking for a help forum but did only find the #introduction 
link you mentioned.



-Thomas



On 20/10/2022 17:52, Nir Lisker wrote:

Hi Thomas,

Did you try to just specify the platform-specific dependencies in 
the POM?


     
         org.openjfx
         javafx-graphics
         19
         win
     
     
         org.openjfx
         javafx-graphics
         19
         linux
     
     
         org.openjfx
         javafx-graphics
         19
         mac
     

Seems more of a question for help forums, though if this information 
is not mentioned in https://openjfx.io/openjfx-docs/#introduction 
, it might be worth 
adding it.


On Thu, Oct 20, 2022 at 9:42 AM Thomas Reinhardt 
mailto:thomas.reinha...@s4p.de>> wrote:



    Hi!

    Apologizes if this is not the proper list to ask my question.

    For context: we are using the WebView of JavaFX in our legacy swing
    based frontend application. For now that is the only component 
we are

    using but we might migrate completely at a later point in time.

    I have an issue with the way platform dependent dependencies are
    handled. We are using maven btw.
    My understanding is that during the build a profile is selected
    based on
    the host os name and architecture. That profile then sets a 
property
    (javafx.platform) that is in turn used as the classifier for 
platform

    dependent dependencies.
    (Offtopic to my question: eclipse warns that the profile ids are 
not

    unique in the org.openjfx:javafx pom.xml).

    Which means that the result of my build is locked to a single 
platform.

    But we have customers for windows and linux and don't want to have
    separate artifacts as that would mean we also have to handle that
    distinction in our installer etc.

    I know I can override the automatically detected platform but 
that does

    not solve the issue.

    Ideally I would use something like -Djavafx.platform=all but 
that does

    not exist.

    My question is: is there an existing solution where I can just 
include

    all platform dependencies for say windows and linux and the runtime
    "sorts it out"? A naive test (manual copying of artifacts) of mine
    unfortunately failed. Of course I could just use custom 
classloaders

    and
    do it myself but I really would prefer to use an existing 

Re: Provide Quit handler for system menu bar

[Philip Race]

All of these requests seem to map to what we added to AWT in JDK 9.
We did this because there'd been Apple specific APIs that came in via the
Apple port but were very iffy in terms of what was supported and it was
not a good idea to formally export them from the new desktop module.

The java.awt.Desktop class was enhanced by the java.awt.desktop package
and all of these things are provided in a platform neutral way.
You just query whether the support is available.

These can even be used in a mixed AWT/FX application if you want a 
solution now,

but FX could have its own version of these.

Nothing that mentions a platform (please!).

-phil

On 9/20/22 6:38 AM, Scott Palmer wrote:
I always understood Alt+F4 as simply being a keyboard shortcut on 
Windows for closing the window of the active application.  The same as 
clicking the close widget.  I don’t think there is anything special 
about it.  As far as being an equivalent to the macOS Quit action, I 
don’t think it is quite the same. Does an application even know the 
difference between a window closed with the widget vs. Alt+F4? CTRL+F4 
closes the current document window or tab - similar to Command-W on 
macOS.


I’m not aware of any special handlers being called on Windows for 
these shortcuts other than what is called when the equivalent close 
widget is pressed. If I’m wrong about that, then sure, a quit handler 
for JavaFX could be wired in to the same mechanism automatically. 
 Maybe Linux has an equivalent as well, I don’t know.


While we are at it, custom handling for the ‘About’ menu item in the 
application menu is also needed, is it not?


For now I’m currently using Jan Gassen’s port of NSMenuFX to hook into 
this stuff. https://github.com/0x4a616e/NSMenuFX



Scott

On Sep 20, 2022, at 5:55 AM, John Hendrikx  
wrote:




What about Alt + F4 and Ctrl + F4 on Windows?  Alt + F4 closes the 
application (which works with JavaFX already) and Ctrl + F4 is 
supposed to close a single window, but that doesn't work for JavaFX.


Also very much in favor of Keeping the API platform neutral, that's 
just how Java has worked since its inception.


--John

On 20/09/2022 06:25, Scott Palmer wrote:
Windows applications often have an “Exit” menu item, but since it 
isn’t standardized like it is on macOS, calling a quit handler for 
it would need to be a manual step - but the exact same method for 
the quit handler could be called, leaving it up to the programmer to 
continue or not with the application exit depending on the return 
value. This manual coding isn’t a big deal since you would also need 
to have some app-specific handling to avoid making an Exit menu item 
on macOS, where it would look out of place.


You could add a standard “requestExit()” method to Platform that you 
could manually bind to an Exit menu item on Windows or Linux, but it 
would be automatically called via an internal macOS Quit handler 
implementation.  The implementation of Platform.requestExit() on 
*all* platforms would call a boolean method if one was registered 
and then conditionally call Platform.exit() depending on the return 
value, the default being to always exit if nothing was registered. 
On macOS it would pass on the value to veto the native Quit handler 
as needed. I haven’t checked, does Application.stop() get called on 
macOS if you exit via the Quit menu or Command-Q? If it doesn’t, 
that’s another benefit.  This idea should probably be opt-in via 
some API or system property, I suppose it would have to be if it 
changes behaviour of having Application.stop() called in some 
circumstances. Or you can just make the setting of the handler 
function the “opt-in”.


Btw, this reminds me of the long-standing request for system tray 
support, along with with various other features that have 
equivalents across multiple OS’, like showing progress on the dock 
icon, or a numbered badge (for notifications, or unread msgs, etc). 
 I think there are already issues in Jira for these, maybe just as a 
general request to support some features that AWT/Swing has that JFX 
is still missing. Most of these features are available on both Mac 
and Windows, possibly Linux.  It would be irritating to code to 
different APIs for each if it can be avoided, so I agree with going 
for a platform-neutral way.


Cheers,

Scott

On Sep 19, 2022, at 8:11 PM, Kevin Rushforth 
 wrote:


 I don't see us adding 100s of OS-specific API calls, but even if 
we did, going down the path of exposing them as Mac APIs or Windows 
APIs, doesn't really seem like the direction we want to go. 
Whatever we do needs to balance the desire to integrate with, e.g., 
the macOS or Windows platform with a desire to leave the door open 
for it to later be implemented on the other platform(s). And the 
most cross-platform way to do that from an API point of view is by 
defining API that delivers the desired functionality in as 
platform-neutral a way as possible. It also needs to fit cleanly 
into the 

Re: [External] : Aw: Proposal: Add Skin.install() method

[Philip Race]

Kevin is right. If you look (for a good example) in JDK's java.base 
module for "new Error"
you'll be hard-pressed to find Error being thrown in response to a 
passed in argument.
The cases I see are when something completely unexpected or "should not 
happen" went

wrong in some implementation code.

And there are zero [*] cases of the javadoc pattern
"throws Error"
or
"exception Error"

-phil

* I did find a couple in java.desktop which made me grumble since 
there's nothing we can do about those now.


On 7/22/22 2:02 PM, Andy Goryachev wrote:


I do mean java.lang.Error.

The goal is to prevent an incorrect code from being shipped to the end 
user.  There are no tools at the API level to enforce the 1:1 
relationship, so it cannot be checked at compile time.


The next best thing is to fail during the development, thus an Error.  
It should be an error and not a RuntimeException because it 
communicates a design error, and not a run time, i.e. a legitimate run 
time condition.  It is also not an IllegalArgumentException because 
there should be no scenario when this could happen.


In other words, the condition should get fixed by a redesign rather 
than by handling/ignoring an exception.  As stated in the Error javadoc


An Error is a subclass of Throwable that indicates serious problems 
that a reasonable application should not try to catch. Most such 
errors are abnormal conditions. The ThreadDeath error, though a 
"normal" condition, is also a subclass of Error because most 
applications should not try to catch it.


if this idea seems to radical, I am ok with making it an 
IllegalArgumentException.


-andy

*From: *Kevin Rushforth 
*Date: *Friday, 2022/07/22 at 13:42
*To: *Andy Goryachev , 
openjfx-dev@openjdk.org 

*Subject: *Re: [External] : Aw: Proposal: Add Skin.install() method

I don't know if you really meant Error, as in java.lang.Error, but it 
would need to be a subclass of RuntimeException. 
IllegalArgumentException seems the natural choice (a case could 
possibly be made for IllegalStateException). Throwing an Error is not 
the right thing for a library to do in response to an application 
passing in an illegal or unexpected argument to a method or 
constructor. It is for truly exceptional things that a programmer 
cannot anticipate (like running out of memory).


-- Kevin

On 7/22/2022 12:37 PM, Andy Goryachev wrote:

I would rather throw an Error in Skinnable.setSkin() when mismatch
is detected.  This is a design error that should be caught early
in development rather than a run time exception.

-andy

*From: *openjfx-dev 
 on behalf of Kevin Rushforth
 
*Date: *Friday, 2022/07/22 at 12:33
*To: *openjfx-dev@openjdk.org 

*Subject: *Re: [External] : Aw: Proposal: Add Skin.install() method

I would not be in favor of adding a no-arg constructor to
SkinBase, for the reasons Andy gave. Additionally, there would be
no way to avoid braking the contract of Skin::getSkinnable which says:

"This value will only ever go from a non-null to null value when
the Skin is removed from the Skinnable, and only as a consequence
of a call to dispose()."



At the very minimum, we should explain in Skin javadoc that
creating a skin for one control and setting it in the other is
a no-no.  Or, perhaps we should explicitly check for this
condition in setSkin().


I agree completely. At a minimum this enhancement should change
the docs for setSkin to say that a skin created for one control
should not (must not?) be used in another control. And unless
there is a legitimate use case I haven't thought of, I think we
could consider an explicit check, and either throw an Exception
(this seems the best choice, unless there are compatibility
concerns), or else log a warning and treat it as a no-op.

-- Kevin


On 7/22/2022 9:13 AM, Andy Goryachev wrote:

You do bring a good point!  I don't know the rationale behind
passing control pointer to the Skin constructor.

I think Swing got it right, clearly separating

 1. instantiation (using either a no-arg constructor, or any
other constructor that does not require component pointer)
 2. configuration (optional step, possibly widely separated in
time and space)
 3. uninstallation of the old skin
 4. installation of the new skin

What you are proposing - moving to a default constructor makes
the most sense.  It comes with a high price though - everyone
with a custom skin implementation would need to change their
code.

At the very minimum, we should explain in Skin javadoc that
creating a skin for one control and setting it in the other is
a no-no.  Or, perhaps we should explicitly check for this
 

Re: Proposal: Bump minimum JDK version for JavaFX 20 to JDK 17

[Philip Race]

I've read the various comments so far and so have weighed those and my 
view is that
it is about time to move on from JDK11 and think a policy of making the 
minimum an LTS is a

reasonable position - so JDK 17 LTS is what comes out of that today.

What to do in future (ie what is the policy) is a separate question

OpenJDK LTS releases will be every two years in future, so there is a 
reasonable argument that

is too frequent to bump the FX minimum without a really compelling reason.

Also consider that FX 20 will GA 4 1/2 years after FX 11  and the next 
JDK LTS will be 21 ..
just 6 months later .. we surely aren't going to bump the minimum again 
immediately.


So we should not have a policy of the "latest LTS" should always be the 
minimum - just that it should

be "some" LTS

And perhaps we skip every other LTS or at the very least we don't bump 
until the LTS has been available for 1 year ..


-phil.

PS I agree this should never be an invitation for code churn with no 
conceivable benefit to the users of the platform.



On 7/19/22 6:44 AM, Kevin Rushforth wrote:
Even though we build JavaFX binaries with JDK 18 as the boot JDK, the 
latest version of JavaFX still runs with JDK 11 (and is capable of 
being built using JDK 12 or later, and with some limitations, using 
JDK 11), although it isn't tested with older JDK versions. In order 
for JavaFX to be able to use newer JDK features, such as records, 
switch expressions, text blocks, and so forth, we need to increase the 
minimum version of the JDK that can run the latest JavaFX. 
Additionally, there is an ongoing cost to keeping JavaFX buildable and 
runnable on older versions of Java, and very little reason to continue 
to do so.


To this end, I propose to bump the minimum version of the JDK needed 
to run JavaFX 20 to JDK 17. I filed JDK-8290530 [1] to track this. 
This will not affect update releases of earlier versions of JavaFX 
(e.g., JavaFX 17.0.NN), which will continue to run with the same 
minimum JDK that they run on today.


As a reminder, we only assure that JavaFX NN will run with JDK NN-1 or 
later, although in practice, we haven't bumped the minimum required 
JDK version in several releases. So, while JavaFX 19 is built using 
JDK 18 as the boot JDK, it produces class files that will run with JDK 
11, using "--source 11 --target 11". The proposed change discussed 
here would update that in JavaFX 20 to "--source 17 --target 17".


NOTE: this will not be an invitation to do wholesale refactoring of 
existing classes or methods to use newer language features (e.g., a PR 
that turns a bunch of existing data classes into records would not be 
welcome). Rather, this can be seen as enabling judicious use of new 
features in new code, much as we did when we started allowing the use 
of "var".


Absent a compelling reason to remain stuck in the past, I plan to send 
out a pull request for this change next week.


Comments are welcome.

-- Kevin

[1] https://bugs.openjdk.org/browse/JDK-8290530