-
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
Make light & dark visuals customizable when following the system theme #4744
Conversation
f8efb7b
to
6699144
Compare
6699144
to
d1c256d
Compare
d1c256d
to
8809473
Compare
Co-authored-by: Emil Ernerfeldt <[email protected]>
crates/egui/src/context.rs
Outdated
} | ||
|
||
/// The [`Style`] used by all subsequent windows, panels etc. | ||
pub fn style(&self, theme: Theme) -> Arc<Style> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted elsewhere, the active_style
produces a big diff (=a lot of breaking changes). I suggest we instead call this style_of
. I suspect this will be less used anyway, so keeping the often used function name shorter makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have additionally added back set_style
(which sets the currently active style). Should I also add back set_visuals
now that we have the _of
suffix?
All ready for re-review :) |
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]>
My opinion is, it would be better to keep `Context::set_visuals()` so that you don't get confused. * Related emilk#4744
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:
I decided to add a
ThemePreference
enum and track the current system theme separately.This has a couple of benefits:
ThemePreference
and not two values.theme_preference
is fine (as opposed to persisting thetheme
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 onThemePreference
, notTheme
.To showcase the new capabilities I added a new example that uses different "accent" colors in dark and light mode: