<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    Never mind about not knowing whether it's a JavaFX or an AWT bug.
    It's either a JavaFX bug or an inherent limitation.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    -- Kevin<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 2/12/2024 9:26 AM, Kevin Rushforth
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:c0ffc738-7279-4f4f-a0c5-aad6f5c8f043@oracle.com">
      
      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.<br>
      <br>
      -- Kevin<br>
      <br>
      <div class="moz-cite-prefix">On 2/12/2024 9:20 AM, Kevin Rushforth
        wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:34a27bca-fcf0-47ff-9c83-78bfa588dd22@oracle.com"> 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:<br>
        <br>
            public static void main(String[] args) {<br>
                java.awt.Toolkit.getDefaultToolkit();<br>
                PlatformPreferencesChangedTest.main(args);<br>
            }<br>
        <br>
        I'll file a bug...not sure yet whether it is AWT or JavaFX.<br>
        <br>
        -- Kevin<br>
        <br>
        <div class="moz-cite-prefix">On 2/12/2024 9:00 AM, Christopher
          Schnick wrote:<br>
        </div>
        <blockquote type="cite" cite="mid:4954a717-a3c4-4b40-a3b8-17ca18d6ea36@xpipe.io">
          <p>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.<br>
          </p>
          <div class="moz-cite-prefix">On 12/02/2024 17:49, Kevin
            Rushforth wrote:<br>
          </div>
          <blockquote type="cite" cite="mid:fb1d74b7-6176-45b4-9d7d-9a363f5bee17@oracle.com">
            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.<br>
            <br>
            -- Kevin<br>
            <br>
            <br>
            <div class="moz-cite-prefix">On 2/12/2024 8:36 AM,
              Christopher Schnick wrote:<br>
            </div>
            <blockquote type="cite" cite="mid:59d65b12-ea31-44fa-9eec-f4b08d5a7a08@xpipe.io">
              <p>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.</p>
              <p>Interestingly, I found another issue that occurs when
                that call to <code>GraphicsEnvironment</code> 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.<br>
              </p>
              <div class="moz-cite-prefix">On 12/02/2024 17:20, Kevin
                Rushforth wrote:<br>
              </div>
              <blockquote type="cite" cite="mid:7b44ecf1-98c7-4ec6-9923-e75190167f32@oracle.com"> That likely
                means that initializing the AWT toolkit is interfering
                with this functionality.<br>
                <br>
                I presume you are using a very recent ea build of JavaFX
                22. What version of JDK are you using?<br>
                <br>
                -- Kevin<br>
                <br>
                <br>
                <div class="moz-cite-prefix">On 2/10/2024 9:05 PM,
                  Christopher Schnick wrote:<br>
                </div>
                <blockquote type="cite" cite="mid:37b90a7c-3ab4-456b-8176-080f45c70a12@xpipe.io">
                  <p>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.<br>
                  </p>
                  <p><code>    public static void main(String[] args) {<br>
                             
                      GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();<br>
                              Application.launch(args);<br>
                          }</code><br>
                  </p>
                  <div class="moz-cite-prefix">On 10/02/2024 18:44,
                    Michael Strauß wrote:<br>
                  </div>
                  <blockquote type="cite" cite="mid:CAJEpuXS15eZJnDfBc1vM5LTWh2j6MhyiFZR5X3zSixF0USTXBA@mail.gmail.com">
                    <pre class="moz-quote-pre" wrap="">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:
<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java__;!!ACWV5N9M2RV99hQ!PsHHFoR8XCdbV3jjVYuRdGnFdOZPyZ9PT7abJ7MpVwRo32pMwS1fKmEtgUHlJoud0s9GMXAwuVrG0xFGCiGZUXqZ$" moz-do-not-send="true">https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java</a>

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 <a class="moz-txt-link-rfc2396E" href="mailto:crschnick@xpipe.io" moz-do-not-send="true"><crschnick@xpipe.io></a> wrote:
</pre>
                    <blockquote type="cite">
                      <pre class="moz-quote-pre" wrap="">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.
</pre>
                    </blockquote>
                  </blockquote>
                </blockquote>
                <br>
              </blockquote>
            </blockquote>
            <br>
          </blockquote>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>