Create styles and custom themes

Feature requests
1

What do you want to achieve?

actually in code generated the styles that are local styles that cool but in case of many objects that has the same style it’s a lot of code created and more work to make same styles in all objects.

it would be cool if we could as a second option to create styles separatly and assign directly to object. it will make work more easier smaller code and maybe it would help to create custom themes if we want change themes in application.

2

We were talking a lot about it and concluded that with components you can create quite the same thing. E.g. you create a “title”, a “subtitle”, “smalltext” components for the typography, or “button_normal”, “button_error” for buttons and save the styles in the components.

What do you think about it?

1 Like
3

yes it’s reasonable to use components, I didn’t think that way about components, for me components were a group of widgets to create a new widget, but as you said we can style objects with components,
so if we need to change a style button for example we need to create a component and use it as a button widget.

the advantage of SLS is to control styles that’s the main usage of WYSIWYG applications, i’m not complaining about using local styles, i like it, and as you said we can use components, i’m totally okay with that,
i was just wondering in case of applications proposing 2 or 3 themes to user, as it is right now i think we should replace all objects with new ones instead of changing just the style, What do you think about it ?

creating styles in code is not pleasant, but as a solution we can export code as a local style and use it to create custom styles in need.

4

It’s really not solved now. In a project I needed to add a light/dark theme switch to a UI and I needed all my LVLG and SLS knowledge to code it into an SLS exported code. It was still hacky…

While i was working on it I got an idea about how to make it simpler. Now components are using local styles but we could make the use normal styles. E.g. “button_error” could have ui_red_button_style_default, ui_red_button_style_pressed, etc.

This way to switch theme, all you need to do is changing these global styles.

It’s not the super flexible and super optimal, but it’s easy to understand and easy to add.

What do you think about it?

5

Yes I see, The issue is which one to use for the user, i assume that local styles are more optimal and flexible in case we use just one theme in all ui application, but in case of using multiple themes it makes local styles unused and the use of global styles inevitable i think,

the challenge for you here is to offer to user (of SLS) choosing between local styles and normal styles in generated code.

I don’t know if it’s possible to add local styles in other functions and assign in every function the local styles desired, and refresh screen, e.g something like bellow :

//function called in a callback 
void set_theme(char themee)
{
    if(themee == 1)theme1();
    if(themee == 2)theme1();
    .... 
   refresh 
}
//add local styles to all objects for theme1
void theme1(void )
{
    lv_obj_set_style_bg_color(ui_object1, lv_color_hex(0xD3D3D3), LV_PART_MAIN | LV_STATE_DEFAULT);
    lv_obj_set_style_bg_opa(ui_Object1, 255, LV_PART_MAIN | LV_STATE_DEFAULT);
.
.
.
    lv_obj_set_style_bg_color(ui_object20, lv_color_hex(0xD3D3D3), LV_PART_MAIN | LV_STATE_DEFAULT);

}
...

what do you think about it ?

6

Actually for components non-local styles are always better, as we need to allocate the style properties e.g. the for the pressed state only once and use only its pointer in the components, instead of saving the same style properties in the components locally.

So we should add global styles in the future.

3 Likes
7

Hi,

I second that. We do need separation of styles definition, and style bonding to objects.
Today, I have no choice but apply styles with code on a second pass, which is cumbersome and does not allow me to see the result (WYSIWYG) in the editor.
Another example: I want all my buttons to look the same (theme) but they’re not a common component. Styling is appearance, components if functionality/feature .

Handling styles directly from the editor seems to be the only and best option in my opinion.

8

I see, and your are right. I’ll discuss how can we improve it.

FYI, we are already working on SquareLine Studio v2 and we also presented it on Espressif DevCon2023 yesterday. (I will share the video once it’s available) In SLS v2 you will be able to deal with styles as you do in LVGL. We plan to release it in 2024 Q1, so it doesn’t solve your current issue, but it might be good to know. BTW, we will provide a tool to import SLS v1 projects to v2.

1 Like
9

Exciting to hear styles will handled in SLS v2!

This was an original feature requested since you first announced the project (might have been in the EdgeLine era).

Styles are excellent in LVGL (when writing code), so having them in SLS will be nice.
Right now, the lack of being able to create a style, give it a name, and apply it to objects means there is always some parts of our pages that can’t be done in SLS and only will be rendered in code.

1 Like