Dark Mode and brushMetalLook

[sreilly]

Original report by me.

---

I've been using a copy of appbundler compiled a couple years ago to build my app launchers, but recently took a look at making some changes and re-compiled. When launching my app using the new launcher, I found the appearance had changed. The apple.awt.brushMetalLook property had been applied to the app's frame root panes and...

1. On a Mac upgraded to Mojave and set Dark Mode, not only was the title bar dark, but areas where the brush-metal look should have been visible were also dark.

2. On a Mac using High Sierra and on the Mojave Mac in Light Mode, the color of the brush-metal look areas had changed slightly and there was no longer a clean transition between the title bar at the top of the window and a toolbar area directly below it.

This isn't really a bug with appbundler so much as a warning to others that might be using brush-metal look to be wary. It took me a couple hours to figure out that the problem described in (2) above was not something I messed up in my own code but was due to changes elsewhere.

Luckily I held onto my older compiled copy of appbundler and can continue to use it until I update my app's look to no longer use the brush-metal look.

I also tried modifying the appbundler native code to check if Dark Mode was enabled and to set a flag to be passed to the Java app, but that somehow caused the launcher to crash and burn. If anyone else figures out to pass dark-mode info to the Java code, I'd like to know how you did it.

[sreilly]

I believe I figured out how to get app bundler to pass along whether Dark Mode is on when starting up a java app without crashing. But of course, it only works at the launch time. If the user switches between Dark and Light Mode while the Java app is running, that's another issue to solve.

If anyone thinks this is useful, comment here, and I'll add it to the appbundler code.

[sreilly]

Personally, I'd love to see support for Dark/Light Mode detection upon startup. Even better would be a way to update the mode status while running... even if it's just changing an entry in the system properties.

[sreilly]

I've pushed a commit for the initial detection. After that,...?

[sreilly]

Not so keen on the dark mode but I've noticed the changed appearance of apple.awt.brushMetalLook switch. It intrigues me because launching the jar from the command line looks different and correct. Not enough expertise to investigate but this looks very much an issue with the launcher.

edit: no luck scouring the jdk sources I'm not an ObjC developer. However with the Digital Colour Meter it is clear that the title bar is the only colour that varies with a smooth gradient if launched from the command line java -jar, and a much narrower gradient launched from main.m in the appbundler repo via libjli.dylib interface. So not really an appbundler issue as far as I can tell since this seems the approved way to launch.

However, it looks to me that the dark mode switching is an incidental side-effect of the launcher and the recent (Mojave) changes to Apple's platform. I'd be surprised if it is officially supported so I would suggest holding off customizing your launcher. It only seems to effect the textured window background see CPlatformWindow.java in jdk sources.

[patrickangle]

If at all possible, can this issue be reopened, as it was never really resolved.

For what it's worth, I've run in to the same issue. After some brief experimentation, I found that the issue is not present if I build on Mac OS X 10.10 Yosemite, but is present when I build on macOS 10.15 Catalina. I still have some more experimenting to do to determine when this broke, but right now we are going to ship with a slightly modified version of the launcher that can still be built against OS X 10.10.

In order to build on 10.10, we had to replace all the new NSEventModifierFlags with their old deprecated values, but otherwise the launcher built as-is. (https://developer.apple.com/documentation/appkit/nseventmodifierflags?language=objc)

I'll loop back when I narrow down when exactly this issue appeared; hopefully there is a resolution that will allow us to return to building the launcher on a modern version of macOS again.

[rsbfox]

@patrickangle

Try adding <plistentry key="NSRequiresAquaSystemAppearance" value="true" type="boolean"/> to your build.

I think that might help.

[patrickangle]

Oh man, I'd forgotten about this. Unfortunately, we furloughed everyone in our software group due to the coronavirus, including myself, so haven't really moved forward on anything. I've been learning SwiftUI and SceneKit in my new free time, but I do recall making progress on this in the weeks leading up to that.

@rsbfox, If I'm interpreting that entry correctly, it will force the app to run in light mode, which isn't our desired behavior.

I'll take a look at this tomorrow so we can look at closing this issue out. Looking at the source code, we defined a method that called this for us using the Java-Objective-C-Bridge (https://github.com/shannah/Java-Objective-C-Bridge)

public static void setWindowTitlebarAppearsTransparent(Window window, boolean titlebarAppearsTransparent) {
    if (isMac()) {
        long windowPointer = getNativeWindowPointer(window);
        if (windowPointer != -1) {
            CocoaUtils.dispatch_sync(() -> {
                Proxy windowProxy = new Proxy(new Pointer(windowPointer));
                windowProxy.send("setTitlebarAppearsTransparent:", titlebarAppearsTransparent);
            });
        }
    }
}

with getNativeWindowPointer(…) defined as such…

public static long getNativeWindowPointer(Window window) {
    if (isMac()) {
        if (!window.isDisplayable()) {
            window.addNotify();
        }

        Object peer = AWTAccessor.getComponentAccessor().getPeer(window);
        try {

            Class lwWindowPeerClass = AquaUtils.class.getClassLoader().loadClass("sun.lwawt.LWWindowPeer");
            Method getPlatformWindowMethod = lwWindowPeerClass.getMethod("getPlatformWindow");

            Object platformWindow = getPlatformWindowMethod.invoke(peer);

            Class cPlatformWindowClass = AquaUtils.class.getClassLoader().loadClass("sun.lwawt.macosx.CFRetainedResource");
            Field f = cPlatformWindowClass.getDeclaredField("ptr");
            f.setAccessible(true);
            return (long) f.get(platformWindow);
        } catch (Exception e) {
            e.printStackTrace();
            return -1;
        }
    } else {
        return -1;
    }
}

The implementation of isMac() is inconsequential.

This solved the actual problem, which is that Apple now expects you to call setTitlebarAppearsTransparent on your NSWindow to make the titlebar not draw it's own background. We combine the above code with the Mac-specific apple.awt.brushMetalLook client property on the JFrame. A bonus we got here was the the window took on the tint of the wallpaper when Dark Mode is enabled on Catalina. We also force our app into dark mode programmatically from Java but that is a different story for a different time. (Give me a day or two and I'll write it up if anyone is interested.)

Let me shift some code around to produce a working example that doesn't contain the software I was working on for the company, and confirm this is indeed the case.

[rsbfox]

In light mode I see title bars that look like this.

With that entry added they look like this.

So I was thinking it might fix it for you without needing to build on older macOS SDK.