I am looking for paid support to create a standard interface for loading different screens, created with SLS, from SD card by user selection. Each screen can have six different objects to visualize all the same data in possible screens, which so far only differ in the visual appearance. FMPOV “only” the objects name must be submitted to the main application, which can be achieved by a corresponding XML file, which describes the data objects. One or two screen related SLS generated files must be adopted (abstracted), too.
many thanks for your reply, it is very exciting to see, that you are working on a replacement for SLS, but frankly, I am still not unhappy with it and it mainly works if you are able to sail around the bugs, which every complex software has.
Actually, I am not looking for a solution you are assuming, I would like to create a standard interface which allows it to exchange an application main screen on users selection. It is the same approach to an option all smart watches have, on which you can replace the standard main dial with customized dials provided by other users.
BR,
Thomas
BTW: I always thought that you are engaged with SLS, too - but this does not seem to be?
Okay, I see now. Companies can really do it, but it’s not straightforward. All the companies I know of came up with a complicated custom solution. If you like challenges it’s definitely a good topic
Defining the view (styles, widgets) is the simpler part. You can pick a format (e.g. JSON), describe the tree and the properties, read the file, and in a big if... else if call the related lvgl functions.
But how to add logic? E.g. do something when a button is pressed. If you can use predefined actions then these also can be handled in the if statement. But if you need something really custom, probably you need a script, and utalize an lvgl binding (e.g. micropython)
all UI item with interaction are equal, so there is not need to take care of user action. Actually, it is only need to make some data driven display elements interchangeable which are less then 10, from which a subset can appear on a screen or not. Basically, it is the same like an interchangeable dial on a smartwatch.
Ahh this your descript say multiple main screens exist in code on compile time and user switch between … = no problem todo
but
next you say as dials provided by other users … = totaly different approach
The smaller the subset of features the simpler the task is. If it’s really just 10 components and a few related properties, I think a custom format would make it, that you can parse easily. E.g.
I having a working importing mechanism written in C++, to import C code generated from SLS into application memory. Then we can filter which we need to use. Is that your need?