Combine multiple exports/projects

1

Hi there,

we are developing multiple LVGL based applications on a hardware and want to partly reuse screens. We already created a C++ layer with a custom screen management.
For example we have a device settings screen, that is similar to all applications, that has been created in a sperate LVGL project.

When trying to compile projects with separately exported screens, we end up having difficutlies with multiple definitions of helper functions (ui_helpers.c and ui.c).

I realize that the combination of different exported projects might be “unusual”, but did someone have similar intention and found a viable approach?
Or is it inteded to add support to SquareLine studio for a more generic or partial exports?

1 Like
2

Meanwhile I tested around with using components, but that also doesn’t seem to be an adequate solution and components are still depend on the underlaying generated ui code (-> ui.c)

3

How do you mean it? Do you modify the exported code?

4

I was hoping, that components help to encapsulate reusable screens. But the dependency to have multiple ui.c and ui_helper.c files still remains.

Do you modify the exported code?
No. I mainly reuse the created lv_objects in my C++ classes.

Let me try to explain a little more clearer what we try to achieve. We have mainly two general requirements we want to fulfill:

  1. Encapsulate generated UI-Code into C++ architecture. Our main application and the application logic is being programmed in C++. We therefore wanted to encapsulated every screen into an according C++ object. As most of the screen switched logic needs to be implemented manually anyways (e.g. when using a keypad for navigation), we created a screen manager C++ layer that manages lifetime and states of all available screens.
  2. Reusable UI-Screens. A lot of screens are similar in different applications. We want to reuse them. We therefore have cases, where an applications is based on screen that are created/generate by individual SquareLine projects.

Generally the approach is working as intended. Only the ui.c and ui_helper.c generate conflicts when trying to combine several square line exports into one application.

Maybe there is something generally wrong with our approach, but we very soon identified that the logic for switching screens can not be completely applied in Squareline directly. Therefore having a dedicated “screen manager” still makes sense.

5

Thank you for the explanation. However I still don’t understand what the problem is with creating a “screen component” for similar screens and creating instances for each screen in one project.

6

Hi,

sorry, I understand that my explanation is still incomprehensible.

Simply spoken we have the use case where we want to combine the export of separate SquareLine projects into one C/C++ Project on source code level. This is causing difficulties as every Squareline Studio export comes with separate initialization modules (ui.c and ui_helper.c).

I realize that this is probably not the intended use of Squareline Studio. Therefore to me the best solution is to use the generated code for SquareLine as a basis, but manually migrate it into own, custom modules.

7

Okay, to manage it effectively, I think we needed to add 2 things:

  • not exporting the helper files
  • add prefix to the files and function, e.g. ui_proj1_init(), ui_proj2_init()

Would it wslve your issue?

8

Yes, that would be beneficial for my use case. But what about the helper functions?
Is this module always identical?