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.
1 Like
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.
1 Like
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. 
2 Likes
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.
1 Like
This is an example of a smartwatch using LVGL8.3 and 2.5D GPU, which may interest you
1 Like
In case you have missed the announcement:
I want to try out the UI editor and have forked the project and cloned it to my pc. After that follows step 3: Download and install the Editor. But how can i download and install it? I cannot find any instructions of where to find it. Thank you in advance for your help!
Please note this warning in the README. 
Or even YAML, lighter and easier to read IMHO
Finally, we started with XML mainly because itās HTML like (meaning well known).
We might add support for other declarative languages later if there is a strong need.
1 Like
I was involved in a component called angular-schema-form that used JSON as its descriptive.
It was basically only thought to create an input form, and it worked well, even if the forms could nest deep sometimes, just to throw that in. 
WRT XML I am a bit hesitant, note that XHTML has been retired by W3C, and that HTML is now HTML 5. Isnāt it better to go with HTML?
Note however, that XHTML has been retired by W3C, and that HTML is now HTML 5.
In my view, there is no real advantage to being strict if its not very complicated. I mean one can require proper nesting only (because that is basically never wrong today due to checks).
And if you go HTML (by just being less strict), you basically create a web browser and gets access to all the tools and checks for web authoring (you can create a plugin ruleset for the LVGL ābrowserā).
Anyway, regardless of notation, just try to not make any notation do everything, instead make it extensible, and perhaps take some hints from how the big the web frameworks (React, Vue, Ext.js) extend HTML and do these things. Perhaps one of them can be an inspiration and have worthwhile design principles to borrow. There has been lots of thought put into those frameworks.
Just as an example, accessibility has been a big concern and subject to regulation in many countries. Maybe it doesnāt apply 100% to lvgl, obviously, but some principles might.
Hi @nicklasb,
Thank you for joining the discussion.
At this stage I consider using using HTML a little raisky. We donāt see the whole and all rabbit holes yet, so we donāt know what might be needed. So putting limitations on us, might be bad in the end.
As we see and know more, I can imagine a HTML-like version/extension/mode/view/? when the basics are stable.
TBH I was expecting moreāideally a drag-and-drop interface similar to Squareline Studio rather than having to switch between Figma, XML, and manual code editing. This workflow slows down fast-paced UI development, especially since editing code in VSCode is already an option, so editing the code itself within an lvgl editor is not a must in my opinion.
Personally, I prefer not to modify code just to update the design, except when absolutely necessary. Additionally, the setup process seems overly complicated.
At our company, we use LVGL and Squareline exclusively to design the UI for our machines (polystruder.com) and frequently update design elements. Despite some annoying bugs, Squareline Studio meets almost 95% of our needs and it is faster than coding!
While this tool could be useful in scenarios where a graphic designer collaborates with a separate developer, it doesnāt suit our workflow, where the same person handles both design and coding implementation. Figma integration is a good feature, however I hope future updates shift the focus toward a more integrated, drag-and-drop design interface that minimizes coding with it is own GUI editor and moves beyond its current role as I consider it as a previewer or more like an addon.
So for now we will keep using the Squareline for our main editor. However, we will follow the development of this tool and hopefully it will become a fully fledged GUI editor with drag and drop style editing capabilities, where both developer and UI designer can easily use it at the same time.
1 Like
Thank you for the honest feedback! We share these early previews to allow us adjusting the directions if needed.
We have already prioritized at least positioning and resizing widgets with mouse. If there were a list to add new widgets with your mouse I think most of the drag and drop features would be considered okay.
We keep investigating.