Basic User Menu

[FiveTeethless]

Make the display show a basic menu and the current task.

• should use create component for managing tasks #3

[FiveTeethless]

Maybe we should take a closer look onto LVGL:
https://github.com/lvgl/lv_port_esp32
https://github.com/lvgl/lv_platformio

[dhebbeker]

For using LVGL, I think porting/registering a keypad input device type may be interesting for using our buttons. I think the "button" type does not fit for our case, as it maps input to areas of the screen.

[FiveTeethless]

@dhebbeker I just want to let you know, that I have tried LVGL with SSD1306.
Problems seem to be the display drivers to be wit goo performance.

As my own diplay drivers always ended up with a lot of mess on the display, I decided to abandon the idea of LVGL for now.

But good news is, that I found some references for menus that look quite nice:

1. BasicOLEDMenu
   uses our known and working Adafruit_GFX library
   quite basic optics
   all programmed in Code --> can be converted into own class
   has a Wokwi Demo
2. arduino_oled_menu
   uses the u8g or u8g2 library
   looks a bit nicer (of course, it uses bitmaps 😉)
   all programmed in Code --> can be converted into own class
   has some demo videos and seems to be the menu of "Flipper Zero"
3. tcMenu
   uses the liibrary of our liking: Adafruit_GFX, u8g2, ssd1306ascii (for low memory MCUs
   also looks quite nice
   is generated by a designer tool --> I'm not sure how to cleanly integrate it into our project
   has some screenshots online and videos

I am qiute indifferent about options 1 and 2. But the generated Menu seems a bit too much.
What do you think?

[dhebbeker]

I had a quick look at the three options. Option 1 and 2 are projects which have the menu implementation hard coded in the only source file of their projects. As you already pointed out one would have to extract the menu code and preferably put it behind an interface. That means we would have to take "ownership" of the code in the sense that we would have to maintain it. For this the license of arduino_oled_menu is better. I also agree that the third option seems to be bloated for our use cae. It has many dependecies and defines itself a "framework". Using a framework usually means that we have to interwine our code into the framework. I don't like the idea of depending on a framework this much. I noticed that the first two projects use external display drivers. For example the U8glib or Adafruit_SSD1306. But as I understood your message, these drivers have poor performance. How would it help to use the menu code of those projects (option 1 + 2) if they also use those drivers? Wouldn't it be better to use LVGL with those drivers instead? I imagine the GUI would be better drawn with LVGL. We can still replace those drivers with a better one later I the performance becomes a bottleneck.

[FiveTeethless]

I was so focused on makeing LVGL performe better and search for other alternatives. I didn't think of using LVGL with the less performing Adafruit lib.

I updated my last working branch with LVGL and Adafruit library to latest development.

It draws in Wokwi-Simulation.

A menu structure is still not implemented. This is now a hole new task to do 😁

[dhebbeker]

Nice! 🎉

I suggest you open a pull request for the basic capability to already draw with LVGL? This will reduce the extend of code reviews for features based on this.

And I would be able to take the current progress into account when doing architecture related refactoring.