-
Notifications
You must be signed in to change notification settings - Fork 576
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
Proposal: Styling capabilities for the std-widgets #5392
Comments
One point I have missed. Base widget and std-widgets styling are not mutually exclusive and could be implemented both. So maybe it is just a question do we want both and if yes with what we should start first. |
Could you provide an example of how the ButtonBase API looks like, roughly? |
Principle it would be the same api as std button without predefined styling and with a style or multiple style properties. |
Ahh, right, so either way we have to first answer the question how to declare the style able properties: As struct, as individual properties, or using a third method (to be determined), right? |
Yes that's right. First we need to define how the styling should looks like multiple properties vs. styling properties. I have a favorite ;-). And then I think first step could be to implement it for the std-widgets. And after that we could also think about to provide unstyled std-widgets. |
I agree that we need ButtonBase, SpinBoxBase and the like, that contains the "interface" and the logic. I think changing some base properties like font and palette on all style seems like a good idea as well. (See also #116 (comment) ) We could also think of a smarter |
One additional advantage of style stucts is that it is also easier to style inner elements like items of a the export MyListView inherits StandardListView {
style: {
item-style: {
background: black;
}
}
} |
That's also a good idea. Maybe this could be a second step. Maybe for more inspiration. I'm currently doing a refactoring on my
|
I am in favor of having "interface widgets" like ButtonBase in a On note from my side: When I worked on Qt projects, we often distinguished between "Styling" and "Theming" |
Thank you for your feedback. Yes I think to to have the base stuff to give a blueprint of the api of each widget and also the base component / layout setup. So it can easily used if someone create a widget set based on a custom design.
Yes that's true we should be careful in the naming. So actual in my proposal a |
This sounds awesome! Is this something that might be coming out in one of the next updates? |
@Areopagitics it will not be part of the next release and it is not scheduled yet. But I think it should not be to hard to implement that, just effort. I think it would make sense to do this step by step. So to start for example with the button, then CheckBox, ... . So also if it is not done for all widgets for the next but one release, we can release it what is already done and put the rest in the next release. But before starting this, I think it's most important that we are sure about, Should be there also base widgets and how exactly the api should looks like. So I think we will need a meeting about it before @tronical @ogoffart ;-). And I really like to take care of that topic :-) |
While it is already possible to do custom styling with Slint by doing custom widget development like [SurrealismUI] (https://github.com/Surrealism-All/SurrealismUI) and coop a highly requested features is to do change style settings on the Slint's
std-widgets
likebackground
,border-color
andfont-size
. The profit for developers is that they have something to start with and they don't need to start from scratch. Connected to this features I see some question that we should also keep in mind to help developers by doing custom styling base on the std widgets:fluent
What I have in mind to solve this questions it to provide design / styling guidelines and best practices. I think this could follow as seconds step after custom styling is done.
Before going in to details of this proposal I want to say about the possibility to create custom widgets that matches e.g. the colors settings of one of the provides Slint styles like
fluent
ormaterial
. There is already a global with that settings called Palette there will be soon a more complex example that displays how to work with it calledTodoMVC
, more details soon ;-).I see there two different ways to implement this feature:
Base widgets
First one is to provide the developers a set of all std widgets as base with no predefined styling. Benefit of this is, the developer / designer is completely free, could do easily a complete custom design for the std widgets without the need to start from scratch. So it would be possible to use base widgets with predefined layout, content and behavior. Disadvantage of this is that for support all std-widget it is necessary to do styling for all std widgets:
Example
Add styling to the current std-widget
Other approach is to add styling properties to the current std-widgets. Profit is the developer / designer don't need to start from scratch and don't need to do styling for all widgets. Disadvantage is if it should work with all styles it needs to ensured that colors e.g. that are set works with all styles. It is harder to ensure consistency with the style.
For styling in common we should keep in mind that wee need to provide this also for the different states of a widget. E.g. it's not enough to just change the background. Depending on the style there are different
background
brushes depending on the state e.g. abackground-hover
and abackground-pressed
.I see there two way to add styling properties to the widgets:
Add properties directly to the widgets
I see there one disadvantage this will bloat the api of a widget a lot with properties.
Add a style property to each widget (style as struct)
Disadvantage right now is that it is not possible to overwrite single field of a struct. So all field that are not set will be set to default values check #5201. Profit is it give the style a clean structure. There is one extra property per widget. Styles can be also stored in a global.
I hope that gives people that are requesting styling features for std widgets some answers and a way how we can solve this. So I'm open for feedback and I hope that is something we can put on the agenda for the near future.
The text was updated successfully, but these errors were encountered: