Option to not keep all screens alive continuously

Feature requests
1

What do you want to achieve?

I would like to be able to develop an application using Squareline Studio that does not keep all screens alive continously.

Do you see alternative options and workaround to achieve it?

My current work-around is using Squareline studio to facilitate rapid UI development of screens visually, but only use the “call function” events as opposed to “change screen” or otherwise. Then in these functions I make sure to clean up any inactive screens following the transition.

Additionally, I do not use the ui_init() function that is default exported from Squareline studio as this will create and allocate memory for all screens on startup… I have to write a custom ui_init() function instead.

Mention some use cases

I have 10+ screens, and not enough memory for all of them to be implemented at the same time. This is probably quite common in low-resource systems. It was a shock to me that squareline studio was implemented in this way as it will eat up so much memory. Please note I have read:
Multiple screens / Unique object names - #2 by kisvegabor where the reason for this is explained. It does make sense but I think for a paid product there should be an option where the developer can have full control of this from within squareline studio. Hopefully in the future!

Thanks, big fan of LVGL!

2

Hi,

Thanks for bringing it up. It show that this really would be important for our users. I will discuss with our developers how could we implement it in a simple and elegant way.

The main issue I see with it is the actions can’t affect widgets on different screens. E.g it’s not possible to set the text of a label on button press if the label is on an other screen. So we should filter the possible target widgets to the screen of the source widget. I think it won’t be a problem in most of the cases though.

3

Thanks for the quick response @kisvegabor, and thanks for the great products.

4

I submitted this similar ticket. I have the same problem and my app is crashing because of this.

[Large Memory Footprint - Bugs - Forum - SquareLine Studio]
(Large Memory Footprint - #4 by kisvegabor)

5

We are already discussing it!

1 Like
6

@jmhatt jmhatt would you be willing to share what your ui_init() function looks like?

7

@CodeGrue essentially all I’ve changed from the ui_init() is I’ve removed the initialization of the other screens.

For example lets say when you export your Squareline studio project the ui_init looks like this:

void ui_init(void)
{
    LV_EVENT_GET_COMP_CHILD = lv_event_register_id();

    lv_disp_t * dispp = lv_disp_get_default();
    lv_theme_t * theme = lv_theme_default_init(dispp, lv_palette_main(LV_PALETTE_BLUE), lv_palette_main(LV_PALETTE_RED),
                                               true, LV_FONT_DEFAULT);
    lv_disp_set_theme(dispp, theme);
    ui_HomeScreen_screen_init();
    ui_SetupScreen_screen_init();
    ui_StatusScreen_screen_init();
    ui____initial_actions0 = lv_obj_create(NULL);
    lv_disp_load_scr(ui_HomeScreen);
}

Then my custom init would look like this as I only want the home screen to be drawn on startup.

void ui_custom_init(void)
{
    LV_EVENT_GET_COMP_CHILD = lv_event_register_id();

    lv_disp_t * dispp = lv_disp_get_default();
    lv_theme_t * theme = lv_theme_default_init(dispp, lv_palette_main(LV_PALETTE_BLUE), lv_palette_main(LV_PALETTE_RED),
                                               true, LV_FONT_DEFAULT);
    lv_disp_set_theme(dispp, theme);
    ui_HomeScreen_screen_init();
    ui____initial_actions0 = lv_obj_create(NULL);
    lv_disp_load_scr(ui_HomeScreen);
}

Then rather than using the Squareline studio events to change screens, just set “call function” events for any buttons that cause a screen change. In the function for this, you can call the initialization function for the other screens that you are navigating to, that were exported by SLS. You can then delete the old screen as well. This way your memory usage is much much lower.

This is just one method of doing it.

I’ve sinced moved away from even this, as my UI contains the same header, footer, and navigation bar for all screens. I’ve found it easier to just use one screen, and only dynamically re-draw anything in the main body of the UI that needs to be drawn, as well as dynamically update the navbar, footer, header.

I still use SLS to quickly create the UI components that will sit in the body of my UI ( on separate screens), but I don’t actually render or delete screens, I only use the code generated and copy it into my own code. If you’ve ever used QT or GTK tools like QtCreator before, this will feel familiar.

8

Thank you for posting this. I am going to give this a try until SL has this built in (or equivalent), When you delete the screen on exit, does that delete all the components from memory?

9

@kisvegabor in the example provided by @jmhatt above, the “_init()” methods are not listred in ui.h so you can’t call them from the ui_events.cpp file. So this workaround isn’t functional unless I modify the ui.h header file and that gets overwritten by squareline studio.

Please keep us posted if your team decides to implement this functionality directly somehow. Thanks!

1 Like
10

It does yes.

11

You can define the init method prototypes in any header file, it does not need to be in ui.h because as you said this gets overwritten. Put the prototypes in a custom header file written by you.

1 Like
12

I didn’t want to create a new topic, sorry if this thread is too old to reply too. I’ve also got this same challenge in managing a large number of screens.

For many use-cases, screens could be managed with datastructures in combination of a screen-stack and screen loop.

By a screen stack, if we start with a main menu screen, pushing a button pushes a screen on stack, closing screen pops from screen stack.

By a screen-loop, instead of a main-menu, a list of screens that can be cycled, then more screens pushed or popped from the currently selected screen.

We might need hooks for each time a screen is pushed and popped or transitioned through a loop, but calling them would be managed by the stack/loop operations. Dynamically creating and destroying screens does mean that we wouldn’t be able to set properties on widgets on pages that do not currently exist, and would have to defer until creation of target screen. Does this seem like a reasonable design?

13

‘Temporary screens’ that do what the topic-opener @jmhatt wants, were implemented in SquareLine Studio v1.3.1 in July 2023 ( Changelog | SquareLine Studio )

Thank you for sharing info about this methodology that could improve the feature even further.

1 Like