fix(ui): Make configuration dialogs respect in-app theme choice #15
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/themes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Configuration and Properties dialogs were determining their theme (light/dark) exclusively by checking the operating system's palette, which I attempted to fix yesterday but didn't fully check the UI Themes. This created a visual bug where if a user selected an explicit dark theme within the Citron UI (e.g., "Midnight Blue") while their OS was in light mode, the dialogs would incorrectly render with a light background, causing unreadable text and a broken appearance. This was essentially the reverse problem of the original testing I saw & did, and failed to swap between Dark in-Citron UI themes to test the Operating System clash, as already mentioned.
This commit refactors the theme detection logic to correctly prioritize the user's in-app selection.
The IsDarkMode() helper function has been updated to follow a clear hierarchy. It first checks if the currently selected theme in UISettings is one of the known dark themes. If it is, dark mode is enforced for the dialogs, regardless of the system theme.
If the selected theme is an adaptive one ("Default" or "Default Colorful"), the function falls back to the original behavior of querying the system palette. This ensures the "follow system" functionality remains intact.
The dialogs now also handle the QEvent::PaletteChange to dynamically update their appearance if the OS theme is changed while they are open, improving the user experience for adaptive themes.