Hello,
I have just found out about LVGL and I am impressed both by how quickly and how good of a GUI I could develop for an ESP32/ST7735 setup. I also ran the VC++ demo project. This is great!
A feature that I think would be very useful, coupled with the VC++ project would be to develop a QML-like text based way of developing an interface. I am currently looking for a GUI lib that I’d like to integrate into an open source project, I’d like the users of the project to be able to just focus on GUI development without the need to write code. If there was a way for them to develop an interface in QML or something of the likes, test it in the VC++ project and then deploy on the ESP32 target, that’d be excellent.
I want to make sure this request is not understood as supporting QML specifically, but rather a generic user interface markup language.
Hi,
Thanks for this feature request.
When making design/architectural decisions we try to make LVGL similar to the concept of HTML/CSS. It’s not about developing a markup language, but “stealing” some concepts from there.
I think this similarity will help to develop a markup language support at one point. What I don’t know how scripting can be added. Do you have any ideas in this regard?
Thanks for the reply.
I have used QML in the past and so that’s the only markup language I have experience with.
What is good about QML is that it allows a parent/child structure, which is very much there in LVGL. It allows easy alignment of objects, and allows creating complex custom objects as an amalgamation of native objects.
In essence, even XML would work since it would easily bind to LVGL object oriented and inheritance approach.
I have to say that while I was initially frustrated with the complexity of LVGL, this project has grown on me. It is quite powerful and I like it.
Something I will have to report on seems to be an issue with Canvases, whenever I instantiate one in my ESP32 based project I get a linker error related to the data section running out of room.
Regards,
EH
I see, thanks.
What I can promise now only is that we will keep in mind this direction as well when do future planning.
Could you tell what caused the most frustration and how could we mitigate this?
A large canvas needs a lot of RAM. So it’s possible that you are out of RAM. 
Thanks for the reply.
One source of frustration came from the use of macro generated code, and (not) knowing which functions are available to use for a specific object. While it seems there’s a lot of time and effort put into the documentation page, each object is missing a detailed list of API calls. And macro generated code amplifies this since it is impossible to find the exact functions that are available for a given object.
For instance: changing the font of a label. The example given here: https://docs.lvgl.io/latest/en/html/overview/font.html?highlight=font
Makes it look like you have to create a style to be able to change the font on a label. Changing the font on a label should be a pretty easy thing to do, creating a style, modifying it and applying it to the label is a bit more involved.
The documentation doesn’t seem to show (or I couldn’t find it) that they are macro generated functions used to do this very quickly.
The file lv_obj_style_dec.h declares a bunch of functions that allow direct manipulation of the current style of the object style, which shortcuts having to read the style from the object, modify and apply it back to the object.
However if I were to look for lv_obj_set_text_font in the header files as means to find if this function exists and how to use it, I wouldn’t be able to find it because it is macro generated using _LV_OBJ_STYLE_SET_GET_DECLARE. This makes it difficult to know what function exist and how to use it. I’d rather be able to find the prototype clearly specified in a h file.
Does this make sense?
Regards,
EH
The lack of exact style documentation is an issue. I’ve thought about how we can make Doxygen produce documentation for the _LV_OBJ_STYLE_SET_GET_DECLARE functions but haven’t come up with anything yet.
Hm, I see. How complicated would it be to add these functions by hand? Ultimately the properties don’t change too often.
What do you think @embeddedt?
I think a script would be more maintanable. Given we already have a manually-written list of properties here, I’m not sure adding another one is the best idea.
Do you suggest parsing the docs to create the functions?
I could imagine a list that contains basically what is passed now to the macros:
name type func_type
radius lv_style_int_t int
bg_opa lv_opa_t opa
It can be even in lv_obj_style_dec.h or in the script.
I think lv_obj_style_dec.h is probably parseable enough in its current form. It’s essentially a table written with a C macro instead of a text-based list.
I guess I can add this to my ever-growing list of scripting projects! 
1 Like