LVGL has a simulator however it only supports the C/C++ languages, and is tightly coupled to some technologies like the Eclipse platform/IDE (very inflexible). More flexibility is needed for the simulator to support additional programming languages like Kotlin for example, which will require dropping the tight coupling to the Eclipse platform/IDE (making the simulator usable in any IDE/Programmer’s Text Editor). Also the simulator will need to simulate multiple display backends, and platforms (eg Embedded Linux).
There is no tight coupling to anything. LVGL is one of the most flexible, excellent gui libraries that exist.
For example I use vscode, but I could still use notepad if I wanted to. You have complete control over display output, drawing functionality, etc. You use cmake to compile everything, IDE is completely a preference. The eclipse and vscode repos are there for convience (I assume), but not necessary.
Also LVGL is a c/c++ library.
2 Likes
LVGL supports makefile, Cmake and simple managed builds too. So you can integrate into any IDE/environment as you wish. However we provide some ready to use projects (in some of them LVGL might be outdated)
Thank you! ^^
1 Like
So the LVGL simulator can run by itself? Do programming language requirements exist with the simulator, or is there a general execution format used by the simulator itself?
LVGL is a c/c++ gui library, but there are other language bindings available like micropython, I’m not sure what or if other bindings exist you can check the github acct.
Overall, I think you should read the documentation thoroughly to understand what LVGL is and is not.
I am talking about the simulator itself. Where is the actual simulator source code located?
Does the simulator exist for LVGL? All I see are code templates that use SDL2 as the display backend.
The simulator source code is in the very repository you linked in your original post. It’s really more of an example project to speed up initial experimentation that uses the SDL2 driver. Since LVGL is platform-independent, there is no “simulation” being done.
Perhaps it should be called a Starter Template instead to remove some confusion. There is a specific definition for Simulator, and this doesn’t match the definition.
1 Like
My intention with the “simulator” was: “simulate a display and touchpad”.
Just out of curiosity, what did you think the “simulator” did?
In having experience with LVGL I can understand how it can be somewhat misleading in the sense that you think LVGL is not meant to be used to build a gui application for pc or something with an external monitor, however I think you had a different interpretation and am wondering what that was and why, as perhaps that would help clarify something.
Was expecting a standalone Simulator that can run by itself (as a separate execution environment), which uses a standard execution format for running applications on the Simulator itself. Something a bit similar to the Android Emulator.
I see the confusion. LVGL’s not an operating system (thus it doesn’t have its own execution format), so the term “simulator” really isn’t the most accurate.
Suggestions are welcome 
SDL Test Bench?
Another suggestion is to call it Starter Project.
I think simulator is not bad, but it just implies that it is emulating something, which may not be the case.
What about something simple like preconfigured ide, or preset pc drivers, preconfigured pc drivers, pc input drivers, or something along those lines. Anyone programming with LVGL should be reading documentation anyway and will learn about drivers, etc.
In my opinion the reason against test, sample or demo is that is is not necessarily a demo or test, it is really just a preconfigured setup for pc development in an ide, at least when I think about it.
“Starter project” or “Starter Template” is actually kind of descriptive of what it is, but I think too vague and not detailed enough.
Using SDL in the name should not be used as drivers vary, is too specific and is not necessarily accurate as the vs simulator uses win32 api (I think). Eclipse, VS Code and Codeblocks use SDL driver (I think). It may also mislead the user to thinking SDL is a major component of LVGL in general.
All the current “simulator” is, is just preconfigured setup for development in computer ide. Preset drivers for the ide ready to go for testing for external screen and devices on the computer (pc), how that is best represented in English, I do not know, these are just suggestions. Pc may not be the most representative term, but maybe the most familiar or popular use that could appeal and be understood to the average user?
Simulator is not bad, but again it implies it emulates something, and in some cases people may not use embedded at all, so they just may use the drivers in the ide as they are, so it is really just drivers set up in the ide for someone to start on pc, and some people may never go embedded.
As an additional thought, I personally see lvgl as a great potential option for laying on top of games for interface (using sdl), or even just simple gui application. Something like imgui. Marketing LVGL towards game developers, particulaly when using SDL would be an interesting approach in my opinion.
Just my thoughts.
LVGL is an excellent awesome library that deserves recognition, the more clear the language to appeal to all levels of programmer, as well as varying marketing routes and use-cases, will lead LVGL to the top.
Thank you for sharing your thoughts!
So now we have these simulator projects:
lv_sim_mdk_an547_cm55
lv_sim_eclipse_sdl
lv_sim_visual_studio
lv_sim_emscripten
lv_sim_codeblocks_win
lv_sim_vscode_sdl
What about something like this similarly to lv_port_* (lv_port_ + target + extra info)
lv_port_pc_eclipse
lv_port_pc_vscode
lv_port_win_visual_studio
lv_port_win_codeblocks
lv_port_linux_frame_buffer (already exists with this name)
lv_port_web_emscripten
lv_port_an547_cm55_mdk
(pc mean cross platform)
2 Likes
I think port is definitely a good choice, and it adds uniformity to everything. I wish I thought of that
It sounds good to me.