We're off to dark modes. Just have a quick look at the various bits that I'm talking about. On the right-hand side, we've got the widget tree. That's what I'm talking about mostly. And then around the document, the application background and the document colors and stuff. I'm calling them application colors, and I'm calling the rest widget tree.

That's a screenshot of dark mode GNOME, our GTK version. And just to overview, in most cases what we have is the issue that you have to inform the platform that your application is opting into dark mode. You have to determine the application colors, the ones that you're going to use for document background and all the rest have to be extracted from

the theme somehow. We have custom widgets in various places. They all need to know the appropriate colors to use foreground and background. The most common obvious problem is that most things have been light mode so far. People have just decided to draw with a random color and they know that the background is light and that it has worked for them until now perfectly fine. Now

you have to explicitly set the background. So if you're a developer here and you're doing previews, you're doing any custom widgets, just make sure you're setting both colors, foreground and background colors together. Not just foreground and the assumption that your background is suitable because it won't be anymore and it isn't. Conversion of GTK to dark mode. There's two different modes of doing things. In GTK, we're using actual native GTK widgets. On the other platform,

we're using our VCL widgets and we theme them to look like the actual platform widgets, but they're not the platform widgets. They're VCL widgets, but the GTKs, they actually are GTK widgets, which means that GTK conversion to dark mode is pretty easy. We just listen to the dark mode change on the platform on GNOME.

We find out whether it's dark mode and we tell GTK that we want GTK to be in dark mode and then all GTK widgetry looks after itself. So all of that stuff just draws itself in dark mode automatically with nothing to worry about. All we have to do then is extract the colors from the theme, tell our custom widgets what colors and foregrounds and backgrounds we want and use the application colors then and the appropriate locations.

That's all okay because in the case of GTK, any of the stuff we were using to query for theme colors continues to work in dark mode. So if we ask for the application background and we put GTK into dark mode and we ask it for an application background,

we get something that we can use to write away, which would seem obvious, but it's not what's happening on the other platforms and that's where things may get quite difficult. Mac OS is medium difficulty. When you opt in by telling Mac OS that you're dark mode enabled and then you query the Mac OS teams for colors, you get results back that are meaningful as long as you stick to the non-deprecated ones.

And some of the cases for Mac, we were not querying the team for background colors. We were just using hard-coded colors. So if we update things pretty much to query what we should be using for the application background color and so forth and so on, we get something meaningful in dark mode as well and it's all easy for those cases.

For the widgetry though, things become more difficult. On Mac, what we have been doing is clicking harder. On Mac, there is a drawing interface we've been using all these years to draw onto our ECL widgets

what the Mac buttons should look like. Those APIs there. If you go Google for the API, you'll find no documentation for them. There seems to be no acknowledgement on any of the Apple documentation pages that this API even exists or ever exists. And the problem is that even in dark mode, it draws in light mode. So any of the stuff we were using on Mac to draw things will only draw light mode.

So it's all out of date and it's all not supported. So the problem there is you have to roll forward to something that is working and there's a whole set of other APIs on Mac that we can use where we actually basically use the real Mac widgets. We keep a few of them cached and we ask the real Mac widgets to render themselves

onto our VCL widgets with blank text so that we get what it looks like. On Mac, some of the things such as buttons will only render in fixed sizes. So if we have the VCL widget that's big and you want to render a Mac button onto it, it'll only render a small slice of it. So you have to make sure that your buttons are the right size

or you have to change Mac buttons into one of the other supported styles which will render into whatever space you give it, but some modes you can't. So it's very tricky. Some of these Mac widgets, if you actually try and create them in a thread, they abort, so you have to actually create them in your main thread

and keep them for when you do want to draw on a thread later on. You can make it work. We're doing things much more at a distance when we're running with the full Mac widgets. We can't render a small part of a scroll bar. You've got to render the scroll bar, basically. So we have to work with things a bit more difficult than we did in the past.

So it means that our work for tab panes and scroll bars are particularly complicated. We've got these focus rings. Our focus rings, even though we attempt to draw them the way the documentation's used to draw them, they're narrower than they should be. So they're not as prominent as I'd like them to be.

There's, again, this draw focus ring mask with frame, which supposedly is supposed to draw these things, but when I try it with different widgets, it works with some. It doesn't work with others. There's a lot of trial and error with a lot of this stuff. This feature for wallpaper tinting, where one thing behind the other shows up, I never got it to work. The accent colors work out of the box.

So let's go shoot a shot of that. On Mac, it all works fine. So that's what it looks like now, using the new APIs. X and color, in my case, was red, I just picked one. Application colors, blah, blah, blah. It all works fine. The changing of all the drawing stuff means that the light mode has changed as well,

hopefully for the better, hopefully. But it has made an effect there. Windows N is the highest difficulty. Opting in that you want to tell Windows that you're a dark mode application. Any of the stuff that we've been using all this time over the last 20-plus years, all those APIs, there isn't an obvious way that Windows has given us to support dark mode.

And if you actually use Windows in dark mode and you launch the file dialogue, you'll see that it's all the old widgets, but it is using dark mode. File Explorer moves to dark mode as well. So they do it for their own. There's various ways of hacking this. Some undocumented stuff we pulled out of that URL and the other projects, blah, blah, blah, are all doing it.

There's a whole hacky way of doing this that is all based on undocumented ordinals, which is very unsatisfactory and fragile. Well, that's what we're doing. These are the APIs we're using there. Again, unlike the Mac case, the APIs still work and they will give you dark mode,

but only for certain things. In other words, only if you pretend to be the two things that we've showed in a previous style. If you pretend to be Explorer or the CFD, common file dialogue, then you render in dark mode, but only for certain widgets, the ones that exist in those two applications. So you have to basically restrict yourself to what palette of widgets are available

in the two cases, which is fine. Scroll bars are fine, but you have to hack them in like that. It's very unsatisfactory, but it does function. Unlike Mac, if you use the case for asking querying for specific colors, you get back the light mode colors if you use the existing APIs. You have to update that. And again, you're limited to the widgets

that are listed earlier. So you have to get, set the Explorer theme or set the CFD team and then query for what you know exists. The big lack is that there is no tab pane or notebook or tab panes available in any of those applications. So in those cases, we're falling back to basically being a button,

which is why we have some complexities around that. Dark mode windows one, that's what it looks like. And then just final stuff, there's other stuff, which is not dark mode, which is even more complicated when it comes to the accessibility high contrast mode. So if anybody who knows anything about that, last section knows about accessibility,

let me know at some stage and we'll figure it out. So that you got complexities, that's why it's done the way it is. That's the end. Thank you.