2018R2 and Mojave Beta 6 Dark Mode

My initial test using 2018R2 and Mojave Beta 6’s dark mode:

Some controls adapt automatically and look fine - may not require any changes:
• Checkbox
• Radio Button
• PopupMenu (normal ones look fine, but ones attached to a BevelButton or opened by code are not)
• Page Panels
• Tab Panels
• PushButton
• UpDown arrows

Some controls do not, but may be easy to fix(?):
• Labels have the default black text color

Other have deeper issues that may require more work:
• ListBox: the header row is solid black
• ListBox: text defaults to white on white
• BevelButtons do not alter their appearance at all, including the popup menu.
• TextFields and TextAreas: don’t alter their appearance at all.

(Note: these are what I see by enabling dark mode with the tip here:

Dim App As String = CurrentBuildLocation + "/""" + CurrentBuildAppName + ".app"""
Call DoShellCommand("/usr/bin/defaults write " + App + "/Contents/Info ""NSRequiresAquaSystemAppearance"" -bool NO")

Last month I wrote an article for xDev on how to fix most of these, I am also working a newer improved and more fleshed out version of the included code.

The only one I haven’t touched is the BevelButton.

Sam, thanks for that : I may have to buy that issue of xDev. I’m happy to pay for stuff, though in 2018 it’s sad that micro transactions are not a thing yet.

Here’s what I discovered on my own about how to detect Dark Mode:

Public Function IsDarkMode() as boolean
  #if TargetMacOS
    // see https://developer.apple.com/documentation/appkit/nsappearance
    Declare Function NSClassFromString Lib "Foundation" (classname As CFStringRef) As Ptr
    Declare Function NSAppearanceCurrentApperance Lib "Foundation" Selector "currentAppearance" (classname As Ptr) As Ptr
    Declare Function NSAppearanceName Lib "Foundation" Selector "name" (obj As Ptr) As CFStringRef
    dim nsa as Ptr = NSClassFromString("NSAppearance")
    dim currentAppearance as Ptr = NSAppearanceCurrentApperance(nsa)
    if currentAppearance <> nil then
      dim name as string = NSAppearanceName(currentAppearance)
      if name = "NSAppearanceNameDarkAqua" then
        return true
      end if
    end if
    return false
    return false
End Function

[quote=399869:@Michael Diehr]
• Labels have the default black text color

Other have deeper issues that may require more work:
• ListBox: the header row is solid black[/quote]

Labels aren’t native so that can be an issue. A solution is using a textfield instead.

The listbox black header is working fine with the latest macOS beta.

Labels are native on macOS. The problem is that the color is set to black instead of Apple’s built-in text color. We’re working on it.

Are you sure? In my test (Mojave 18a353d), Dark Mode, RB 2018R2 (64 bit), a listbox with a header, the header is solid black. (In light mode, it looks OK).

Yes, I am pretty sure. I don’t see the black listbox headers anymore with macOS 10.14 beta 6

Yeah, sorry I was mistaken it with Windows.

For the BevelButton as a work-around on macOS you can draw a picture with the required color and assign it to the button’s icon. Got the idea from feedback case 28694.
Also I’ve found in Mojave Dark mode that Xojo HTMLViewers don’t update the BG color or text color - it’s the same as light mode.

From what I’ve read, the WebKit engine had this problem in the August 1st build, which would account for it still being wrong in 10.14 b6.

[quote=400154:@Mark Franken]
Also I’ve found in Mojave Dark mode that Xojo HTMLViewers don’t update the BG color or text color - it’s the same as light mode.[/quote]
Why would HTMLViewers do that? It’s the HTML (or perhaps the CSS) which defines the BG and text colours inside the HTMLviewer.

Dark mode in the OS without a dark HtmlViewer doesn’t make much sense. I’ll bet with you that Apple will invert the colors of the HtmlViewer.

Which will screw up a lot of web pages. If someone designs a web page, they define the colours used within it. Using colour names such as “salmon” or “darkpink” or RBG values not unlike Xojo color values. So what is the inverse of “lightgreen”? And which items will “inverting” it apply to? And what happens when MS and the Linux boys decide not to follow suit?

And why would it be up to Apple to invert the colours in an HTMLViewer, which is a Xojo construct? Or are you telling me that future versions of Webkit will do it, so that Safari will also mess with webpages. Fat chance, I venture to suggest.

I seriously doubt it’ll be automatic except maybe for the default background color and default text color that you get if you don’t specify one.

Safari will apparently have a new media query named “prefers-dark-interface” so websites can intelligently choose the light or dark css stylesheets, although it’s not enabled in the preview version that I have yet.

Oh yes, I’ll jump right on that - said no webmaster anywhere … This is the tail wagging the dog again.

BTW - aside from “dark mode” has anyone discovered any new elements within the operating system itself? Everything I’m looking at is specifically related to the default Apple-supplied apps rather than the OS itself.


Well, controls would be one thing. But also anything in the kernel layer (aside form a new version number), or low-level APIs and SDK? I’ve seen a few arbitrary I/O function changes, but they provide the same result as the un-deprecated original variants.

It’s starting to feel like ENCOM OS-12:

[quote] Alan Bradley: Given the prices we charge to students and schools, what sort of improvements have been made in Flynn… I mean, um, ENCOM OS-12?
Richard Mackey: This year we put a “12” on the box. [/quote]

Searching for an API changes documentation turns up this page. https://developer.apple.com/documentation?changes=latest_beta
In contrast, they used to provide a nice single list and explain the changes, now you have to click into each section to see what’s changed, and sometimes through sub sections also.

There doesn’t appear to be much, but that should be a good thing, since Yosemite we’ve had buggy OS update after buggy OS release, and High Sierra was an accumulation of Apple simply trying to change far too much code in such a short amount of time, and not giving themselves enough time to test the software before they squeeze out a new release.

Ultimately I wish Apple would stop trying to ship an OS update every year, and take their time to ship meaningful, stable and trustworthy OS releases. However I don’t see that changing under it’s current administration, so maybe an OS update with minimal changes is a good compromise.