Migration from SLS to EEZ. Practical experience

General discussion
1

Yesterday SLS informed me that I could not create more than 150 controls in my pet project and I realized that it was time to migrate to EEZ Studio :slight_smile: In two days I transferred the design of all six forms. During the transfer process, I was learning EEZ Studio and had some problems.

  1. I have a screen that processes click events. In EEZ I can’t set an event handler for the screen itself

  2. Dropdown control does not allow you to set the text (lv_dropdown_set_text) and the list position (lv_dropdown_set_dir)

  3. I have a textarea control that is associated with a keyboard object. If the textarea name contains uppercase letters (for example edMemoName), then the project check gives an error - object not found. Only by changing the name to lowercase letters did I eliminate this error

  4. There is some ambiguity with the naming of objects. For example, if I name the SelectDlgOkBtn object, then in the generated code it will be called select_dlg_ok_btn. I had to change the names of all objects to lowercase with an underscore as a separator, since I believe that the names in the project and the generated code should match.

  5. SLS has a simple animation wizard. I didn’t find this in EEZ - you need to include the flow library, but it seems to me that this is redundant for simple animations that can be supported by standard LVGL tools…

  6. Grouping of objects is not supported. SLS doesn’t have it either, but there is a container object that solves this. It would be nice to have object grouping and containers in EEZ.

  7. When creating an event handler for an object, you must first define a user action, and only then associate it with the object. This is inconvenient; it would be more logical to be able to immediately create a user action with the required name.

  8. No code generation for C++. This results in native action needing to be defined as extern “C”

  9. It is very convenient that named objects are available as structure fields, for example objects.select_dlg_ok_btn (SLS generates code where all objects are defined in a global namespace with ui_ prefix). But it would be more logical for screens to be defined as substructures of objects. In the current implementation EEZ, if we have two screens screen1 and screen2, each of which has a button ok_btn, I should name it differently and refer to it as follows: objects.screen1_ok_btn and objects.screen2_ok_btn. If you make substructures, then the appeal will look like this: objects.screen1.ok_btn and objects.screen2.ok_btn

  10. In EEZ Studio, you can select several objects and perform group operations on them to change properties and place/align. This makes the job easier. SLS does not have such capabilities.

Overall, I found the EEZ interface more convenient. I didn’t have any difficulty getting started with EEZ Studio. However, I did not read the documentation :slight_smile: