Make light & dark visuals customizable when following the system theme #4744
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bash
force-pushed
the
custom-dark-light
branch
5 times, most recently
from
f8efb7b to
6699144
Compare
bash
force-pushed
the
custom-dark-light
branch
from
6699144 to
d1c256d
Compare
emilk
reviewed
Aug 26, 2024
bash
force-pushed
the
custom-dark-light
branch
from
d1c256d to
8809473
Compare
Co-authored-by: Emil Ernerfeldt <[email protected]>
emilk
reviewed
Sep 4, 2024
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.
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.
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
approved these changes
Sep 10, 2024
This was referenced Sep 12, 2024
emilk
changed the title
emilk
changed the title
emilk
pushed a commit
that referenced
this pull request
Sep 26, 2024
hacknus
pushed a commit
to hacknus/egui
that referenced
this pull request
Oct 30, 2024
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]>
hacknus
pushed a commit
to hacknus/egui
that referenced
this pull request
Oct 30, 2024
My opinion is, it would be better to keep `Context::set_visuals()` so that you don't get confused. * Related emilk#4744
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Unfortunately, this PR contains a bunch of breaking changes because
Contextno 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_mutmutates 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
ThemePreferenceenum and track the current system theme separately.This has a couple of benefits:
ThemePreferenceand not two values.theme_preferenceis fine (as opposed to persisting thethemefield which may actually be the system theme).The
small_toggle_buttoncurrently 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: