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:
- Object Creation:
lv_obj_create - Style/Layout/Flag Assignment:
lv_obj_set_width/height/align, lv_obj_set_style_... - 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.
and
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:
</label>
</button>
</header>
</container>
Now add a new button after the previous one. In XML it’s easy:
</label>
</button>
<button>...</button>
</header>
</container>
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.
2 Likes
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:
XML:
<card>
<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>
</button>
</card>
JSON:
{
"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"
}
}
}
}
TOML:
[card.title]
text = "Card Title"
font-size = "20px"
font-weight = "bold"
[card.description]
text = "This is the card description."
font-size = "14px"
color = "#666"
[card.button]
label = "Click Me"
background-color = "#4CAF50"
color = "white"
padding = "10px 20px"
YAML:
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"
I still love XML the most because it’s short and familiar. What do you think?
3 Likes
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.
2 Likes
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.
1 Like
Yeah, for me too it is anything but xml. I find it way too hard to parse as a human.
1 Like
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!
Nice comparison!
I generally don’t like XML for things like config, but I like it for a UI for several reasons:
- UI’s tend to be deeply nested. Therefore the closing tags in XML, while harder to write, make it much easier to read and figure out where you are. It is very easy to get lost in deeply nested JSON. For most programming tasks, we want to optimize for easy reading, not writing.
- It is more similar to HTML, which many people are familiar with for UIs
YAML and TOML are nice for hand-edited configs, but these don’t tend to be deeply nested.
JSON is good for machine-generated and read configs/data or message payloads that are only occasionally read by a human. However, the nesting complexity of these payloads is relatively small compared to a UI.
HTML has won in UIs, even after untold attempts in our industry to do something else. There are likely good reasons – don’t ignore this.
Thanks for joining!
All things considered I also believe that XML is the safe choice at this point.
2 Likes
Have you considered using YAML instead of XML. I’m seeing a lot more use of YAML than XML in systems like these.
3 Likes
Can you mention a few examples?
I once made a small tool, but there was no progress.
I hope to participate in it
2 Likes
The YAML seems to be the most human readable one. The XML only looks smaller because the parameters were all on one single line, which makes it less readable.