Xojo `Application.AppearanceChanged` Question

The Xojo docs states that the Application.AppearanceChanged event fires:

when a user switches between Light and Dark mode or when the accent color changes.

Two questions:

  1. Does the AppearanceChanged event ever fire on Windows or Linux. If so, can anyone give an example of when that would happen (for instance, I didn’t think Windows has a dark mode).
  2. Is there a way to get the current accent colour using a declare? I’d like to be able to distinguish whether the accent colour changed or light/dark mode switched.
  1. not as far as I know
  2. there is but you have to actually wait to do it in the first bunch of paint events that happen AFTER that change notification has been processed (such fun !) If you try to get it during that event you probably will get the wrong color

I’m not sure there isnt a different notiication you could catch and notice the accent color change

Yes, the code is included as part of the Ohanaware App Kit.

To use them in Xojo they must be rasterized and therefore they lose their dynamism. In the Ohanaware App Kit, there is a module named macOSThemeColors, which caches the rasterized the colors (to save having to rasterize each and every time), the cache needs to be flushed on the appearanceChanged event and rebuilt in the paint event. It must be re-built in a Paint event, otherwise you do NOT the correct colors.

What do you want to use the accent color for, there is another color alternativeControl something or rather, that’s actually closer to the color used for controls.

1 Like

I’m working on helper modules, something similar to your App Kit module (note to self: purchase the OmegaBundle before it’s too late!) but that is truly cross-platform. I’m just currently working on the system colours part of that module and wanted to get access to the accent colour.

Thanks for the tip about caching. That’s helpful.

I might investigate if there are declares for Windows and GTK that can be used because Windows certainly has a dark mode option. I’m guessing Xojo just doesn’t catch it yet.

Why is nothing straightforward?!

That’s tricky. I’m trying to subclass the main Application to force updating the colours at the correct moment. I’m guessing there’s no way for the application class to know when the first paint after the appearance change occurs so it can globally refresh the colour caches?

I think that’s a question for the ages!

It could be, but that requires Xojo change their code for handling colors, and create a color class that doesn’t use 8-Bit integers, one that allows for 32-Bit floats, images, code and so on…

1 Like

Might as well bite the bullet and move it all to doubles since that is usable x-platform
But that still only gets us so far as you noted since NSColor can use patterns and other non solid color items as “Colors”
Windows has pen patterns as well so Xojo could abstract that away

We’ll see

I filed a feature request
feedback://showreport?report_id=60758

1 Like

Just don’t rely on FillColor on BS: feedback://showreport?report_id=60914

1 Like

I mostly just use my own cross platform SystemColors module
I swear I posted it somewhere

AH NO its in my BevelbuttonReplacement
There’s an entire cross platform color module in there

2 Likes

Nabbed it - thanks!

Also chucked in a GitHub star too :star: . They’re collectors items :slight_smile:

Since 10.14 Apple have recommend not actually drawing themed colors anymore!

If you want an area filled with a certain “material”, they recommend using a NSVisualEffectView or a NSBox. You can get NSVisualEffectView in my AppKit or other library. An NSBox, is what Xojo calls a GroupBox! Which can be configured to display without a border or label, just filling a certain “material”. Apple even suggests using a NSBox, because it’s backwards compatible all the way to 10.5. Which I thought was funny, because this Apple doesn’t normally give a **** about backwards compatibility.

@samRowlands: no thanks.

a) I hate translucency. It’s stupid, it doesn’t have any reason for existing.
b) The code for NSVisualEffectView is the typical Objective-C code which is way above my head.
c) Are you kidding with the groupbox.

In v1.0.3 of my App Kit, I made a NSVisualEffectView control that you can layout and configure in the Xojo IDE.

Nope. Am not kidding, and if you’d like I can add the options to customize it in a future App Kit update.

I’m going to be creating more control subclasses that make it easier to configure controls in the Xojo IDE with the options that Xojo doesn’t expose.

But the direct declares (which are also included in this kit) are the fastest way (pragmatically) and because they’re in modules, they add minimal weight to your application.

1 Like