I would place the readability order as TOML, YAML (both close) followed by JSON then XML
While we’re all painting the markup-barn, I say XML because if you make a merge error, it usually isn’t XML. With YAML, it’s usually still YAML, just wrong. That said, YAML is used already in lv_i18n for translation files.
On a different topic, how our code reference objects created by the LVGL UI editor? Will there be object pointers generated for each object, dynamically populated as screens are created, and freed and nulled as screens are destroyed? For each screen, then child-pointers? Just curious.
Great question! We can’t see all the details yet, but I’d like to focus on Observers to separate the UI and application logic.
Hi,
I am new to LVGL. Thanks to @kisvegabor and the team for wonderful UI library. i am using this library couple of months and enjoying very much. for the moment i am using this library with SLS which is good but not perfect.
i am very thrilled for LVGL’s UI Editor. Hope happen something exciting
i have some thought to share for new LVGL Editor:
- There are lot of widget is missing on SLS hope we get all necessary widget
- Should be improve the feature for Multi-language support more easy process (Still i failed to implement this feature )
- It will better if there is separate space for user code segment in every generated file which is not replaced by auto generated like STM32 CUBE do.
- in SLS we cannot use build-in SYMBOL which can be more useful as replace of icon , png file some cases.
- as Embedded system is limited resources i hope there will be some feature or widget which is increase stability and performance of the system. personally i dont think uses of PNG,BITMAP in little MCU is very good option.
I wish for good to all of your team. waiting for something exciting new. have a good day!
Thanks.
Redoy Ahmed
@Redoy I’m sorry for not responding. I’ve just noticed that I haven’t received notifications recently
It’s was great to read your thoughts because they correlate well with my ideas
Important announcement: UI Editor: Introducing declarative widget and UI descriptions
In my project, we handle a large number of localized languages. Testing whether the text overflows from widgets in each language is very time-consuming, and it’s a major concern for me. I’m interested in whether this process can be automated. Does the new tool include the idea of automatically testing for text overflow?
It’s great that you mention this. It was requested by one of our major partner as well. I hope we can directly add it to the editor.
Are you considering providing a page management framework for LVGL? I hope to implement some interfaces for a watch:
- It can swipe left and right.
- It can pull down to access the settings screen or pull up to access the information screen.
- There can be a notification pop-up screen, and it should be possible to return to the previous screen from the notification interface.
- It should be possible to open a menu screen from the main screen and open options within the menu screen.
It’s my old dream to have something like this. It’s not strictly related to the editor, so it can by prioritized only a little bit later.
In case you haven’t heard about it yet esp-brookesia does something similar.
This is an example of a smartwatch using LVGL8.3 and 2.5D GPU, which may interest you