New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macOS: add support for the new Dark mode #1973
Comments
Nothing has been done in OpenCOR about macOS Mojave's new "Dark" theme, but I agree that we ought to support it, so tentatively putting it in for 0.7. |
…ite by default (opencor#1973)." This reverts commit 205803d.
…1973). The idea is so that we can use Objective-C in our TabBarWidgetMacStyle class.
So, that we can style it accordingly in Dark mode.
…ted tabs in Dark mode (opencor#1973).
By default, it’s blue while now we use the same colour as any normal text, which is fine since a link is underlined. To have blue on a light background is relatively ok, but not on a dark background. A lighter blue is not great either, hence we use the same colour of normal text and rely on a link being underlined…
…ormation and model type (opencor#1973).
Indeed, if we were to use `windowTextColor()`, we used to have #ffffff, i.e. white, but it should actually #d8ffffff, i.e. a slightly transparent white.
Indeed, in that commit, QPalette::color() was always returning a value of #d8 for the alpha channel. Yet, it really ought to be #ff. So, not quite sure (yet) what's going on here, but there is no reason for our styling to always use an ARGB value for colours.
Having spent more time than I will ever want to admit on trying to get OpenCOR to look nice in Dark Mode, I have to admit "defeat". Qt is just not ready for Dark Mode despite QTBUG-68891. So, we are just going to enforce the use of Light Mode for now. Not something that I am happy about (not least because of all the time I wasted on this!), but too many other things to do, so... |
Sorry Alan, enforcing light mode is fine! Thanks!! |
No, it's me. I should have given up long ago. I just thought that I could fix all the tiny problems I came across, but some of my fixes had side-effects, etc. due, I believe, to Qt not being ready for Dark Mode. Anyway, the |
When we first looked at this issue, we were using Qt 5.12.1. Right now, OpenCOR uses Qt 5.12.11 (definitely not the latest version of Qt, but this is unfortunately the last real LTS version) and it looks like dark mode support is quite good. So, we might be able to get it done this time. |
2021/07/01: it looks like dark mode (both on Windows and macOS) works better with Qt 5.12.x LTS (see here).
The current LTS version of Qt (5.12.1) doesn't fully support macOS's Dark mode (e.g. see https://bugreports.qt.io/browse/QTBUG-73788 and https://bugreports.qt.io/browse/QTBUG-73852). Yet, there are things that we can still to improve things (note: some of those things were observed when starting OpenCOR in Light/Dark mode and then switching to Dark/Light mode and back):
QLabel
objects ("dark" blue on a dark background doesn't look great; check theAbout OpenCOR
dialog for instance)Core::TabBarWidget
behave properly in Dark mode (see the file/mode/view tabs in the central area)Core::SplitterWidget
use the right backgroundCore::CollapsibleWidget
use the background (right now: white on grey background...!)GraphPanelWidget::GraphPanelWidget
always use a light surrounding background by default (since everything can be customised by the user)Help
window:PMR
window:Change the colour of the PMR instance information (dark grey on dark background is not great)(This is actually the way it should look)PMR Workspaces
window:Change the colour of the PMR instance information (dark grey on dark background is not great)(This is actually the way it should look)diff
dialogCellML Annotation
view:Simulation Experiment
view:Note: Qt's current support of macOS's Dark mode is rather limited. For example, one would expect
QEvent::PaletteChange
to be triggered every time we switch from Light to Dark mode (and vice versa), but it’s not the case. In other words, the best we can do is to get OpenCOR to look "ok" in Dark mode. However, to switch to Light mode while OpenCOR is running will result in the UI being completely messed up, but there is nothing we can do about it at this stage. (The same applies when starting in Light mode and then switching to Dark mode.) We therefore need to wait for Qt to "properly" handle macOS's Dark mode. RegardingQEvent::PaletteChange
, we still handle it since this is what should be done if Qt was to properly support macOS's Dark mode.---[ BELOW IS THE ORIGINAL MESSAGE FROM @mirams ]---
I have MacOS Mojave 'Dark Mode' switched on which is nice, but the Editing window looks like this (in snapshot 2019-02-01):
The text was updated successfully, but these errors were encountered: