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?