Work began on LVGL's UI Editor 🎉

A comparison here:

Mostly because it is a map structure instead of a tree, and because it does no processnig on its own, not to mention that it is much easier to read as a human.

This is an exciting announcement.

Modular, easy-to-edit, and developer-friendly generated code for defining the logic.

I have a specific request to break up screen construction into phases. Another UI design tool targeting LVGL puts everything into one ui_${SCREEN_NAME}_screen_init() function. I’d like to suggest this be done in at least a few phases/functions:

  1. Object Creation: lv_obj_create
  2. Style/Layout/Flag Assignment: lv_obj_set_width/height/align, lv_obj_set_style_...
  3. Content Assignment: lv_label_set_text/lv_roller_set_options/lv_textarea_set_text/…

For the most common case of loading a new screen, all three will run in order, but once a screen is loaded now you can reset the screen’s geometry, and you can retranslate a screen after calling lv_i18n_set_locale() without needing to destroy and recreating the entire screen.

this is it
I have three pages, Product A uses the first and second pages, and Product B uses the first and third pages. I hope to export only the those I used when exporting.


In addition, regarding the multilingual switching of lvgl, currently I am using lv_i18n. I write a script to extract all the functions that set texts. After switching language, I call these functions once to refresh, I hope when exporting, also generate a fun that contains those funs that refresh all text for language switching.

1 Like

But UI is a tree and not a map. Practical example: You can easily see this in JSON:


In XML it would be:


Now add a new button after the previous one. In XML it’s easy:


The lack of commenting in JSON is also a problematic.

I think it should be resolved in LVGL. E.g. have some special functions like:

lv_label_set_text_translation(label, "home");
lv_checkbox_set_text_translation(label, "option");
lv_dropdown_set_options_translation(label, "option1\noption2");

These function would save the “tag” and on a special event an update their text from it.


I see and I will keep in mind. Something similar came up from a big OEM too. Now we are working on the basics so these high level features will be on table in ~6 months. Thank you for the input anyway!

1 Like

I would also like you to consider Yaml or Toml.
It would be great if they were as easy to edit as Qt’s QML.

I’ve asked ChatGPT to show examples for basic card element in XML, JSON, TOML, and YAML:


    <title style="font-size: 20px; font-weight: bold;">Card Title</title>
    <description style="font-size: 14px; color: #666;">This is the card description.</description>
    <button style="background-color: #4CAF50; color: white; padding: 10px 20px;">
        <label>Click Me</label>


  "card": {
    "title": {
      "text": "Card Title",
      "style": {
        "font-size": "20px",
        "font-weight": "bold"
    "description": {
      "text": "This is the card description.",
      "style": {
        "font-size": "14px",
        "color": "#666"
    "button": {
      "label": "Click Me",
      "style": {
        "background-color": "#4CAF50",
        "color": "white",
        "padding": "10px 20px"


text = "Card Title"
font-size = "20px"
font-weight = "bold"

text = "This is the card description."
font-size = "14px"
color = "#666"

label = "Click Me"
background-color = "#4CAF50"
color = "white"
padding = "10px 20px"


    text: Card Title
      font-size: 20px
      font-weight: bold
    text: This is the card description.
      font-size: 14px
      color: "#666"
    label: Click Me
      background-color: "#4CAF50"
      color: white
      padding: "10px 20px"

I still love XML the most because it’s short and familiar. What do you think?

It is very exciting to got finally the UI editor will become true. I’m happy I was going with the team in a very short period of time and I believe the team is very strong & the UI Editor would be very flexible.

For XML we need to write closing/ending tags, for JSON we do not need, I myself see JSON is faster to type.

Why don’t we support both ? We do not need to decide.


It was our pleasure!

On the other hand for JSON you need to type { and ".

I prefer all the options other than XML.

Your comparison is not apples-to-apples since the style nodes for XML have been reduced to a string - you can’t query the font-size without string operations for example. For a fair comparison, style should be expanded like in the other formats - or the other formats should have style reduced to a string. Making those changes will show that XML is the most verbose.

Choosing from the other formats, I often lean toward JSON because of it’s simplicity and ubiquity but the lack of an ability to add comments is a drawback. I’d probably still choose JSON.
YAML is flexible but has been criticised for it’s complexity. TOML is great for smaller configuration files but scales poorly as complexity increases.

None are perfect, but I generally like XML least.

Yeah, for me too it is anything but xml. I find it way too hard to parse as a human.

Yaml is easy to read and edit, but the complexity of the specifications can cause problems.
Json is stable and the most reasonable, but it is tedious because you need to write " and , frequently. Problems with comments, etc. can be solved by using Json5.
Pkl is my favorite syntax, personally. But the problem is that it is too new.

Pkl is really interesting! It supports something similar to XML schema in a much simpler way.

Having loops is also cool!

The only issue really is that it’s new and not known by people yet.

Anyway we are investigating now. Thank you for the great idea!