Graphical GUI builder support

[CHTUZKI]

A few days ago I found the littlevGL library. I feel that this library is very good. Now I am still new to this library. I want to ask if littlevGL provides a GUIbuilder like STemwin.

[embeddedt]

@CHTUZKI No, LittlevGL does not have a studio for dragging and dropping widgets. Everything has to be done in code at this time.

[CHTUZKI]

So~ Is there any way to implement visual construction?

[CHTUZKI]

@embeddedt

[embeddedt]

@CHTUZKI I'm pretty sure it would require a custom tool to be built. I think that is not on the roadmap at this time, unfortunately.

[CHTUZKI]

@embeddedt OK，thank you for your reply.

[kisvegabor]

I've found this project on GitHub but not sure what it is actually capable of: https://github.com/leQu/littlevgldesiner

[embeddedt]

@kisvegabor I checked the repo and there is no mention of lv_* anywhere in its files. So I think this project is not really related to LittlevGL.

[kisvegabor]

I just guess from the name of the repo.
I will open an issue and ask what's going on.

[turoksama]

Looks like a webpage application?
But no effect.

[AloyseTech]

Maybe we could explore the Qt Creator plugin possibilities?

[CHTUZKI]

@AloyseTech I also want to write a the littlevgl Graphical GUI builder program with QT, but my level of QT is very low. (￣^￣゜)尴尬

[kisvegabor]

To be honest I don't know how QT creator works. Is it extendible like Eclipse?

As @embeddedt mentioned a drag-and-drop designed is not on the roadmap right now, although it'd be a really good thing. So it would be awesome if you were interested in creating a designer but else we still need to wait for it for a while. :(

[AloyseTech]

Even though QtCreator is not based on eclipse, it is fully configurable as well using plugins. The drag and drop interface is a plugin itself https://github.com/qt-creator/qt-creator/tree/master/src/plugins/designer. I have no experience with this kind of stuff though, but Qt provide documentation for creating plugin or provide custom widget to the current Qt Designer plugin.

[kisvegabor]

@AloyseTech I see, thank you for the info.
Please let me know if you (or somebody) is interested in dealing with this topic!

[tianyoung]

Hi~ @kisvegabor Maybe we can start work of lvgl-xml. it will be like HTML.

[kisvegabor]

@tianyoung
Awesome! Can describe your view in more detail? Will it have a drag and drop editor which creates the HTML like XML and an other part which translates it to lvgl functions?

[tianyoung]

@kisvegabor I did some work on my project. I parse the XML with expat and then translates it to lvgl. But as for what you mentioned drag and drop editor, I have no idea yet.

[ivanbraga]

@kisvegabor

Initially, I would like to apologize for the immense text, and for the translation to be done basically by the oracle ggle, except for my part some modifications.

I will describe what I have done and what I have tried, so you and whoever is reading will have a better understanding.

In my everyday I use wxwidgets + codeblocks a lot, without going into detail of the tools, I once tried to port "mix" c with c ++ in these tools and the result was not good, after some modifications in the initial project, no longer received the errors of pointers that were many when adding the "lvgl" folder to the project.

I think my starting point has already been clarified.

Now came the second problem, after further investigating your library, she uses "trickery" tasks to draw the screen.

Describing the problem, in the tools I mentioned above, the best way to draw on the screen, it would be hypothetically speaking to use what in your library is:

/ * Create a screen * /
lv_obj_t * par = lv_obj_create (lv_scr_act (), NULL); / * Create a parent object on the current screen * /
lv_obj_set_size (par, 100, 80); / * Set the size of the parent * /

And inside:

/ * Create a normal button * /
lv_obj_t * btn1 = lv_obj_create (even, NULL); / * Create a parent object on the current screen * /
lv_obj_set_size (btn1, 100, 80); / * Set the size of the parent * /

And in a direct way, without "artifice" tasks, draw in this memory space.

So you could create the drawing of the object, copy, drag and paste it onto the previously drawn canvas.

If you have understood, and within the tools mentioned, you are interested, I am at your disposal.

I was very long in the description, but I tried to be brief, if you have interest, we will continue here or else open another topic.

@tianyoung
We can join our efforts, and produce an IDE for this excellent library.
I think it's a good idea to parse the XML

Thanks for reading.

[tianyoung]

@kisvegabor @ivanbraga I wanna join you, but my project is on schedule, maybe I don't have much time to contribute to this project.

[kisvegabor]

@ivanbraga I'm afraid I didn't fully understand your proposal. So your idea is to create an IDE using wxWidget and make LittelvGL draw to wxWidget canvas?

[pengoor]

@ivanbraga, @tianyoung , XML is a perfect idea.
In GNOME, for example, there is a tool named 'glade(https://glade.gnome.org/)', which can be used to design GUI in XML, and then, GtkBuilder can convert the XML to GTK.
So can we develop a similar lvglBuilder?

[kisvegabor]

@pengoor Is possible to customize Glade for the objects of LittlevGL? Or something similar hast to be created from scratch?

[pengoor]

@pengoor Is possible to customize Glade for the objects of LittlevGL? Or something similar hast to be created from scratch?

@kisvegabor I think it's possible. But, Glade is a little out of date and is not good-looking :-(

[kisvegabor]

@pengoor I see. I was asking about it because you suggested it earlier :) Do you know a good alternative? Or would it's worth to build a drag and drop designer from scratch?

[pengoor]

@kisvegabor Glade is just a sample solution. If we decide to build a professional designer, from scratch may be the only method. After all, there is no free lunch.
By the way, would it's worth to build a drag and drop designer from scratch? My own opinion is, please refer to TouchGFX, it is a necessary step for commercialization.

[kisvegabor]

Making business with a drag and drop designer would require a very different approach:

• marketing
• payment handling
• support
• developers
• etc.

I myself couldn't handle right now to run it on a for-profit basis.
BTW, TouchGFX became free too.

[pengoor]

Yes, you're quite right, it's a different business.

TouchGFX was sold(not free), and now it can only support ST's device.

[kisvegabor]

I mean TouchGFX is now free for the users.

[stale]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[amirgon]

Did you see this?
They also mentioned Python API as an interesting option: ImpulseAdventure/GUIslice#100
I wonder what it would take to port GUIslice Builder to LittlevGL.

[kisvegabor]

They also mentioned Python API as an interesting option: ImpulseAdventure/GUIslice#100

It seems the Python API is for the GUI library and the Builder. The same as you do with Micropython for LittlevGL.

I wonder what it would take to port GUIslice Builder to LittlevGL.

As it's designed directly for GUIslice library (and not as a general purpose tool) I think it wouldn't be easy to port to a completely different GUI library.

[AGlass0fMilk]

I would be interested in helping develop this, it is one of the missing pieces of LittlevGL that other more popular libraries have...

I don't think we necessarily need to go XML to LittleVGL. It could generate LittlevGL code on the fly. Then whatever UI framework we use for the application will likely have a canvas-like object that we can port LittlevGL to draw to and do WYSIWYG updates. Possibly have multiple instances of LittlevGL running to generate the previews for each type of widget. This would then work for custom widgets as well. LittlevGL itself expects to run as a monolithic instance though so I'm not sure how to handle that.

I have no idea where to begin with this project. If we can agree on a framework to start with (like Qt) and go from there it would be an interesting project.

@kisvegabor perhaps you can reopen this issue for more visible discussion?

[kisvegabor]

@AGlass0fMilk

I would be interested in helping develop this, it is one of the missing pieces of LittlevGL that other more popular libraries have...

Awesome! :)

Possibly have multiple instances of LittlevGL running to generate the previews for each type of widget. This would then work for custom widgets as well. LittlevGL itself expects to run as a monolithic instance though so I'm not sure how to handle that.

@amirgon has developed a Micropython interface for LittelvGL and @rreilink has work in progress Python binding. Using one them it seems possible to run one instance of LittlevGL and controll it with a script API. What do you think?

[amirgon]

@AGlass0fMilk @kisvegabor

I have an idea.
A GUI Builder can be built entirely on Micropython (or Python, when it's ready) as a monolithic application that generates a python script dynamically. The generated python script would actually be the built GUI and could be used on other applications (it will require micropython support on those applications).

This is possible because Python is a dynamic language, where you could create code on runtime and run it immediately. So when you add a button for example, the GUI Builder appends lv.btn(..) to the script, and evaluates (runs) it to display it dynamically.

One advantage of such GUI Builder is that it does not need a special "environment". It's just a Python script by itself, so It could run on any platform that runs Micropython+lvgl (or Python+lvgl), for example the unix port of lv_micropython repo.

If this sounds like an interesting option, I can create a proof-of-concept that shows how to create a script dynamically as a response to GUI events.

[embeddedt]

@amirgon I like the idea, but for existing users, I think we need to consider that:

• I doubt a large majority of our current user base is currently using Micropython. (I don't have any facts for this however.)
• Micropython seems like a pretty large code base to add to an existing project just to be able to use the GUI builder.
• If the project is already written in C, this would require existing users to do a lot of porting of their code or to add bindings for their own functions.

That being said, we could have two separate GUI builders: one targeting C/C++ and the other targeting Pythonic languages. What do you think about that?

[amirgon]

@amirgon I like the idea, but for existing users, I think we need to consider that:
...
That being said, we could have two separate GUI builders: one targeting C/C++ and the other targeting Pythonic languages. What do you think about that?

@embeddedt Having two GUI builders doesn't make sense. We should strive to concentrate the efforts on one goal, not do the same thing twice.
Imagine that @kisvegabor and @ImpulseAdventure worked together on a single GUI library.
Today we have two libraries, LittlevGL and GUIslice that are targeted to the same audience - embedded device GUI.
If, instead of developing two independent libraries they had joined forces and had created one, we would had one library but a much better one, with a working GUI Builder already!
So let's not do the same mistake twice.

Now, I think that my suggestion could be good enough for everyone, also for those lvgl users who write pure C and not use micropython:
I suggested that the GUI Builder would generate a Python script that builds the GUI, but it can also generate C source that does the same thing. That would probably be pretty easy since the Python and C code that access the lvgl API is close enough.

[embeddedt]

... it can also generate C source that does the same thing. That would probably be pretty easy since the Python and C code that access the lvgl API is close enough.

Then I have no problem with that approach.

[embeddedt]

Today we have two libraries, LittlevGL and GUIslice that are targeted to the same audience - embedded device GUI.

I'm not sure that they're targeting the same audience. GUIslice looks to me like it's designed with a simplistic, barebones look - whereas LittlevGL does alpha blending, shadows, etc.

[amirgon]

I'm not sure that they're targeting the same audience. GUIslice looks to me like it's designed with a simplistic, barebones look - whereas LittlevGL does alpha blending, shadows, etc.

Oh, I think that they are targeted to the same audience, it's just that LittlevGL is much more advanced, for the reasons you pointed out and for other reasons. But GUIslice has a GUI Builder, that's its main selling point . My point was that if there was one library we would have both LittlevGL advanced features and a GUI Builder.

[kisvegabor]

I also like the idea of using (Micro)python as the engine of the GUI builder. It would be possible to export the Python code or convert it to C.

@AGlass0fMilk What do think about it?

With the existing and planned features of v6.0 plus the GUI builder, LittlevGL can be the most feature-rich embedded GUI library. I don't even commercial competitors who have:

• High-level drawing without double buffering
• So many widgets
• So portable
• Keyboard, encoder support
• Advanced internationalization support
• Script binding
• and GUI builder

So guys, I can say something great is happining here. :)

[AGlass0fMilk]

Since the core library is written in C, I think we should consider focusing on writing the GUI builder for and with C/C++.

I think maybe what we could do is have the GUI builder generate C code so that it works with those who want to use the core library. Then, for those who want to use MicroPython, we can do something similar to how the MicroPython code is currently being generated. The generated Python binding can expose application-level calls (like button clicks, etc) to the user for implementation in Python.

I like the idea of using python to create the GUI builder application though. Perhaps we could use a binding like CFFI to call into LittlevGL?

MicroPython is a very nice extension but I think writing the GUI builder for a higher level abstraction will cause headaches down the road in terms of maintenance and binding discrepancies.

EDIT:
I looked a bit at how MicroPython is generated but I'm still not 100% sure how close the APIs match.

Maybe it would be worth trying to write it with Python using the MicroPython binding and then export to C.

[amirgon]

Since the core library is written in C, I think we should consider focusing on writing the GUI builder for and with C/C++.

@AGlass0fMilk Please explain this. I don't follow your logic.

I think maybe what we could do is have the GUI builder generate C code so that it works with those who want to use the core library. Then, for those who want to use MicroPython, we can do something similar to how the MicroPython code is currently being generated.

I suggested in the post above to use micropython to generate both C and micropython code from the GUI builder.

I like the idea of using python to create the GUI builder application though. Perhaps we could use a binding like CFFI to call into LittlevGL?

There is already a micropython binding to lvgl, why not use it?

MicroPython is a very nice extension but I think writing the GUI builder for a higher level abstraction will cause headaches down the road in terms of maintenance and binding discrepancies.

I don't understand what you mean, you can use micropython to write low level calls to lvgl API, just like in C.

I looked a bit at how MicroPython is generated but I'm still not 100% sure how close the APIs match.

I think it's close enough. Please provide examples.

Maybe it would be worth trying to write it with Python using the MicroPython binding and then export to C.

Please explain why you think it would be worth it.

[AGlass0fMilk]

@amirgon

By "the core library" I mean LittlevGL is originally written in C. As it is targeted towards embedded development, C will surely be the most attractive implementation to developers looking for an embedded GUI library solution.

MicroPython is essentially a wrapper on top of this core library. So if the core library can be wrapped, then a generated GUI could also be wrapped to work with MicroPython.

---

I basically have two suggestions for the possible architecture of the GUI builder:

1.) Export to C, wrap the generated GUI

My initial thought was to follow the same architecture -- export to C under the hood and generate a binding for MicroPython.

This would keep the C implementation lightweight and modular (as C developers can simply use the exported code). The MicroPython layer would be in addition to rather than instead of the C layer, which is the way it is now. This provides both C and MicroPython developers a way to build GUIs with the same application.

It would keep us from having to write an exporter for each supported language (I eventually want to make a C++ wrapper to go with my Mbed-OS port).

---

2.) Implement GUI builder in Python, create modular exporters for each supported language

On the other hand, what we could do is just write the GUI builder application in Python. Then we create some sort of abstraction layer for the underlying code generator. We implement this API with an exporter module that is specific to each language we want to export to. This will let us support different languages without too much extra work.

---

I want to emphasize that I think one of the most appealing aspects of LittlevGL is its lightweight, portable C-based implementation. So I think the focus of a GUI builder should be on primarily supporting C first. Then we can build up complexity (like MicroPython bindings) from there.

---

In response to your other comments:

I see now that the MicroPython binding would be the same thing as CFFI.

If the API is close enough, then let's start architecting the Python-based GUI builder.

I think it would be worth trying with Python because:
Python would be easy to start with and is cross platform (if we choose the right libraries). Python is much quicker and easier to develop application-level projects with than C/C++.

Personally, I'm already familiar with several GUI libraries for Python.

@kisvegabor Is there someplace (like a wiki or google doc) that we can start hashing out the architecture of this GUI builder application? Or maybe a new repository with a README so we can also start submitting new GitHub issues related to design.

Once we have an architecture sketched out we can each start developing parts of the application in parallel.

[AGlass0fMilk]

Just brainstorming here. A few considerations I thought of (these would be separate issues on a dedicated GitHub project):

1. LittlevGL heavily relies on preprocessor configuration that is then "set in stone" at compile time. Users will likely desire to change some of these parameters when designing a GUI (such as screen resolution, PPI, etc). A couple proposed solutions:

   a. Modify lvgl codebase to have adjustable parameters at runtime if being built for GUI builder. More work, but more flexible.

   b. Have users create a project and decide compile-time parameters before they start a new design. Less work, but designs may not be portable between different settings. This may be an easier path for the first version of the GUI builder.

2. We can have the GUI builder automatically disable components that a design does not use at time of generation. This ensures the final binary/resource footprint will be as compact as possible. When a user places a widget that requires an additional component, we can have a pop-up window that warns what components will be enabled and even how much ROM/RAM they require.

3. In what format will designs be saved in? Perhaps it is worth investigating an intermediate XML representation.

4. We may have to introduce code tags (like a comment with an "@" symbol) or some sort of standard when writing LittlevGL widgets. This way it will be easier to tell what fields of an object can be modified and how they should be presented to the user for modification.

[kisvegabor]

Is there someplace (like a wiki or google doc) that we can start hashing out the architecture of this GUI builder application? Or maybe a new repository with a README so we can also start submitting new GitHub issues related to design.

I've created a repo for it and gave write access to @AGlass0fMilk: https://github.com/littlevgl/lv_gui_builder

And created the first issue to discuss the architecture: lvgl/lv_gui_builder#1

So let's continue this topic there!

Thank you very much for your contribution so far. Can't wait to see it! :)

[haideemarantan]

@kisvegabor I did some work on my project. I parse the XML with expat and then translates it to lvgl. But as for what you mentioned drag and drop editor, I have no idea yet.

How did you parse the XML to LVGL?