Re: [External] : Re: Platform preferences theme detection

[Kevin Rushforth]

Good to hear. Thanks for confirming.

-- Kevin

On 2/15/2024 4:46 AM, Christopher Schnick wrote:


Just wanted to let you know that after setting 
apple.awt.application.appearance=system everything works as expected 
now. Thanks for all the work on this great feature. I plan to release 
the next version of our application with platform preferences 
integration soon to production.


On 13/02/2024 20:11, Michael Strauß wrote:

The reason why the values are wrong might be that in PlatformSupport.m
L105, we query [NSApp effectiveApperance], but this always seems to
return the light appearance if JavaFX doesn't own the NSApplication.

On Mon, Feb 12, 2024 at 6:26 PM Kevin Rushforth
  wrote:

Actually, it's worse than not detecting changes, it's simply not getting the 
right values at all. If I run the program when the system appearance is already 
in Dark mode, it doesn't get the correct values at start up.

-- Kevin

Re: [External] : Re: Platform preferences theme detection

[Christopher Schnick]

Just wanted to let you know that after setting 
apple.awt.application.appearance=system everything works as expected 
now. Thanks for all the work on this great feature. I plan to release 
the next version of our application with platform preferences 
integration soon to production.


On 13/02/2024 20:11, Michael Strauß wrote:

The reason why the values are wrong might be that in PlatformSupport.m
L105, we query [NSApp effectiveApperance], but this always seems to
return the light appearance if JavaFX doesn't own the NSApplication.

On Mon, Feb 12, 2024 at 6:26 PM Kevin Rushforth
  wrote:

Actually, it's worse than not detecting changes, it's simply not getting the 
right values at all. If I run the program when the system appearance is already 
in Dark mode, it doesn't get the correct values at start up.

-- Kevin

Re: [External] : Re: Platform preferences theme detection

[Kevin Rushforth]

I filed https://bugs.openjdk.org/browse/JDK-8325888 to track this.

-- Kevin

On 2/13/2024 11:11 AM, Michael Strauß wrote:

The reason why the values are wrong might be that in PlatformSupport.m
L105, we query [NSApp effectiveApperance], but this always seems to
return the light appearance if JavaFX doesn't own the NSApplication.

On Mon, Feb 12, 2024 at 6:26 PM Kevin Rushforth
 wrote:

Actually, it's worse than not detecting changes, it's simply not getting the 
right values at all. If I run the program when the system appearance is already 
in Dark mode, it doesn't get the correct values at start up.

-- Kevin

Re: [External] : Re: Platform preferences theme detection

[Michael Strauß]

The reason why the values are wrong might be that in PlatformSupport.m
L105, we query [NSApp effectiveApperance], but this always seems to
return the light appearance if JavaFX doesn't own the NSApplication.

On Mon, Feb 12, 2024 at 6:26 PM Kevin Rushforth
 wrote:
>
> Actually, it's worse than not detecting changes, it's simply not getting the 
> right values at all. If I run the program when the system appearance is 
> already in Dark mode, it doesn't get the correct values at start up.
>
> -- Kevin

Re: [External] : Re: Platform preferences theme detection

[Kevin Rushforth]

Never mind about not knowing whether it's a JavaFX or an AWT bug. It's 
either a JavaFX bug or an inherent limitation.


The problem you are running into is that when the AWT toolkit is 
initialized before the JavaFX toolkit, then necessarily, AWT is in 
charge of the NSApplication. Prior to the macOS 14 fixes I was 
mentioning, AWT used to take change even when it shouldn't have, but now 
that's been fixed (both in AWT and JavaFX). Whichever toolkit is started 
first owns the NSApplication, and installs its NSApplicationDelegate. 
This means that NSApplication{Delegate} callbacks are only delivered to 
the toolkit that owns it.


I haven't checked this, but my guess is that the 
"NSDistributedNotificationCenter" methods being used to listen to 
preferences don't get called when JavaFX is not the NSApplication owner.


-- Kevin


On 2/12/2024 9:26 AM, Kevin Rushforth wrote:
Actually, it's worse than not detecting changes, it's simply not 
getting the right values at all. If I run the program when the system 
appearance is already in Dark mode, it doesn't get the correct values 
at start up.


-- Kevin

On 2/12/2024 9:20 AM, Kevin Rushforth wrote:
I can reproduce this on macOS 13.x using JDK 21.0.2 and the latest 
JavaFX. If I run the PlatformPreferencesChangedTest program in 
tests/manual/events we correctly detect the appearance changes. If I 
first initialize the AWT toollkit as follows, then it doesn't detect 
the changes:


    public static void main(String[] args) {
    java.awt.Toolkit.getDefaultToolkit();
    PlatformPreferencesChangedTest.main(args);
    }

I'll file a bug...not sure yet whether it is AWT or JavaFX.

-- Kevin

On 2/12/2024 9:00 AM, Christopher Schnick wrote:


Just tested with JDK 21.0.2 and the behavior is unchanged. I don't 
have an older macOS version <14 to test whether this issue is 
actually specific to 14 or not.


On 12/02/2024 17:49, Kevin Rushforth wrote:
There were changes to AWT in JDK 22 for macOS 14, so it might be 
worth trying JDK 21.0.2. In the mean time, I'll do some testing of 
this as well now that I know it is related to initializing the AWT 
toolkit.


-- Kevin


On 2/12/2024 8:36 AM, Christopher Schnick wrote:


I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on 
macOS. I guess I can try upgrading to JDK 21.0.2, but I will just 
assume that there haven't been many changes to awt in that time.


Interestingly, I found another issue that occurs when that call to 
|GraphicsEnvironment| is made/not made where it is not possible to 
quit a JavaFX application via the dock quit operation when it is 
minimized to an AWT tray icon. I can file a separate issue for that.


On 12/02/2024 17:20, Kevin Rushforth wrote:
That likely means that initializing the AWT toolkit is 
interfering with this functionality.


I presume you are using a very recent ea build of JavaFX 22. What 
version of JDK are you using?


-- Kevin


On 2/10/2024 9:05 PM, Christopher Schnick wrote:


Well, that is going to be a fun one to debug ... In my 
application I check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). 
If you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment 
your PlatformPreferencesChangedTest application with this main 
method, it no longer works. Also, it throws another exception 
when clicking on the fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: [External] : Re: Platform preferences theme detection

[Kevin Rushforth]

I can reproduce this on macOS 13.x using JDK 21.0.2 and the latest 
JavaFX. If I run the PlatformPreferencesChangedTest program in 
tests/manual/events we correctly detect the appearance changes. If I 
first initialize the AWT toollkit as follows, then it doesn't detect the 
changes:


    public static void main(String[] args) {
    java.awt.Toolkit.getDefaultToolkit();
    PlatformPreferencesChangedTest.main(args);
    }

I'll file a bug...not sure yet whether it is AWT or JavaFX.

-- Kevin

On 2/12/2024 9:00 AM, Christopher Schnick wrote:


Just tested with JDK 21.0.2 and the behavior is unchanged. I don't 
have an older macOS version <14 to test whether this issue is actually 
specific to 14 or not.


On 12/02/2024 17:49, Kevin Rushforth wrote:
There were changes to AWT in JDK 22 for macOS 14, so it might be 
worth trying JDK 21.0.2. In the mean time, I'll do some testing of 
this as well now that I know it is related to initializing the AWT 
toolkit.


-- Kevin


On 2/12/2024 8:36 AM, Christopher Schnick wrote:


I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on 
macOS. I guess I can try upgrading to JDK 21.0.2, but I will just 
assume that there haven't been many changes to awt in that time.


Interestingly, I found another issue that occurs when that call to 
|GraphicsEnvironment| is made/not made where it is not possible to 
quit a JavaFX application via the dock quit operation when it is 
minimized to an AWT tray icon. I can file a separate issue for that.


On 12/02/2024 17:20, Kevin Rushforth wrote:
That likely means that initializing the AWT toolkit is interfering 
with this functionality.


I presume you are using a very recent ea build of JavaFX 22. What 
version of JDK are you using?


-- Kevin


On 2/10/2024 9:05 PM, Christopher Schnick wrote:


Well, that is going to be a fun one to debug ... In my application 
I check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). 
If you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment 
your PlatformPreferencesChangedTest application with this main 
method, it no longer works. Also, it throws another exception when 
clicking on the fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: [External] : Re: Platform preferences theme detection

[Kevin Rushforth]

Actually, it's worse than not detecting changes, it's simply not getting 
the right values at all. If I run the program when the system appearance 
is already in Dark mode, it doesn't get the correct values at start up.


-- Kevin

On 2/12/2024 9:20 AM, Kevin Rushforth wrote:
I can reproduce this on macOS 13.x using JDK 21.0.2 and the latest 
JavaFX. If I run the PlatformPreferencesChangedTest program in 
tests/manual/events we correctly detect the appearance changes. If I 
first initialize the AWT toollkit as follows, then it doesn't detect 
the changes:


    public static void main(String[] args) {
    java.awt.Toolkit.getDefaultToolkit();
    PlatformPreferencesChangedTest.main(args);
    }

I'll file a bug...not sure yet whether it is AWT or JavaFX.

-- Kevin

On 2/12/2024 9:00 AM, Christopher Schnick wrote:


Just tested with JDK 21.0.2 and the behavior is unchanged. I don't 
have an older macOS version <14 to test whether this issue is 
actually specific to 14 or not.


On 12/02/2024 17:49, Kevin Rushforth wrote:
There were changes to AWT in JDK 22 for macOS 14, so it might be 
worth trying JDK 21.0.2. In the mean time, I'll do some testing of 
this as well now that I know it is related to initializing the AWT 
toolkit.


-- Kevin


On 2/12/2024 8:36 AM, Christopher Schnick wrote:


I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on 
macOS. I guess I can try upgrading to JDK 21.0.2, but I will just 
assume that there haven't been many changes to awt in that time.


Interestingly, I found another issue that occurs when that call to 
|GraphicsEnvironment| is made/not made where it is not possible to 
quit a JavaFX application via the dock quit operation when it is 
minimized to an AWT tray icon. I can file a separate issue for that.


On 12/02/2024 17:20, Kevin Rushforth wrote:
That likely means that initializing the AWT toolkit is interfering 
with this functionality.


I presume you are using a very recent ea build of JavaFX 22. What 
version of JDK are you using?


-- Kevin


On 2/10/2024 9:05 PM, Christopher Schnick wrote:


Well, that is going to be a fun one to debug ... In my 
application I check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). 
If you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment 
your PlatformPreferencesChangedTest application with this main 
method, it no longer works. Also, it throws another exception 
when clicking on the fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: [External] : Re: Platform preferences theme detection

[Christopher Schnick]

Just tested with JDK 21.0.2 and the behavior is unchanged. I don't have 
an older macOS version <14 to test whether this issue is actually 
specific to 14 or not.


On 12/02/2024 17:49, Kevin Rushforth wrote:
There were changes to AWT in JDK 22 for macOS 14, so it might be worth 
trying JDK 21.0.2. In the mean time, I'll do some testing of this as 
well now that I know it is related to initializing the AWT toolkit.


-- Kevin


On 2/12/2024 8:36 AM, Christopher Schnick wrote:


I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on macOS. 
I guess I can try upgrading to JDK 21.0.2, but I will just assume 
that there haven't been many changes to awt in that time.


Interestingly, I found another issue that occurs when that call to 
|GraphicsEnvironment| is made/not made where it is not possible to 
quit a JavaFX application via the dock quit operation when it is 
minimized to an AWT tray icon. I can file a separate issue for that.


On 12/02/2024 17:20, Kevin Rushforth wrote:
That likely means that initializing the AWT toolkit is interfering 
with this functionality.


I presume you are using a very recent ea build of JavaFX 22. What 
version of JDK are you using?


-- Kevin


On 2/10/2024 9:05 PM, Christopher Schnick wrote:


Well, that is going to be a fun one to debug ... In my application 
I check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). 
If you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment your 
PlatformPreferencesChangedTest application with this main method, 
it no longer works. Also, it throws another exception when clicking 
on the fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: [External] : Re: Platform preferences theme detection

[Kevin Rushforth]

There were changes to AWT in JDK 22 for macOS 14, so it might be worth 
trying JDK 21.0.2. In the mean time, I'll do some testing of this as 
well now that I know it is related to initializing the AWT toolkit.


-- Kevin


On 2/12/2024 8:36 AM, Christopher Schnick wrote:


I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on macOS. 
I guess I can try upgrading to JDK 21.0.2, but I will just assume that 
there haven't been many changes to awt in that time.


Interestingly, I found another issue that occurs when that call to 
|GraphicsEnvironment| is made/not made where it is not possible to 
quit a JavaFX application via the dock quit operation when it is 
minimized to an AWT tray icon. I can file a separate issue for that.


On 12/02/2024 17:20, Kevin Rushforth wrote:
That likely means that initializing the AWT toolkit is interfering 
with this functionality.


I presume you are using a very recent ea build of JavaFX 22. What 
version of JDK are you using?


-- Kevin


On 2/10/2024 9:05 PM, Christopher Schnick wrote:


Well, that is going to be a fun one to debug ... In my application I 
check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). 
If you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment your 
PlatformPreferencesChangedTest application with this main method, it 
no longer works. Also, it throws another exception when clicking on 
the fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: Platform preferences theme detection

[Christopher Schnick]

I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on macOS. I 
guess I can try upgrading to JDK 21.0.2, but I will just assume that 
there haven't been many changes to awt in that time.


Interestingly, I found another issue that occurs when that call to 
|GraphicsEnvironment| is made/not made where it is not possible to quit 
a JavaFX application via the dock quit operation when it is minimized to 
an AWT tray icon. I can file a separate issue for that.


On 12/02/2024 17:20, Kevin Rushforth wrote:
That likely means that initializing the AWT toolkit is interfering 
with this functionality.


I presume you are using a very recent ea build of JavaFX 22. What 
version of JDK are you using?


-- Kevin


On 2/10/2024 9:05 PM, Christopher Schnick wrote:


Well, that is going to be a fun one to debug ... In my application I 
check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). 
If you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment your 
PlatformPreferencesChangedTest application with this main method, it 
no longer works. Also, it throws another exception when clicking on 
the fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: Platform preferences theme detection

[Kevin Rushforth]

That likely means that initializing the AWT toolkit is interfering with 
this functionality.


I presume you are using a very recent ea build of JavaFX 22. What 
version of JDK are you using?


-- Kevin


On 2/10/2024 9:05 PM, Christopher Schnick wrote:


Well, that is going to be a fun one to debug ... In my application I 
check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). 
If you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment your 
PlatformPreferencesChangedTest application with this main method, it 
no longer works. Also, it throws another exception when clicking on 
the fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: Platform preferences theme detection

[Christopher Schnick]

Well, that is going to be a fun one to debug ... In my application I 
check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). If 
you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment your 
PlatformPreferencesChangedTest application with this main method, it no 
longer works. Also, it throws another exception when clicking on the 
fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: Platform preferences theme detection

[Michael Strauß]

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:
>
> I checked again, restarted everything, but still the same problem:
>
> Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
> Plasma. The preferences values there are all detected correctly, but are 
> never updated at runtime when changed in the settings menu.

Re: Platform preferences theme detection

[Michael Strauß]

Hi Christopher,

the relevant preferences for color scheme detection are
textColor=0x00ff and textBackgroundColor=0x on your system.

That's pretty strange, I'm getting the following values on macOS Sonoma
14.3.1 M1:
in light mode: textColor=0x00ff, textBackgroundColor=0x
in dark mode: textColor=0x, textBackgroundColor=0x1e1e1eff

Consequently, I'm also getting the correct color scheme when I'm switching
between light and dark mode on macOS (verified with the
PlatformPreferencesChangedTest application).



On Sat, Feb 10, 2024 at 5:55 AM Christopher Schnick 
wrote:

> Lastly I also tried it on macOS. The accent color detection works there,
> but the color scheme detection does not, i.e. it always returns light mode.
> I'm using macOS Sonoma 14.3 with aarch64.
>
> Here are the preferences when dark mode is set in the settings:
>
>
>
> So since you are thinking about making this a preview-only feature, I
> don't think there is that much to do to properly handle systems where some
> properties are not supported. Just a few methods to set the default value
> of foreground, background, and accent color would be enough. In theory I
> don't need to know exactly what color observation is supported, I only want
> to have the ability to use my own colors as defaults in that case.
>
> Best
> Christopher Schnick
>
>

Re: Platform preferences theme detection

[Christopher Schnick]

Alright, if the accent is not supported yet then almost everything is 
fine I guess. The settings issue is not noticeable as all the updates 
happen very fast.


I want to open my previous question about detecting unsupported colors 
again here. So I assume that for example accent detection is not 
supported on any Linux system and I have not tested yet how widespread 
the support for color scheme detection is on other desktop environments. 
From an application developer's point of view, the platform preferences 
feature loses some appeal if there is no way of enabling a control flow 
like: If the system color is supported use that one, else use the color 
that I manually define somehow.


So it would be nice to either have a relatively simple way of detecting 
which basic color property foreground, background, accent, color scheme 
is actually supported or allow application developers to set the default 
value for that property manually. In this case, I could just set a good 
looking default accent color, which would then be returned on Linux 
systems as that property is not supported yet.


I don't have access to the JBS, I'm not even sure how you get that.

On 2/6/2024 1:26 AM, Michael Strauß wrote:

Hi Christopher!

1) Accent color detection is not yet implemented for Linux/GTK. I 
think this is a fairly recent addition for Ubuntu, probably in version 22.


2) I don't see this behavior on my Ubuntu 20.04 system (need to 
upgrade to 23 and test again). If you have acess to JBS, feel free to 
open a bug ticket to track this issue.



On Mon, Feb 5, 2024 at 10:56 PM Christopher Schnick 
 wrote:


I finally found some time to test the latest ea build and can
confirm that it works now on Windows as expected.

Next, I moved to Linux, more specifically Ubuntu 23.04, and
encountered some issues:
- The accent color detection does not work, i.e. it does not
initially detect the value set in the settings and also does not
change when I modify the accent color in the Ubuntu Settings. I
can see some values changing in the map, however the end result is
still the same
- When opening the Ubuntu Settings application, the entire
platform preferences map is updated with weird values but somehow
changes back immediately after. Maybe it reports the default light
mode colors for a split second when opening the settings?

Once again I do not know whether this is intended or not as there
is no definitive list of which operating systems are supported.
Here is the obligatory preferences map on that system:

Re: Platform preferences theme detection

[Michael Strauß]

Hi Christopher!

1) Accent color detection is not yet implemented for Linux/GTK. I think
this is a fairly recent addition for Ubuntu, probably in version 22.

2) I don't see this behavior on my Ubuntu 20.04 system (need to upgrade to
23 and test again). If you have acess to JBS, feel free to open a bug
ticket to track this issue.


On Mon, Feb 5, 2024 at 10:56 PM Christopher Schnick 
wrote:

> I finally found some time to test the latest ea build and can confirm that
> it works now on Windows as expected.
>
> Next, I moved to Linux, more specifically Ubuntu 23.04, and encountered
> some issues:
> - The accent color detection does not work, i.e. it does not initially
> detect the value set in the settings and also does not change when I modify
> the accent color in the Ubuntu Settings. I can see some values changing in
> the map, however the end result is still the same
> - When opening the Ubuntu Settings application, the entire platform
> preferences map is updated with weird values but somehow changes back
> immediately after. Maybe it reports the default light mode colors for a
> split second when opening the settings?
>
> Once again I do not know whether this is intended or not as there is no
> definitive list of which operating systems are supported. Here is the
> obligatory preferences map on that system:
>
>
>

Re: Platform preferences theme detection

[Nir Lisker]

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

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

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

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

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

Re: Platform preferences theme detection

[Christopher Schnick]

Hello Nir,

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


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

Hi Christopher,

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


- Nir

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


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

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

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

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

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


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

Hello Michael,

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



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

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

Re: Platform preferences theme detection

[Nir Lisker]

Hi Christopher,

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

- Nir

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

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

Re: Platform preferences theme detection

[Christopher Schnick]

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


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


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


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

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


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


Hello Michael,

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



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

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

Re: Platform preferences theme detection

[Andy Goryachev]

Are you sure it wasn’t change in some version of Windows 10 or between 10 and 
11?  I vaguely recall testing light/dark mode switch on Windows 11.

-andy



From: openjfx-dev  on behalf of Michael Strauß 

Date: Monday, January 29, 2024 at 14:09
To:
Cc: openjfx-dev@openjdk.org 
Subject: Re: Platform preferences theme detection
I see that the names of the platform mappings defined in 
WinApplication::getPlatformKeyMappings() are simply wrong 
("Windows.UIColor.ForegroundColor" instead of "Windows.UIColor.Foreground"), so 
the platform mappings are not applied to the properties.

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


On Mon, Jan 29, 2024 at 10:45 PM Christopher Schnick 
mailto:crschn...@xpipe.io>> wrote:

Hello Michael,

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

[cid:ii_18d573d4eaed3eee5091]

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

[cid:ii_18d573d4eaed3fcfc8a2]

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

Re: Platform preferences theme detection

[Michael Strauß]

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

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


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

> Hello Michael,
>
> I took a look at the implementation and tried to find the issue. From what
> I can see, the mappings returned are correct:
>
>
>
> but it seems like they are somehow not applied the PreferencesProperties:
>
> Let me know whether I can help with anything to debug this issue.
>
>

Re: Platform preferences theme detection

[Christopher Schnick]

Hello Michael,

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




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

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

On 1/29/2024 10:37 PM, Michael Strauß wrote:

Hi Christopher!


- Should this feature work in that ea version?

Yes.



- Is Windows 10 supported by the color scheme detection?

Color scheme detection should be supported on Windows 10 beginning
with build 10240.



- The documentation says that LIGHT is returned in case theme the
detection is not supported. But I guess there is no way to find out
whether querying that property is supported on the current system? It
might be useful in some circumstances to adapt the behavior when we know
that this is not supported.

There is no way to directly query whether any of the
platform-independent properties (colorScheme, backgroundColor,
foregroundColor, accentColor) are supported by the current OS.
You can check whether the platform-dependent mappings (for example,
"Windows.UIColor.Background") are contained in the map, which will
only be the case if supported by the OS.



- The documentation mentions that some preferences might not be
available on the current system. Does that mean that if they are
available, they are also observable? Or might it be possible that a
certain setting is available but does not support dynamically updating
at runtime and cannot be observed?

If you see a mapping for a preference, it should also be updated
automatically if the corresponding OS setting is changed.

Do you see the mappings for "Windows.UIColor.Background" and
"Windows.UIColor.Foreground" in the map returned by
Platform.getPreferences()?
The color scheme value is derived from these colors. If the mappings
are not present, something unexpected is happening.



On Mon, Jan 29, 2024 at 9:23 PM Christopher Schnick  wrote:

Hello,

I just tried out the new 22-ea+27 build to see whether we can utilize
some of the new features, particularly the platform preferences API, to
replace the libraryhttps://github.com/Dansoftowner/jSystemThemeDetector
that we are currently using for theme detection.

I'm running this on Windows 10 with the latest updates and the color
scheme always reports LIGHT, even when dark mode is enabled in the
settings. The observable value also does not update when the value
changes in the settings. Obviously I have a few questions here:
- Should this feature work in that ea version?
- Is Windows 10 supported by the color scheme detection?
- The documentation says that LIGHT is returned in case theme the
detection is not supported. But I guess there is no way to find out
whether querying that property is supported on the current system? It
might be useful in some circumstances to adapt the behavior when we know
that this is not supported.
- The documentation mentions that some preferences might not be
available on the current system. Does that mean that if they are
available, they are also observable? Or might it be possible that a
certain setting is available but does not support dynamically updating
at runtime and cannot be observed?

Best regards
Christopher

Re: Platform preferences theme detection

[Michael Strauß]

Hi Christopher!

> - Should this feature work in that ea version?

Yes.


> - Is Windows 10 supported by the color scheme detection?

Color scheme detection should be supported on Windows 10 beginning
with build 10240.


> - The documentation says that LIGHT is returned in case theme the
> detection is not supported. But I guess there is no way to find out
> whether querying that property is supported on the current system? It
> might be useful in some circumstances to adapt the behavior when we know
> that this is not supported.

There is no way to directly query whether any of the
platform-independent properties (colorScheme, backgroundColor,
foregroundColor, accentColor) are supported by the current OS.
You can check whether the platform-dependent mappings (for example,
"Windows.UIColor.Background") are contained in the map, which will
only be the case if supported by the OS.


> - The documentation mentions that some preferences might not be
> available on the current system. Does that mean that if they are
> available, they are also observable? Or might it be possible that a
> certain setting is available but does not support dynamically updating
> at runtime and cannot be observed?

If you see a mapping for a preference, it should also be updated
automatically if the corresponding OS setting is changed.

Do you see the mappings for "Windows.UIColor.Background" and
"Windows.UIColor.Foreground" in the map returned by
Platform.getPreferences()?
The color scheme value is derived from these colors. If the mappings
are not present, something unexpected is happening.



On Mon, Jan 29, 2024 at 9:23 PM Christopher Schnick  wrote:
>
> Hello,
>
> I just tried out the new 22-ea+27 build to see whether we can utilize
> some of the new features, particularly the platform preferences API, to
> replace the library https://github.com/Dansoftowner/jSystemThemeDetector
> that we are currently using for theme detection.
>
> I'm running this on Windows 10 with the latest updates and the color
> scheme always reports LIGHT, even when dark mode is enabled in the
> settings. The observable value also does not update when the value
> changes in the settings. Obviously I have a few questions here:
> - Should this feature work in that ea version?
> - Is Windows 10 supported by the color scheme detection?
> - The documentation says that LIGHT is returned in case theme the
> detection is not supported. But I guess there is no way to find out
> whether querying that property is supported on the current system? It
> might be useful in some circumstances to adapt the behavior when we know
> that this is not supported.
> - The documentation mentions that some preferences might not be
> available on the current system. Does that mean that if they are
> available, they are also observable? Or might it be possible that a
> certain setting is available but does not support dynamically updating
> at runtime and cannot be observed?
>
> Best regards
> Christopher
>