Dark mode for Qt application

[Carifio24]

This PR contains an implementation of dark mode for the Qt app, suggested in #2332 and endorsed by @aagoodman. This primarily consists of adding the ability to change the application's QPalette, but there are a few elements that require some specific handling. In the UI, changing the application theme is done via the Preferences dialog. Some things to note:

• The two elements that required some custom styling are the data canvases that serve as tab backgrounds (whose colors are explicitly set in the code) and the IPython terminal.
  • The terminal uses the pygments library for syntax highlighting. There are only 3 dark pygment styles that meet the WCAG contrast minimum - of these, I decided to go with rrt.
  • If the user is in "System default" mode, we make a rough attempt to determine whether the mode is closer to light or dark by comparing the window base and text colors, and select the terminal theme accordingly.
• I added three options for the application palette: light, dark, and system default, with the last being the default option in glue. For most people I suspect light and system default will be essentially the same, but one can modify the default system palette so I think having an explicit light mode palette is useful.

There are still a couple of minor issues:

• The icons for the "window" tools (moving between tabs and changing the title) are difficult to see in dark mode. I'm thinking the solution is to change the icons to be a gray color that has decent contrast in both light and dark modes, but I'm open to other suggestions.
• The terminal colors are set via a CSS stylesheet, but the text styling doesn't seem to propagate back to old terminal items, which can make them a bit difficult to read if you change theme. Personally I don't think this is a big deal - I doubt users will be changing their theme that often - but it's worth nothing.

Any thoughts on either the implementation or the dark mode styling are welcome!

[astrofrog]

Looking good so far! On my system (Mac with Qt 6.4) I can't read the text on combo boxes and tabs when they are not selected:

The main application toolbar also doesn't look quite right and the text is hard/impossible to read:

I had to also explicitly change the viewers so that they are white on black instead of black on white - is that normal? Should we perhaps change that automatically when selecting dark? Maybe one of the options for the viewer colors should be 'theme default' which then just matches light or dark as needed.

[Carifio24]

@astrofrog Thanks for pointing that out! I don't see the same issues on Ubuntu so I hadn't noticed. I'll try and reproduce on my Mac.

The viewer theme should change to WoB if the app theme is set to Dark and the user had been using BoW (and vice versa) - I'll check if there's a bug there. I like the idea about adding an option to keep the viewer theme in sync with the application theme, will add that in.

[astrofrog]

I wonder if there are existing packages such as https://pyqtdarktheme.readthedocs.io that could help if it gets too tricky to get to work on all platforms?

[Carifio24]

@astrofrog so it looks like these issues come from the part of the application that are drawn directly by the system window manager. On MacOS, if I have the general appearance set to Light, I see the issues that you pointed out:

But with the system appearance set to Dark:

I'll look into what we can do about that. I'll look at pyqtdarktheme as well - their docs mention the ability to sync with the OS theming, so maybe they have a way to handle these sort of issues.

[Carifio24]

@astrofrog I made a very basic setup with pyqtdarktheme here - it works quite well, but the flat theme they use is (at least to my eyes) a pretty stark difference from how glue currently looks.

From looking at how they've done things, I think what's needed to fix these issues is to modify the application stylesheet as well.

[astrofrog]

As noted in #2430, I will be splitting out Qt-related code into a separate repository - however that repository will have the same history as the present one here so it should be easy to move over the pull request to that repository (I can help if needed). Sorry for the disruption!

[astrofrog]

@Carifio24 - I'm going to close this since it isn't possible to automatically transfer PRs to different repos, but feel free to re-open on the glue-qt repo, as it would be great to have that there!

[Carifio24]

@astrofrog Sounds good, I'll move this over (and try to get back around to finishing this up).