Feedback on UI editor

[escherstair]

I've just seen the youtube video on the development of UI editor and I would like sharing my feedback.

• I see the power (and the need) of such a tool if it simplifies the customization of built-in components and widgets (saving them as custom ones) and the creation of new custom widgets. If it's a simple customization, I'll edit the source code and that's all.
• There's a lot of hype in integrating the job of a designer and aof a developer, but based on my experience, it's a difficult job.
  • Designers are designers and they don't like playing with business logic (even if it's only a matter of setting a link to something, or copying and pasting somewhere). So, it's always the developer that should "adapt" to the designer, finishing the job.
  • And I, as a developer, don't want to learn/use designer tools (i.e. Figma) to do my job.
  • Long story short: big effort, but small help from a Figma plugin (the designer won't use it, and I, as a developer, don't like learning Figma). I ask to the designer to give me a finished job or some sketches.
  • Maybe for large companies is different, but for medium/small ones, designers are not ready to the jump.
  • And if you spend efforts in this plugin you won't have resources for other features (more useful ?)
• For the business model, I'll spend money only if I would save my time in some of my tasks
• great idea the CI/CLI integration
• loading XML at runtime seems nice.... but, please make it safe against IP violation (Intellectual Property). It must be impossilbe for a malicious attacker to change the loaded assets. If not, remove this possibility at all.
• develop an easy way to handle localizations
  • take into account that I, as a developer, ask to a translator (human or AI) to get hte localization strings
  • and localized strings are added, change, are deleted, must be reused in different widgets and during lifetime of the product
  • it could be useful if they could be changed (securelly) after the device has been compiled/deployed

Final summary: keep your focus on developing a tool that saves time for C developers. The will be your customers. Not designers.
And keep you focus on embedded usability security, not on wow effects.

Great job.

[kdschlosser]

I agree with you on this. The UI Editor should be a single program and not split into 2 pieces. The thought is currently set as using a program to design the layout and visual parts of the UI and then another tool to alter the underlying code. The single largest issue I see with this is placing part of that system into the hands of people that are not under the LVGL umbrella. We have all been bitten by using an external library and finding out that there is some kind of a problem with it. Getting those problems fixed is not the easiest thing more often than not. Then you have to go in and fix it yourself or you have to add a bunch of code to work around the problem. Historically we have seen that when companies are in control of that library they are not going to make changes on what the user want, they are going to make changes for how they believe it should be done. The problem here is that more often than not this causes all kinds of grief downstream.

Yes it is nice to be able to use code that has already been written and it will speed up development time IF and only IF that code works like it should. This only means that at the present time it is going to work. Changes could be made that ends up breaking your application that you have absolutely zero control over.

This "editor" should handle both the UI design as well as making changes to the underlying code that runs the UI. design folks will use the application to design the UI. This would include placing widgets, colors, artwork, etc.... The programmer would be tasked with adjusting the underlying code to ensure it works properly. That is where the code editor portion of the UI designer would get used.

Having both pieces would put LVGL developers in control of fixing all of the bugs, It removes the possibility of external code causing issues....

This applies to javascript/webapps
https://www.reddit.com/r/ProgrammerHumor/comments/67jnhl/when_people_say_java_is_better/

I feel that the UI Editor should be written using a cross platform GUI framework like wxWidgets. No need to get hunkered down with having to deal with writing some kind of a custom UI for the editor. Use a framework that is targeted at creating a UI that will be displayed in the OS's style. This makes it easier to learn something new. Most people are very familiar with how their OS presents things to them and using a custom UI causes a large spike in the learning curve. Now I know I mentioned not using external libraries. With this example it happens to be an extremely mature library, it's free, it's maintained and updated. When I say mature we are talking 32 years. QT is another that can be used but for commercial purposes it is not free to use.

The worst thing that can be done is tying the use of the editor to a monthly fee. If you want to make money from it then release a handicapped version of the editor. Offer the full tilt version for free to open source projects. a link to the repo would need to be given for where the open source project is and there would have to be active development in that repo. The free license would expire in 6 months or a year and the user would need to request a new license. This would allow for a check to be made to see if the open source project is actually still in development. Companies would have to pay a monthly fee to get the full license. JetBrains (PyCharm, CLion, PHPStorm, etc...) does this. Active Opensource projects can get any or all of their products with a full license for 1 year.

You could even add the requirement that a link to the editors website in the repo's readme file with some text saying "Designed using ....". Adding the same thing in a credits section or a settings section for a UI can also be something that you require.

Just because a project is Opensource doesn't mean no revenue is made from it.

[kisvegabor]

I think we are mostly on the same page. We are clearly targeting developers and not designers. In this sense 2 things can happen:

1. The developer works with a designer (it's 99% that the designer uses Figma). In this case we need to help re-implementing the design. As the design is not functional the developer needs to put together the logic (as you have mentioned). However copying the style properties is a boring and error prone part of the process that we can easily speed up.
2. There is no designer, but developer creates the design too. In this case the tool should be good enough to experiment with the visuals quickly. Component templates could be also useful to get started.

Regarding XML loading, IMO it's the same as Over The Air FW update. You need to sign the verify the firmware before loading it. You an do the same with the XMLs. E.g. ESP-IDF offers solutions for this.

Localization support is definitely on the table: the extra (rarely seen feature) will be to allow previewing if the texts fit to their box. If they don't follow some constraints we can show a warning.

We were using a cross-platform UI library. Actually the most popular one: HTML+CSS+JS. 🙂 The editor is based on React, Node.JS and Electron.

I noted that the issue of monthly payments.

[escherstair]

Regarding XML loading, IMO it's the same as Over The Air FW update. You need to sign the verify the firmware before loading it. You an do the same with the XMLs. E.g. ESP-IDF offers solutions for this.

Dlo you mean that the possibility to load XML on the fly can be disbale for deployed systems?
And, if enabled, it's up to the user setting up a XML signature system?
Or do you mean that this feature will be provided by the tool itself?
Can you provide link to the ESP-IDF solution for this? It can be an inspiration source fo me.

Moreover, just for curiosity, how may work-months (or work-years) have you allocated for lvgl_editor?

[kisvegabor]

Dlo you mean that the possibility to load XML on the fly can be disbale for deployed systems?

Yes:

1. You just don't write a code which can load them 😄
2. You can disable LVGL's XML handling with LV_USE_XML 0

And, if enabled, it's up to the user setting up a XML signature system?
Or do you mean that this feature will be provided by the tool itself?

We might provide some solutions for it, but it seems quite application specific (how you update the firmware, how yo perform the signature, how you validate it, etc)

Can you provide link to the ESP-IDF solution for this? It can be an inspiration source fo me.

See here

Regarding XML loading, IMO it's the same as Over The Air FW update. You need to sign the verify the firmware before loading it. You an do the same with the XMLs. E.g. ESP-IDF offers solutions for this.

Dlo you mean that the possibility to load XML on the fly can be disbale for deployed systems?
And, if enabled, it's up to the user setting up a XML signature system?
Or do you mean that this feature will be provided by the tool itself?
Can you provide link to the ESP-IDF solution for this? It can be an inspiration source fo me.

Moreover, just for curiosity, how may work-months (or work-years) have you allocated for lvgl_editor?

As software development as usual, it will be never finished. We started the research in 2024 January, and planning to have v1.0 in 2025 September. So it's ~20 month, with 3-5 people working on it on average.

We have rough ideas for v2 too, but it's still too far.

[bhspyder]

Was pleasantly surprised by this video. This is exactly what I had hoped for (and had started building early last year).

The main thing I think the video demonstrated for me that other editors have failed on is flexibility. From what I can see of the generated code, it doesn't require you to use a specific application structure. Someone can easily build out a re-usable component library that is git friendly, and can be dropped into multiple projects.

I'm assuming some form of theming can be achieved using constants?
How are images/fonts referenced in the xml?

My feedback on business model would be to not limit certain pieces of functionality by arbitrary amounts. Sell a license that fully unlocks the functionality, not something like "limited to 122 widgets" or "limited to only 14 screens" or "limited to 26 xml files". I think selling the Figma plugin as a separate piece makes a lot of sense as the editor tool is super useful even without it. Floating licenses are super important for businesses with teams of developers that will not be actively using the software 100% of the time.

Excited to try this out whenever it becomes available.

[kisvegabor]

Hi,

Thanks for the amazing questions!

Was pleasantly surprised by this video. This is exactly what I had hoped for (and had started building early last year).

It's fantastic. 😍

From what I can see of the generated code, it doesn't require you to use a specific application structure.

Exactly. I don't like when a tool forces you to use a specific structure either. The initial goal was to have tool that I can just open to put together the visuals of a small component quickly, get the C code, and continue coding. So it's up to you which parts you use the editor for. Maybe you just style a keyboard in it, and do everything else in code. Or you can do all the components here. It's up to you 🙂

I'm assuming some form of theming can be achieved using constants?

I think most of the things can be achieved by constants. But there is more. According to the current plans you will be able to do this:

<styles>
	<style name="big_button" bg_color="0xf00" border_width="1px" pad_left="10px">
		<variant name="color" case="red" bg_color="0xf00"/>
		<variant name="color" case="green" bg_color="0x0f0"/>
		<variant name="color" case="blue" bg_color="0x00f"/>
	</style>
</styles>

In global.xml:

<style_variant name="color" help="Select the color of the UI">
	<case name="red" help="Select a red theme"/>
	<case name="green" help="Select a blue theme"/>
	<case name="blue" help="Select a blue theme"/>
</style_variants>

And if you call a function like lv_xml_set_style_variant("green") all the styles will be updated. So you can easily create e.g. a dark/light theme switch too.

How are images/fonts referenced in the xml?

It was really not shown in the video.

Images (only a simple <file> tag is supported now, but this is the goal):

<images>
        <!-- avatar1.png will be used from file. In XML it can be referenced as <image src="avatar"/> -->
	<file name="avatar" src_path="avatar1.png">
                <!-- A built in image converter can create images with difference sizes and color formats.
                     Constants also can be used as  the value of "width" to change the size of all icons at once.  -->
		<convert path="raw/avatar.svg" width="100px" color_format="L8"/>
	</file>
         
        <!-- logo1.png will be converted to a C array when exported. -->   
	<data name="logo" src_path="logo1.png" color_format="RGB565">
		<convert path="https://foo.com/image.png" width="50%"  height="80%"
		color_format="RGB565" memory="RAM2/>
	</data>
</images>

Fonts (similar to images, but here as_file decides whether to create C arrays or load as files):

<fonts>
	<bin as_file="false" name="medium" src="path/to/file.ttf" range="0x20-0x7f" symbols="°" size="24"/>
	<tiny_ttf as_file="true" name="big" src_path="path/to/file.ttf" range="0x20-0x7f" symbols="auto" size="48"/>
	<freetype name="chinese" src_path="path/tofile.ttf" size="48" custom_freetype_attribute="abc"/>
</fonts>

My feedback on business model would be to not limit certain pieces of functionality by arbitrary amounts. Sell a license that fully unlocks the functionality, not something like "limited to 122 widgets" or "limited to only 14 screens" or "limited to 26 xml files".

I think the same. Even the free version will come with unlimited widgets. Just some features won't be available.

[bhspyder]

Awesome thanks for answering those questions. I would love to take this for a test run if you are looking for help testing.