We're off to dark modes, just to 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 itself.
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.
To overview 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 your
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 what a random color, and they know that the background is
light and that it's worked for them until now perfectly fine, now they have to explicitly
set the background.
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 team them to look like the
actual platform widgets, but they're not the platform widgets, they're VCL widgets, but
the GTK case, 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 widget tree looks after itself, so all of that stuff just draws itself and
dark mode automatically.
We've nothing to worry about.
All we have to do then is extract the colors from the team, 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 OK because in the case of GTK, any of the stuff we were using to query for
team 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 rate away, which
would seem obvious, but it's not what's happening on the other platforms, and that's where things
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.
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 widgets here, 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 we have
to roll a file or 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
without the 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 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 at the 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 kind of work with things a bit more difficult than we did in the past.
So it means that our work for tabpings 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 is just
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 is supposed to be 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, shoot, shoot, shot at that.
Mac, it all works fine, so that's what it looks like now, using the new APIs, accent
color, in my case, I was ready to just pick 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 then has the highest difficulty, opting in that you want to tell Windows that you
are a dark mode application.
Any of the stuff that we've been using all this time over the last 20, whatever, plus
years, all those APIs, there isn't an obvious way that Windows has given us to support dark
mode.
In other words, if you actually use Windows in dark mode and you launch the file dialog,
you'll see that it's all the old widgets, but it is using dark mode.
File Explorer moves in dark mode as well, so they do it for their own.
There's various ways of hacking this and undocumented stuff, we pulled out of that
URL and the other projects, blah, blah, blah, all doing it, so there's a whole hecky way
of doing this that is all based on undocumented ordinance, which is very unsatisfactory and
fragile.
Well, that's what we're doing.
These are the APIs that 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 showed in the previous style, if you pretend
to be Explorer or the CFD, common file dialog, then you'll 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 pallets 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, again, set the Explorer
theme or set the CFD theme 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 1, that's what it looks like, and then there's 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 then if you know anything about that, the last
section knows about accessibility, let me know at some stage and we'll figure it out.
So you've got complexities, that's why it's done the way it is, that's the end, thank
you.
Thank you.