-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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 styling #146
Custom styling #146
Conversation
@piaoger Keep in mind that this is not a built-in theme or anything. All the styling is defined in this particular example. It was meant to showcase how you can basically change style completely. In any case, I agree they are not very clear. It should be fixed now! I've also updated the GIF. Let me know :) |
HAHA 👍 |
This is awesome. Will this allow theoretically in the future to have something resembling the CSS |
@JakubKoralewski The CSS |
I don't want to go too off-topic here, but my OCD does... not.. allow...
According to w3 most of the time the transform property does not affect layout:
It just rotates, skews, translates etc. without taking layout into account at all. With this knowledge now, would that be possible 😄 ? |
@JakubKoralewski It does affect the layout (position and boundaries) of the element you are transforming and its contents. As a consequence, there are other systems besides rendering that need to be aware of this transformation. Custom styling is currently just a way to configure rendering on a per widget basis. |
Fixes #112, closes #102, and closes #93.
This PR implements basic custom styling support for
Container
,TextInput
,Button
,Scrollable
,Slider
,ProgressBar
,Radio
, andCheckbox
.Renderer-agnostic styles
Custom styling is opt-in. Widgets will use a default style unless a custom style is explicitly set using the new
style
methods.The
Style
of each widget is defined by the renderer implementation as an associated type.This makes styling renderer-agnostic. For instance, a sprite-based renderer could decide to simply not support background colors or borders and use enums instead.
A new subcrate:
iced_style
The style attributes that are supported by
iced_wgpu
(and in the near futureiced_web
) have been gathered in a new subcrate:iced_style
.For now, the custom styling in
iced
takes a dynamic approach. AStyleSheet
trait exists for every widget and it defines theStyle
of the widget in different states. This trait can be implemented by users and then provided to thestyle
method of a particular widget. Many of the examples now showcase this approach.It is important to note that, in
iced
, anything that can affect layout is not considered "style" . For instance, specifying a font or text size is not considered styling. This means that your whole layout will stay consistent independently of your style sheets!In any case, this is just meant to lay the foundations for custom styling! We will definitely need to extend each widget style attributes and maybe change strategies as we learn about more use cases.
Relevant changes
A
Defaults
type has been added toiced_wgpu
. This type is meant to be leveraged to allow for style inheritance. For instance, aContainer
can set some text color and all theText
inside will be affected unless theText
itself defines a color of its own.Moreover, the
Quad
primitive iniced_wgpu
now supports aborder_width
andborder_color
. Also, a bug has been fixed where color was incorrectly blended when theborder_radius
was0
.Finally, a
styling
example has been added. It showcases a simple way to use different themes in the same GUI by creating astyle
module and aTheme
enum. It would be great to extend this example with more themes. It may also be interesting to offer some built-in themes iniced_style
at some point.Pending work
deny(missing_docs)