-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Custom light & dark themes on system theme change #4490
Comments
100% agree with this. The global style is stored in struct Options {
pub dark_mode_style: Arc<Style>,
pub light_mode_style: Arc<Style>,
pub theme: Theme, // Dark or Light
pub follow_system_theme: bool, // Change [`Self::theme`] based on `RawInput::system_theme`?
…
} with Then move PRs welcome! |
Please also refer to issue #4312 while working. |
* Some initial progress towards #4490 This PR just moves `Theme` and the "follow system theme" settings to egui and adds `RawInput.system_theme`. A follow-up PR can then introduce the two separate `dark_mode_style` and `light_mode_style` fields on `Options`. <!-- Please read the "Making a PR" section of [`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md) before opening a Pull Request! * If applicable, add a screenshot or gif. * If it is a non-trivial addition, consider adding a demo for it to `egui_demo_lib`, or a new example. * Do NOT open PR:s from your `master` branch, as that makes it hard for maintainers to test and add commits to your PR. * Remember to run `cargo fmt` and `cargo clippy`. * Open the PR as a draft until you have self-reviewed it and run `./scripts/check.sh`. * When you have addressed a PR comment, mark it as resolved. Please be patient! I will review your PR, but my time is limited! --> * [x] I have followed the instructions in the PR template ### Breaking changes The options `follow_system_theme` and `default_theme` has been moved from `eframe` into `egui::Options`, settable with `ctx.options_mut` --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
@rustbasic Do you have an minimal example that I can run to verify that visuals_mut works as expected for you? |
If you call If you do it like the example, once the settings are set, it will be initialized when you change the theme. Since the recent update, even the settings are initialized once. Since
|
If I'm not mistaken, If you want a change to the visuals to be permanent you have two options:
Currently, if you have eframe configured to follow the system theme (on by default) it will override the visuals when the system theme changes and you lose your changes to the visuals. This will be fixed as soon as #4744 lands. |
Yes, I think there are some ambiguous parts because I made the example in a hurry.
What I want is that I want the Dark and Light modes to not be reset to the default value when I change them. Thank you. |
@rustbasic Yes, this should indeed be fixed by #4744. |
#4744) * Closes <#4490> * [x] I have followed the instructions in the PR template --- Unfortunately, this PR contains a bunch of breaking changes because `Context` no longer has one style, but two. I could try to add some of the methods back if that's desired. The most subtle change is probably that `style_mut` mutates both the dark and the light style (which from the usage in egui itself felt like the right choice but might be surprising to users). I decided to deviate a bit from the data structure suggested in the linked issue. Instead of this: ```rust pub theme: Theme, // Dark or Light pub follow_system_theme: bool, // Change [`Self::theme`] based on `RawInput::system_theme`? ``` I decided to add a `ThemePreference` enum and track the current system theme separately. This has a couple of benefits: * The user's theme choice is not magically overwritten on the next frame. * A widget for changing the theme preference only needs to know the `ThemePreference` and not two values. * Persisting the `theme_preference` is fine (as opposed to persisting the `theme` field which may actually be the system theme). The `small_toggle_button` currently only toggles between dark and light (so you can never get back to following the system). I think it's easy to improve on this in a follow-up PR :) I made the function `pub(crate)` for now because it should eventually be a method on `ThemePreference`, not `Theme`. To showcase the new capabilities I added a new example that uses different "accent" colors in dark and light mode: <img src="https://github.com/user-attachments/assets/0bf728c6-2720-47b0-a908-18bd250d15a6" width="250" alt="A screenshot of egui's widget gallery demo in dark mode using a purple accent color instead of the default blue accent"> <img src="https://github.com/user-attachments/assets/e816b380-3e59-4f11-b841-8c20285988d6" width="250" alt="A screenshot of egui's widget gallery demo in light mode using a green accent color instead of the default blue accent"> --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
* Some initial progress towards emilk#4490 This PR just moves `Theme` and the "follow system theme" settings to egui and adds `RawInput.system_theme`. A follow-up PR can then introduce the two separate `dark_mode_style` and `light_mode_style` fields on `Options`. <!-- Please read the "Making a PR" section of [`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md) before opening a Pull Request! * If applicable, add a screenshot or gif. * If it is a non-trivial addition, consider adding a demo for it to `egui_demo_lib`, or a new example. * Do NOT open PR:s from your `master` branch, as that makes it hard for maintainers to test and add commits to your PR. * Remember to run `cargo fmt` and `cargo clippy`. * Open the PR as a draft until you have self-reviewed it and run `./scripts/check.sh`. * When you have addressed a PR comment, mark it as resolved. Please be patient! I will review your PR, but my time is limited! --> * [x] I have followed the instructions in the PR template ### Breaking changes The options `follow_system_theme` and `default_theme` has been moved from `eframe` into `egui::Options`, settable with `ctx.options_mut` --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
* Some initial progress towards emilk#4490 This PR just moves `Theme` and the "follow system theme" settings to egui and adds `RawInput.system_theme`. A follow-up PR can then introduce the two separate `dark_mode_style` and `light_mode_style` fields on `Options`. <!-- Please read the "Making a PR" section of [`CONTRIBUTING.md`](https://github.com/emilk/egui/blob/master/CONTRIBUTING.md) before opening a Pull Request! * If applicable, add a screenshot or gif. * If it is a non-trivial addition, consider adding a demo for it to `egui_demo_lib`, or a new example. * Do NOT open PR:s from your `master` branch, as that makes it hard for maintainers to test and add commits to your PR. * Remember to run `cargo fmt` and `cargo clippy`. * Open the PR as a draft until you have self-reviewed it and run `./scripts/check.sh`. * When you have addressed a PR comment, mark it as resolved. Please be patient! I will review your PR, but my time is limited! --> * [x] I have followed the instructions in the PR template ### Breaking changes The options `follow_system_theme` and `default_theme` has been moved from `eframe` into `egui::Options`, settable with `ctx.options_mut` --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
emilk#4744) * Closes <emilk#4490> * [x] I have followed the instructions in the PR template --- Unfortunately, this PR contains a bunch of breaking changes because `Context` no longer has one style, but two. I could try to add some of the methods back if that's desired. The most subtle change is probably that `style_mut` mutates both the dark and the light style (which from the usage in egui itself felt like the right choice but might be surprising to users). I decided to deviate a bit from the data structure suggested in the linked issue. Instead of this: ```rust pub theme: Theme, // Dark or Light pub follow_system_theme: bool, // Change [`Self::theme`] based on `RawInput::system_theme`? ``` I decided to add a `ThemePreference` enum and track the current system theme separately. This has a couple of benefits: * The user's theme choice is not magically overwritten on the next frame. * A widget for changing the theme preference only needs to know the `ThemePreference` and not two values. * Persisting the `theme_preference` is fine (as opposed to persisting the `theme` field which may actually be the system theme). The `small_toggle_button` currently only toggles between dark and light (so you can never get back to following the system). I think it's easy to improve on this in a follow-up PR :) I made the function `pub(crate)` for now because it should eventually be a method on `ThemePreference`, not `Theme`. To showcase the new capabilities I added a new example that uses different "accent" colors in dark and light mode: <img src="https://github.com/user-attachments/assets/0bf728c6-2720-47b0-a908-18bd250d15a6" width="250" alt="A screenshot of egui's widget gallery demo in dark mode using a purple accent color instead of the default blue accent"> <img src="https://github.com/user-attachments/assets/e816b380-3e59-4f11-b841-8c20285988d6" width="250" alt="A screenshot of egui's widget gallery demo in light mode using a green accent color instead of the default blue accent"> --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
Is your feature request related to a problem? Please describe.
Currently, when the system theme changes, the
Visuals
theme is switched to the hard-codedegui::Visuals::dark()
oregui::Visuals::light()
. I would like for there to be an option to use customVisuals
for dark and light themes.This seems to be where the system theme change is detected and the egui visuals are set:
egui/crates/eframe/src/native/epi_integration.rs
Line 271 in c3f386a
And this seems to be where the hard-coded
Visuals
are set:egui/crates/eframe/src/epi.rs
Lines 501 to 506 in c3f386a
Describe the solution you'd like
There should be some way to pass a
Visuals
that corresponds to the dark theme, and anotherVisuals
which corresponds to the light theme. Then, when a theme change is needed, those custom themes would be used instead of the hard-codedegui::Visuals::dark()
oregui::Visuals::light()
.Describe alternatives you've considered
None
Additional context
I am working on https://github.com/damus-io/notedeck and we would like to support custom theming at some point. It's not a high priority at the moment, and I would be open to submitting a PR for this feature in the future.
The text was updated successfully, but these errors were encountered: