GUI framework

[MatthewWilkes]

There's a spike branch at spike/ that doesn't build.

So, it looks like lvgl-micropython-bindings supports being built as a user c module, but it has build errors. I believe that's because the esp32 port code is interfering with the micropython build, as lvgl appears to expect either to be built in esp-idf or micropython. So, I've unset ESP_PLATFORM to force it into the micropython path (which may just cause problems later on), but it's failing not doing code generation It uses add_custom_command to set up the code generation, but then complains it can't find the output files, but my understanding is that the generation happens when the files are depended on gotta love cmake dependencies. Their helpful example project assumes you're wanting to fork micropython, and has diverged from the version we use by 900 commits :) And all the micropython docs and examples use gnu make my slow build env might make it a bit painful but I can take a look? I wonder though if we ought to nail down how app deployment is going to work though? Since we already have _some_ form of UI toolkit with st7789, should we look at getting the app structure and deployment going?

[hairymnstr]

I've spent a few hours on LVGL bindings. After some discussion at and after the meeting in Thursday we've decided to abandon it as the GUI framework. In summary the issues are:

• LVGL doesn't support the ESP32S3 yet
• LVGL doesn't support IDF v4.4 yet
• LVGL doesn't work as a module, you have to build it in to Micropython by modifying the source
• LVGL builds a massive array of auto-generated bindings for the ESP framework which needs modification for the S3 and may conflict with the power management stuff

There's a version of LVGL in the ESP-IOT solution folder which will compile for the S3 but that's only available to the ESP32 C code it doesn't include Micropython bindings.

I can't port the library to the S3 and integrate it with modern Micropython in time.

We could wrap the ESP-IOT LVGL with our own Micropython bindings, we only need the display features because we don't need any touch screen features. I don't like this approach because it means we'd be using a non-standard LVGL implementation which wouldn't match the docs.

So the conclusion is we'll try nano-gui which is pure Python so no toolchain work needed.

Backend there's just a little work to do to wrap our existing display driver to make it a FrameBuffer sub class. That will leave the heavy lifting to the C driver for the display and it means low-level access to the display is still available for graphical apps.

[tomsci]

microgui is merged, resolving.