LVGL ends its collaboration with SquareLine Studio

Announcements
22

Nice

unfortunately GPL3 - a complete showstopper relegating this project to the backwaters of hardcore believers

IMO not an option as the GPL3 issue is pretty much unfixable

23

GPL3 is a tough nut that’s for sure. It’s a very restrictive license. I personally don’t care for the licensing because of some of the restrictions. It gets used to ensure that any modifications of the code and also any original code is made available to everyone. It cannot be released under a different name without the source code also being made available. The biggest issue is how it deals with using libraries that have different licenses. IDK if there is a license that has the open source protections but doesn’t have the other restrictions.

24

I have seen and tried a few UI code generators, and for my purposes they all fall short. The underlying problem is that they are trying to approximate an all-powerful format (code) with something more humanly manageable (a user interface); they are either too complex to be useful or they leave out some corner case that can only be expressed by handwriting code. On the other hand they add the significant burden of having to keep track of yet another tool while developing a software project, they increase the develop-compile-run cycle time and they bind you to whatever code structure the generate. It’s not worth it.

In my opinion development efforts would be better spent on other aspects of LVGL, like porting to other programming languages or support for other architectures.

3 Likes
25

I respect your opinion. I understand that UI code generators are not for everybody. I have used and continue to use the UI code generator for the development of several large projects. Although I had doubts myself, I never once regretted choosing that path.

With good UI code generator you should be able to mix generated code with handwritten code. If for nothing else, UI code generator can be useful to make a quick prototype or learn about LVGL API.

2 Likes
26

I do agree that the code that is generated is not going to be the most efficient and/or the fastest running code. But for purposes of quick design it can be extremely useful tool… It is also a tool that entry level users will use to get started.

The single biggest piece of the puzzle that is missing is it is not a complete one stop shop so to speak. You cannot select the board and display that is being used. You cannot define the connections between the 2. There are no drivers that get added to the generated code. Displays that have an MCU already onboard are what people are buying because it is already put together. The large portion of the users of this kind of a tool is going to be someone new to dealing with MCU’s and displays and creating UI’s. The software needs to be a start to finish product that will flash the firmware onto the MCU with all the drivers needed to make it work.

A step above that would be to add in the ability to also have hardware support for the pins that are broken out so the user would be able to tie the hardware aspects to the GUI aspects. Nothing overly complex, things like temperature sensors and relays and servo/motor control using PWM.

The trick to doing that is not for the authors to create all of those things but to provide an easy way of letting the users add them. Ideally this could be in the form of toml or xml files that would describe the devices and also have the code needed to make the device work This file would have some kind of a marker in it so if there are parameters that have to be set by the user then the software would have places to let the user enter the information that would be needed. The files would not be included with the main package but a way to browse what is available from an online repository and be able to download a device f they want to use it…

27

My standpoint is that neither full coding way nor the full editor way is effective.

With coding only it’s very tedious to adjust positions, sizes, colors, etc. Especially if you are not working based on a design.

On the other hand the editor can limit your flexibility.

It’s also hard to create a one size fit all tool. I found that novice users prefer drag-and-drop editing, while enterprise companies don’t afraid of coding, but need some special feature.

During my work while working on several kinds of UI projects, I felt like it would be great to just quickly drag and drop a little piece of the UI and copy its code.

2 Likes
28

so what is needed is a way to see the generated code immediately and not have to click on generate then go and open a file and hunt for what has been added. something that would show the code that is going to be used for an element of the UI when that element gets clicked on. so if you clicked on the screen then all of the generated code would be shown and if you clicked on a button only the code for that button would be shown. This would be exceedingly useful!!!

3 Likes
29

IMHO the solution to the code generation problem is to … not generate code.
The two main GUI frameworks around are QT and GTK (at least in Linux) and both GUI Builder’s (QT Designer and Cambalache - formerly known as Glade) use xml ui files as their produced output, this ui files are loaded in the applications with specific API functions, and it works.

1 Like
30

Oh, yes, I’m thinking ab out XML as well. I think XML and C support can leave together. Some needs XML, others need C.

31

Hi Gabor,

The same concept goes for resources like images and fonts and others, gtk i.e. has a quite efficient way to manage those.

32

Ohh, that’s very nice! I was thinking a lot about a good resource/asset managemer, but couldn’t come up with anything really good yet. I’ll immerse in it!

33

Feel free to ask, I have some experience on this.

1 Like
34

Thank you! Actually there are a few things. :slight_smile: Using XML only for the view would be very elegant, but I’m afraid about these on smaller MCUs:

  • How to ship the XML with the binary?
    1. compile it to C by the user?
      • an extra step which is better to avoid
      • no runtime XML loading is required which is good
    2. load it runtime?
      • convert the XML to binary and compile to the code or load from file
      • I’m not sure about how slow it will be.
  • It’s more cumbersome to add extra code to the UI as it needs to extract every widget via an API do something with them.
  • Do you know some limitation of XML to describe the view that we should be aware of? ( know QML and HTML works, but maybe there is something that you might want to highlight.
35

In GTK there are two ways:

  • Ui files (as the other resources) are compiled in c code using a specific tool called ‘glib-compile-resources’ and linked into the executable

  • UI files are loaded at runtime

  • It’s not so cumbersome.

XML is just a description language and thus not declarative.
If you want to support a declarative way of describing the interface (like QML) there’s blueprint.
https://jwestman.pages.gitlab.gnome.org/blueprint-compiler/

36

I also think XML to describe UI with resources (bitmaps, fonts, …) is a way to go. All UI tools will generate this XML and generating C code from this XML will be standardized. Some features I wish:

  • widget identifiers (like id in HTML), so you can easily reference widgets from your code
  • support reusable styles (like class in HTML)
  • support event handling (onClick="user_function"). This will work if C code is generated from XML and user_function is defined. But, it will not work if XML is loaded from string or file during runtime - in that case maybe there should be API registerEventHandler(event_handler_name, void (*callback)(lv_event *))
  • import external XML
37

Slint project has DSL for textual description of your user interface: Slint 1.4.1 Reference. Here is example how C++ code is generated from .slint file.

38

Thank your for both of you! Merging of ideas is in progress :slightly_smiling_face:

1 Like
39
  • widget identifiers (like id in HTML), so you can easily reference widgets from your code
    • correct
  • support reusable styles (like class in HTML)
    • correct (usually a css dialect)
  • support event handling (onClick="user_function"). This will work if C code is generated from XML and user_function is defined. But, it will not work if XML is loaded from string or file during runtime - in that case maybe there should be API registerEventHandler(event_handler_name, void (*callback)(lv_event *))
    • this can be done using a sort of introspection (it’s quite heavy in terms of system’s resources) and a function to ‘connect’ the widget and the callback
  • import external XML
    • correct
1 Like
40

It should also be possible to insert meta information by UI editor inside XML. I think the best way is to allow, inside each element, a <meta-info>...</meta-info> element with open content (i.e. anything can go inside, it depends on UI editor requirements).

41

Sure, you can use widget identifier to connect widget with event handler callback through code. But, if it is specified within XML then that connect call will also be generated. Anyway, both options should be possible.