High level GUI lib/framework
Posted: Sun Nov 18, 2018 8:46 pm
Hi fellow MicroPythonians,
I'm in the process of planning/building an app for a device that boasts a GUI (320x240 TFT) and has mostly button-driven inputs. It uses Micropython for its main application logic. I really like the full-featuredness of uP and especially the availability of the async functionality is great! This together with the support for my platform of choice (ESP32 + pSRAM) made going for uP a no-brainer.
I am pretty used to and confident writing embedded C code. If have not yet made a native (C) uP module, but I'm certainly not shying away from writing some supporting modules or device drivers in C (planning to do so when needed).
For the GUI part however, this is a bit more complex:
Performance really matters here (shoving a lot of data), so having a fast native module is essential IMO. I'd like to have a somewhat pleasant development experience, so the goal is to have a high(er) level GUI api available in uP. I'm not looking (only) for the lower level routines i.e. a raw framebuffer or some loose line/circle/fill methods.
I found two interesting libs/frameworks that probably would do the job (possibly with some modifications): uGIO from Achim Doebler (https://github.com/achimdoebler/UGUI) and GUISlice (https://github.com/ImpulseAdventure/GUIslice). The latter being the more comprehensive.
Both are written in pure C and it should be relatively easy to get going on the ESP32 (GUISlice even has "official" support for the ESP32 platform!)
As both modules model a GUI, they tend to use OO programming paradigms, with lots of C structs etc. And have a relatively large code base (compare to for instance a simple driver).
My question is:
How would you go about wrapping one of these libs up in a uP module whilst fitting the C object model as neatly as possible into uP?
e.g. having "Window", "button" and "Textbox" classes in uP, that more more less map directly map onto the objects in the C libs. Would this be possible without essentially (re)building the full GUI object model in uP (and as a result only having a low level graphics driver left over in native C code)?
I'm in the process of planning/building an app for a device that boasts a GUI (320x240 TFT) and has mostly button-driven inputs. It uses Micropython for its main application logic. I really like the full-featuredness of uP and especially the availability of the async functionality is great! This together with the support for my platform of choice (ESP32 + pSRAM) made going for uP a no-brainer.
I am pretty used to and confident writing embedded C code. If have not yet made a native (C) uP module, but I'm certainly not shying away from writing some supporting modules or device drivers in C (planning to do so when needed).
For the GUI part however, this is a bit more complex:
Performance really matters here (shoving a lot of data), so having a fast native module is essential IMO. I'd like to have a somewhat pleasant development experience, so the goal is to have a high(er) level GUI api available in uP. I'm not looking (only) for the lower level routines i.e. a raw framebuffer or some loose line/circle/fill methods.
I found two interesting libs/frameworks that probably would do the job (possibly with some modifications): uGIO from Achim Doebler (https://github.com/achimdoebler/UGUI) and GUISlice (https://github.com/ImpulseAdventure/GUIslice). The latter being the more comprehensive.
Both are written in pure C and it should be relatively easy to get going on the ESP32 (GUISlice even has "official" support for the ESP32 platform!)
As both modules model a GUI, they tend to use OO programming paradigms, with lots of C structs etc. And have a relatively large code base (compare to for instance a simple driver).
My question is:
How would you go about wrapping one of these libs up in a uP module whilst fitting the C object model as neatly as possible into uP?
e.g. having "Window", "button" and "Textbox" classes in uP, that more more less map directly map onto the objects in the C libs. Would this be possible without essentially (re)building the full GUI object model in uP (and as a result only having a low level graphics driver left over in native C code)?