-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
CSS-like styling #3284
Comments
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. Original comment@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:
|
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 Next up would be to implement the Next up is designing and implementing a hierarchical "class" system and add that as part of 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 #3284 |
This can be a very large and difficult task that takes a long time. It should be possible to use the egui library without using a |
* Closes #4534 This PR: - Introduces `Ui::stack()`, which returns the `UiStack` structure providing information on the current `Ui` hierarchy. - **BREAKING**: `Ui::new()` now takes a `UiStackInfo` argument, which is used to populate some of this `Ui`'s `UiStack`'s fields. - **BREAKING**: `Ui::child_ui()` and `Ui::child_ui_with_id_source()` now take an `Option<UiStackInfo>` argument, which is used to populate some of the children `Ui`'s `UiStack`'s fields. - New `Area::kind()` builder function, to set the `UiStackKind` value of the `Area`'s `Ui`. - Adds a (minimalistic) demo to egui demo (in the "Misc Demos" window). - Adds a more thorough `test_ui_stack` test/playground demo. TODO: - [x] benchmarks - [x] add example to demo Future work: - Add `UiStackKind` and related support for more container (e.g. `CollapsingHeader`, etc.) - Add a tag/property system that would allow adding arbitrary data to a stack node. This data could then be queried by nested `Ui`s. Probably needed for #3284. - Add support to track columnar layouts. --------- Co-authored-by: Emil Ernerfeldt <[email protected]>
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
Border
#4019WidgetStyle
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 #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?
The text was updated successfully, but these errors were encountered: