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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
>
> 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
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.
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).
-
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
: 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 prope
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
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
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
>
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
25 matches
Mail list logo
