15 comments

[ 1.9 ms ] story [ 48.1 ms ] thread
Fantastic, C99, min requirement 16Mhz! Makes me want tinker with esp32. Great lib, congrats and thank you.
Found this today too when messing with pinetime watchfaces.
It's so refreshing to see a beautiful, well crafted GUI toolkit with a sane, readable, clean, C API. :D
Man, everytime I see this kind of toolkits I think about the pain the developers have to go through to implement proper text display and editing .. especially with unicode and multiple different languages and input styles.
The author of this library should flaunt his/her power word real name more prominently otherwise we'll never know what hero wrote this!
Hi, I'm the original author of LVGL but now its developed by many talented people. So the current state is not only my merit.

If you have any questions or issue, please use: - GitHub for development related stuff - Forum for how-to, get started, etc: https://forum.lvgl.io/

BTW, due to this thread here, we got 500 starts in one day, which is unbelievable! I was so happy to see your comments, thank you very much! :)

Ok now I’m inspired to use that nice oled display with my pi or esp32… I had been using adafruits gfx libraries while they are great they are pretty low level and require a lot of tweaking to position text… while this might not solve that problem the widget library looks really nice and maybe just need to see it on one of my displays just for fun
A fantastic work, one of the few true graphic libraries that are not the usual pset and drawcircle but true gui management in plain C!

regarding esp32 porting, i have seen that it is possible to use in conjunction with other graphics libraries as 'low level drivers' (e.g. bodmer's classic TFT_eSPI[0]) but i still don't understand the pros and cons of this approach; hypothetically, if i used faster LovyanGFX[1], would LVGL gain in responsiveness?

if so, how to do this?

[0] https://github.com/Bodmer/TFT_eSPI

[1] https://github.com/lovyan03/LovyanGFX

There is an SDL2 binding (https://github.com/Ryzee119/lvgl-sdl) which makes LVGL also useful for desktop/tablet apps. Great stuff. Might even be a good (lean, libre) alternative to existing GUI frameworks like GTK or Qt.
the sad thing about SDL2 is that it longer supports frame-buffer, key to embedded devices needing a GUI, which is also where LGVL targeting.
LVGL is designed to work without direct access to a frame buffer as is the case with SPI displays. You can use smaller draw buffers and it will render regions of the screen in pieces as they are updated.
The SDL2 binding is really nice for people (like me) who use LVGL for embedded HMI. It allows me to test out my UI on my desktop, without having to compile and deploy code to a piece of hardware.
I really don't like internal memory management in such libraries. It should not be btn = lv.btn(lv.scr_act())

but

Button bt; lv.init_button(&bt)

so that I can decide where to keep the memory of button

That is a convenience function. You can manage pointers to multiple screens yourself if desired. An LVGL "screen" is roughly equivalent to an Android activity. A complex UI may need to switch between multiple screens and it is often easier to just ignore lv_scr_act().