In the past six months, we have been in discussions with both small and large companies to better understand their true needs. Based on these conversations, we have gained a solid understanding of the features that would significantly aid in developing and maintaining UIs: Adopting a XML or JSON based domain-specific language (DSL) to define the view UIs in a declarative way. Modular, easy-to-edit, and developer-friendly generated code for defining the logic. A component-oriented approach, similar to React on the web, along with robust component libraries to facilitate the creation of visually appealing projects even without a designer. Seamless integration with mainstream version control systems like Git, GitHub, GitLab, and BitBucket. A testing tool to detect regressions. Smooth transitions of UIs from Figma.
We have also gained significant partners who will assist us on this journey. We are finalizing the contracts now and hope to disclose their names next month.
While we believe we have a deep understanding of how this tool should work, we acknowledge that our view may not be perfect. Therefore, we will periodically publish beta versions during development to gather your feedback. We are targeting the summer of 2025 for the release of version 1.0.
According to our plans, it will be a closed-source commercial tool; however, it will be free for open-source projects.
Developing a UI editor is a significant step in LVGL’s evolution, and we are eager to hear your thoughts. Did we miss an important feature? Did we approach any aspect incorrectly? Please share your feedback and have a living discussion about LVGL’s UI editor.
I do wonder about the editor itself, will it generate both C code and some sort JSON/XML thing? And how does this work in conjunction with the “React”-like system? I have never worked with React so I have no idea what that looks like altough I assume something like XML?
Furthermore I think these are quite a lot of very big plans- for instance, why bother with the integration of Git etc.? If the editor was to generate binary files containing just some sort of XML view, this would already basically be all that is needed right?
I have the same doubts about the regression tool, please do not bite off more than you can chew, I feel like this is the same issue that Squareline Studio ran into and they were not even trying anything this complicated.
Speaking of Squareline, wouldn’t it be ideal if we could somehow edit the generated code and also run that easily from the editor? So that functions that cannot be easily implemented through the editor may be built and tested in code without leaving the editor?
One important feature that I think is missing is some sort of theme builder with a good all-encompassing preview of the different object types that you make a theme for- I feel like this is an important feature in LVGL itself that I have never messed with because it seems complicated and time consuming to write out.
You should/can write the UI in XML (just like yould write HTML). That will be exported to C where you can add the logic. The generated code sections will have a comment markup so you can re-generate the C from XML at any time and adjust the logic as needed.
By git integration I meant the project should version-track-able, merge-able, human readable and textual, instead of some binary hard to version track blob. We shouldn’t have a git interface as most of the IDE’s (e.g. Eclipse and VSCode) already has one.
Thank you for reminding me about it. We need to find simple yet powerful solutions to solve only the real issues instead of reinvent the wheel. (E.g. not having a “git panel” as IDEs already have one)
I was dreaming about it too. Like writing something in C, jump to the editor to complete a few visual stuff and jump back to code writing. However I needed to realize that if you write e.g. a for loop to create 10 list items, it’s not really possible to re-export the for loop if you modified something related in the editor. It’s because just by seeing the created widgets it would be very hard to map the 10 list items to the for loop in the code. That’s why we shall have the XML to describe the view only, and you can complete it with the logic in code. Normally you need the editor for the “view” anyway, and it’s easier to code the logic.
I wonder if can handle it via components. Like you start with a very simple theme and create you basic building blocks as component. E.g. my_prmary_button, title_labelm, etc. I’d like to publish some component libraries as well that you reuse and modify in your own projects.
That’s great news. We are looking forward to test a new UI tool. The declarative approach using XML sound flexible.
Do I understand correctly that there will be no WYSIWYG editor available?
Does the exported Code follow a standard design pattern (MVC/MVP)?
We would love to see an C++ export that maybe encapsulates the UI views. But maybe that’s a different story.
The main focus will be on the XML editor and a real time preview for it. The preview will have a lot of extra useful measurement and other visualiser tools. You will be able to change only x, y, width and height in the preview, but you will have access to all properties in the in the XML.
Sort of. The XML is only for the view and widget’s logic is defined in C.
Wow , great news! I’ve been waiting a long time for this. I hope the LVGL UI editor will have features like OBP, similar to those in Squareline Studio .
Here are some of the UIs I created using LVGL with the help of Squareline Studio.
For OBP: The editor we have in mind is kind of decoupled from the hardware. You can develop hardware independent components without knowing anything about the hardware.
For example project generation probably we have a separate open source tool.
easy, provide some mechanism to manage different parts of different product models in a UI project.
such as all pages of product A and product B being the same, except for “working” page, the display of product A and product B are different.
would be better if it can conveniently manage multi product
Using components is the early stage of achieving multi product management, then when I export the UI project(the project file itself could be json/xml format that can using git to manage it of course it`s fine) to c/cpp files(that I can directly compile it), in this time, if there is a product management, such the “working” page of product A and product B are different, I can first choose one product type(such product A) then export it.
and, the EEZ Studio, events can be edited graphically through drag, I haven’t used this software much, but it looks quite convenient and many of its concepts are advanced
I think the methodology used by Borland/Inprise for their Delphi and C++ products in their visual designers is still the best I’ve ever seen. Everything is component based but you can switch between visual design and code. The properties palette helps users to understand what properties are available and their current values and exposes the available events, then when you click on an event it create basic boilerplate code for that function. It makes is a lot easier for new users to get up to speed quickly.
Delphi is an example! What we have in mind is closer to how web tools: write HTML but have the power of Chrome Inspector tool to visualise paddings, autocomplete properties, etc and immediately see the result. Just like in Delphi, our vision is to separate the view (use the editor for that) from he logic (write code)
What’s the difference between having 2 products in the same project or creating components for the common parts and having 2 projects for 2 products?
In your idea, what would be the actual requirements?
Do not export some screens/components if they are not related to the selected product?
Support products with different resolution in a single project?
Support products with different branding/assets?
Support some kind of conditions based on the selected product?
It’s definitely interesting but we would like to focus on it now. I believe creating the logic by writing code is simpler and more powerful. The cumbersome part of UI development is to create the visuals (sizes, style properties, etc) as you have imagined or as it’s on the design. And we would like to help with this cumbersome part.
Adopting a XML or JSON based domain-specific language (DSL) to define the view UIs in a declarative way.
, great news! I’ve been waiting a long time for this. I hope the LVGL UI editor will have features like OBP, similar to those in Squareline Studio 
.