Hi, I am new to LVGL and have read the XML section. I am considering the benefits of using a project with and without XML.
Additionally, I don’t understand the difference between a Widget and a Component in the XML format.
I would appreciate any advice you can share.
Thanks
Vu
When looking for some XML-related information on the forum, I noticed no one has answered your question. I hope you haven’t given up on LVGL because of that. The benefit of using XML is that you can describe the UI declaratively, meaning you describe what the UI should look like instead of specifying how to build it step-by-step. Declarative code is easier to read and reduces boilerplate. It is also possible to load the XML code dynamically, which means you can change the UI without recompiling.
It seems the documentation for the XML syntax is not up to par yet, so describing the UI in XML is not quite as easy as it could be. The UI editor helps with its templates and code completion, but before the documentation is complete, some things are easier to do in C. However, if you use the UI editor to generate C code instead of loading the XML dynamically, you can easily combine both approaches.
As for the difference between a widget and a component, a component is a collection of widgets. In many UI frameworks, it is called a view instead of a component. Only widgets can contain custom C code.
I have not been able to fully understand how the XML is going to work either. How to express what needs to be done when there is user interaction with the UI really isn’t going to be possible if that interaction is what would cause aspects of the program that are outside of LVGL to change. Adding external functions to be called to handle those situations is not something that could be added at runtime. This is because there is nothing to tie what is in XML to what exists in C code that would be able to run dynamically. Unless a function is used in compiled C code that function is not going to end up getting compiled into the program.
If a UI only causes changes to the UI when user interaction occurs then it can be done in XML. The number of times that is going to happen might be 1 in 100.
You can define callbacks with the event_cb tag. Obviously, those callbacks will need to be in the compiled code, so you cannot add more of them dynamically, but as long as the functionality is there, you can change the UI on the fly.
OK so question. if the callbacks are not able to be added dynamically how does one register a callback with an object that doesn’t exist? What about the function not being included in the compiled code because it is not actually being used by anything because the object to which you register the callback with doesn’t exist either… How would you register that callback using XML? You cannot do it by name because that would mean the XML parser would need to have forward knowledge of the callbacks existence and that in and of itself negates it from being dynamic in nature…
If you read the linked documentation, you will notice that the callbacks need to be registered with a call to lv_xml_register_event_cb("callback_handle_in_xml", callback_in_c), when the XML is loaded. Since these calls are in the code, the compiler can’t optimize out callback_in_c. Registering the callback doesn’t mean the callback needs to be used in XML—just that it can be. You could thus register a callback for every function you envision could be useful in a UI, and all those would be available for any UI described in XML and loaded dynamically.