Introducing the Design of the UI editor's XML Markup

Hey,

We’ve made significant progress! After gathering extensive feedback from companies and establishing important collaborations, we have finally begun working on the editor itself too.

The first step was to create several internal proofs of concept. Based on these and the feedback we’ve received, we have started designing how the editor should truly work.

As you may already know, it will be a developer-centric tool aimed at helping you implement and test UI designs at a rapid pace. This means the focus will be on you and your workflow as a developer. :hugs:

Here’s what it means:

  • Modularity is key: you will be able to create custom widgets with a custom API, not just using LVGL’s built-in widgets.
  • The generated code and your written code will coexist seamlessly.
  • The new widgets can be tested.
  • Version tracking will naturally work (we’ll use only text files).
  • The primary interaction with the editor will be through your keyboard, not your mouse.

The core idea is to describe new widgets in XML, with an excellent autocomplete feature to help you write UIs quickly. As you type, the result will be immediately displayed in a preview (similar to Google Chrome’s Inspector tool). In this XML file, you can describe how the widgets look (similar to HTML and CSS). To implement complex logic, you can extend your widgets with custom C code. Finally, your custom widget (XML + C) can be compiled back into the editor, allowing you to use your widget with all its features.

I hope you’re still with me, because here’s the exciting part! :blush: I’ve just published the design of this XML markup. It includes a lot of details about widgets, constants, font and image management, component libraries, and more.

You can take a look at it here: GitHub link. It’s a bit long, but I hope you’ll find it interesting.

Please let us know what you think here or on GitHub. We’re developing this tool for you, and now is the best time to tell us what we should change!

5 Likes

It’s a good start Gabor, keep up the great work you’re doing!

1 Like

I have delved deeply into some UI designers before, and I want to clarify a few things. For example, are the files generated by the new editor build XML+C? Does the SoC need an XML parser to run the resource files generated by the new editor?

Hi,

I’d be happy all the questions that you have :slight_smile:

It’s up to you:

  1. You can export C code which doesn’t require XMLs at all. It’s just C code, similar to what you can write with hand.
  2. Or you can load the XMLs directly if you want.

Hello Gabor,

Thank you for the update and for sharing the progress on the editor. The new modular approach and XML-based UI description sound very promising.

I have a question regarding performance: How will the use of XML-based UI descriptions and custom widgets impact execution speed and memory usage, particularly on resource-constrained MCUs?

Specifically, how does parsing XML at runtime compare to a fully compiled UI in terms of efficiency?

Thanks in advance.

We need to do more tests, but in general there is no significant memory usage while parsing XMLs. Constants, styles, etc are saved in linked list (they would be required for C only UIs too). Besides the content of <view> tag is also saved to allow creating components based on that later. But usually it’s not that long.

Performance-wise, once the widgets are create, there is no XML in use. They are just LVGL widget, running at native speed.

@kisvegabor
It seems I’m a bit (very much :slight_smile:) late. So here are my questions.
First, compared with C code, we had to specify each feature we wanted, and the MCU would process features on each line. Now, with the advent of XML, how does it process the specification we mentioned? In other words, what is the mechanism? (I couldn’t find it on the first shot)
Second, where would the XML data be stored? Should it be saved on an external memory and then fetched? Or again, are they saved on the flash memory of the MCU?
Third, for my previous projects, I had to manipulate the widgets’ source. Is it also supported by the XML, or is XML just used for the first time creation of the pages?

If I understand the question correctly, you are curious of how XML parsing is implemented. If so please check this part of the docs and the XML parsers here

On startup LVGL needs to load the XML files, so you should store them in a non-volatile memory.

Yes, absolutely. You can either

  • Create new widgets and add XML parser, as shown on the links above
  • Or just modify the current widget’s code and XML parsers if needed. These simple C files, so you can do any modifications that you want.

Hi @kisvegabor,

First of all, thank you for working on the LVGL Editor. I am relatively new to LVGL, tried all the UI designers and I think what we really need is a tool that let’s us write the UI in a declarative way with a live preview, like the new editor.

However, to be honest, I am quite disappointed “surprised” about the choice to go with XML. This is not really a format intended to be written (and read) by humans, I think it is primary intended to be processed by machines. It is simply too verbose (so many special characters and syntax boilerplate) to write it by hand, making UI design unnecessary cumbersome (and slow). In the end, an LVGL UI description file is not a data file. And also we don’t need the flexibility of XML or HTML since it only needs to reflect the feature-set of LVGL.

But I am not writing here to complain. I’d like to make a suggestion and share my experience with a large, open-source desktop application (LibrePCB) which I am migrating from Qt to Slint. This UI toolkit uses the same principle as you (a declarative file, a code generator, and a live preview), but they invented a domain-specific language. Honestly I was skeptical about it in the beginning, but after a deeper look (and now heavily using it since half a year), I have to say this DSL is the feature that makes Slint so incredibly powerful. It is clean & lean, with no unnecessary syntax clutter at all (so it is very easy to write and read by humans), and reflects perfectly the structure and feature-set of the underlying UI toolkit (simple example). With the experience I made with Slint, I am pretty sure a DSL for the LVGL editor would be the perfect solution too.

In principle, we only need to transform the XML into a DSL. Let me make a real-world example by converting this XML into a DSL:

<screen permanent="true">
    <view width="100%" height="100%">
        <style name="main" />
        <header title="settings"/>
        <row flex_grow="1" style_bg_color="0xebebeb" style_bg_opa="255" style_pad_all="5"
               width="100%" flex_flow="row_wrap">
            <column>
                <checkbox text="Bluetooth" subject="bluetooth_on"/>
                <checkbox text="WiFi" subject="wifi_on"/> 
                <checkbox text="Notifications" subject="notification_on" />
                <lv_button style_text_font="font_subtitle">
                    <lv_label text-translated="about"/>
                    <event_cb callback="about_click_event_cb" trigger="clicked" />
                </lv_button>
            </column>  
        </row>
    </view>
</screen>

Which could look something like this:

settings := Screen {
    width: 100%;
    height: 100%;
    style: main;
    permanent: true;

    Header {
        title: "settings";
    }

    Row {
        flex_grow: 1;
        style_bg_color: #ebebeb;
        style_bg_opa: 255;
        style_pad_all: 5;
        width: 100%;
        flex_flow: row_wrap;

        Column {
            CheckBox {
                text: "Bluetooth";
                subject: bluetooth_on;
            }

            CheckBox {
                text: "WiFi";
                subject: wifi_on;
            }

            CheckBox {
                text: "Notifications";
                subject: notification_on;
            }

            LvButton {
                style_text_font: font_subtitle;
                clicked: about_click_event_cb();

                LvLabel {
                    text: @tr("About");
                }
            }
        }
    }
}

(just as a very simple example, actually the Slint DSL supports way more specialized features like properties, 2-way property bindings, evaluating expressions, functions, callbacks etc.)

IMHO a syntax like this is so much easier to write than XML. So much less boilerplate and special syntax characters. And it’s also much easier to read. Note that for the live reload in the application a DSL might not be the best solution (maybe a DSL parser is more complicated / larger in size than an XML parser) but I think this feature should have second priority and could be implemented with an intermediate file format (e.g. DSL compiled into XML or even a binary format which is then loaded by the application).

Just wanted to share my thoughts about it. Maybe it’s too late anyway to move to a DSL now, or maybe you have already considered it and decided for XML for some other reasons.

P.S. while writing this post, I ended up converting the globals.xml to a file which is actually YAML (which is also much more convenient than XML) :see_no_evil:

images:
  img_wifi: images/wifi-solid.png
  img_bluetooth: images/bluetooth-brands.png
fonts:
  font_title:
    type: tiny_ttf
    size: 20
    src: fonts/Inter-SemiBold.ttf
  font_subtitle:
    type: tiny_ttf
    size: 14
    src: fonts/Inter-SemiBold.ttf
subjects:
  hours: 17
  mins: 45
  age: 17

Thank you for sharing all these thoughts! :pray:

Selecting the language really started some arguments. To be honest I feel lik there is no good solution :smiley:

  • XML: Well-known, simple, but has some boilerplate
  • YAML: Shorter, modern, white space oriented (which is a pro and con too), supports multi-line strings, which is great
  • JSON: Short and modern, but it’s even less for humans than XML. Having 5 } makes it really hard to understand where you are
  • Custom DSL: Could be the best, but it’s custom so there won’t be any tooling and would have a steeper learning curve.

In the end we have chosen XML because even if it’s longer it’s explicit and well known. Basically if it’s good for web site development, it should be good for us too.


If we consider XML as the base language, it should be really simple to convert it to others in the app.

But let’s finish it with XML first, and let’s see what to do next :slight_smile:

1 Like