Open emilk opened 12 months ago
Re: dark mode vs. light mode, I believe the heavy lifting is done by just swapping the corresponding Radix color tables. The "coordinates" (tint, index) can remain the same.
I am probably spewing a stupid idea here. but Dioxus is implementing CSS for native rendering. maybe it is worth seeing if you could either straight up use that, or bundle your dev power and make a generic lib that would work for both. I do realise this is very optimistic, probably even naive. But just wanted to have shared the thought
Ah my bad - I see they have experimental WGPU support now via their Blitz renderer.
@chris-kruining - as far as I can tell Dioxus isn't actually native, right? It's webview based : https://dioxuslabs.com/learn/0.4/getting_started/desktop#desktop-overview
Ooh my bad if I got that wrong, I seem to remember the dude in the video saying "building a browser is hard" when he talked about css. So I made the presumption that they were implementing there own rendering and not just a webview.
Love this idea!
Personally faced a lot of inconvenience when trying to style individual widgets in the past, so this would be amazing!
Is there any roadmap for this or is it still in idea phase?
This and RTL support are gonna be dream come true
I'm interested in writing a parser for the style language / rule engine / css clone thing. The following is a (hopefully) thought-out attempt to fill holes in the original proposal:
"Wow it's almost like a real RFC!"
Questions with recommendations have their recommendations (italicized). Unanswered questions are bolded.
`,
>,
+,
~`)class
?Ui
s and Widget
s with identifiers?id
to prevent confusion with Id
?I was going to start working on this right after finishing writing the proposal but now I'm worn out haha
The way I want to approach this is step-by-step:
First implement the new WidgetStyle
and use that for all widgets. That already is quite a bit of work, but is mostly refactoring.
At this point the WidgetStyle
would be selected by something hard-coded in the current struct Style
.
Next up would be to implement the WidgetStyle
selection it via a plugin system (ThemePlugin
). This would require also implementing the first portion of StyleModifiers
.
This would also be the point we add a cache in front of it to speed up repeated queries for slow plugins.
Next up is designing and implementing a hierarchical "class" system and add that as part of StyleModifiers
.
And last is the actual CSS language and engine, which can now be fully a separate crate, and opt-in.
That's understandable. I thought doing the CSS parser, being standalone, was better for me as I'm completely unfamiliar with the project internals.
Do you think it would be reasonable for me to attempt the refactor? Or should it be left up to someone more experienced?
Also, a clarification with the plugin system. Where/How would the plugins be registered? With the top level egui context or in the Widget impl?
An action plan has been added to https://github.com/emilk/egui/issues/3284
@emilk
This can be a very large and difficult task that takes a long time. CSS is a complex topic, and there are specialists who focus solely on CSS. It is also possible to implement only simple configurations. (Of course, this is the right approach at first.)
It should be possible to use the egui library without using a theme file
.
When using the egui library, users should not be forced to use a theme file
.
Some half-finished ideas around how to improve the styling and theming story for egui.
Background
Styling for egui is currently supplied by
egui::Style
which controls spacing, colors, etc for the whole of egui. There is no convenient way of changing the syling of a portion of the UI, except for changing out or modifying theStyle
temporarily, and then changing it back.We would like to have a system that can support CSS-like selectors, so that users can easily style their ui based on the Style Modifiers (see below):
It would be very beneficial if such styling could be set in a single text file and live-loaded.
Action plan
WidgetStyle
and use that for all widgets, with first iteration ofStyleModifiers
WidgetStyle
selection it via a plugin system (ThemePlugin
).ThemePlugin
StyleModifiers
Proposal
Style modifiers
Here are some things that could influence the style of a widget:
Ui
identifier (”settings_panel”)For instance, a user may want to change the sizes of all buttons within the
"settings_panel"
.The per-
Ui
identifier would need to be a hierarchial stack, so the query to a theme would be something like:We could also consider having dark/light mode as a modifier, allowing users to specify both variants in one theme file.
WidgetStyle
Let’s start with this:
If each widget as given a
WidgetStyle
it could then use it both for sizing (frame
margins and font size) and its visual styling. The current theme would select aWidgetStyle
based on some given style modifiers, and its interaction state (computed at the start of the frame, thanks to https://github.com/emilk/egui/issues/3936).WidgetStyle
would be used by all built-in widgets (button, checkbox, slider, …) but also eachWindow
andUi
.Example
Speed
We must make sure
egui
isn’t slowed down by this new theming. We should be able to aggressively cache theWidgetStyle
lookups based on a hash of the input modifiers.Theme plugins
We could start by having a plugin system for the theming, something like:
We could then start with a simple rule engine, but still allow users to implement much more advanced ones (e.g. more and more CSS-like).
Rule-engine
Eventually we want a fully customizable sytem where rules set in one theme file will control the look of the whole UI. Such a rule system has a few open questions to resolve:
Rules
The rules can apply partial settings or modifiers. For instance, a rule can set the font and increase the brightness of the text.
Exactly how to specify the rules (i.e. in what language) is outside the scope of this issue, but here is a few examples of the kind of rules one could maybe want to do:
Color palette
We also need a color palette, indexable by brightness and opacity
https://www.radix-ui.com/colors/docs/palette-composition/understanding-the-scale
In the GUI code users should be able to refer to colors both using aliases (”blue”, “header”, …) and hard-coded colors (
#ff0000
).Dark mode vs light mode
We should also consider supporting both light and dark mode within the same theme. That is, one theme file should be able to set both a dark and a light theme. Perhaps “dark” and “light” is just another style modifier?