Design a better UI for the M5Stack Core2

[matthudsonau]

Preface: I have no idea if this belongs in this project, or if I should just 'steal' the camera communication parts and make my own

I now have a M5Stack Core2 (ok, two: I like to have a spare to loan out to people). With the touch interface and the addition of two extra buttons (three below the screen and two on the side of the case) there's definitely a lot more options for a UI than on the M5Stick, plus the bigger screen means that the current UI could definitely stand to be improved

[gkoh]

I'd really like to keep the UI code all together for all the devices if possible, the differences in driving the camera should be "easy" to isolate and configure.
M5Core users can have a "nice" experience, whilst the M5StickC users should retain the "minimalist" experience.

My suggestion is:

• keep the UI code in this project
  • put in a new UI library under lib
• use the existing M5ez code to bootstrap
• iterate and replace the M5ez pieces
• if the UI library becomes advanced enough, split it out to separate repository
  • I can see a potential to fill the gap left by M5ez being unsupported

My 2c.

[gkoh]

@matthudsonau If you're interested, happy to support, UIs aren't really my 'thing'.
I think an easy start could be to trial replacing the M5ez::msgBox for the shutter control.
All the M5ez code uses the underlying M5Unified library, so you could fairly easily call something entirely different to draw a new message box. Once you return, M5ez will redraw the canvas so it should just go back to 'normal'.

Part of the problem (and ease) with M5ez is abstracting all the UI code away so the non-UI people (like me) can just draw some text and buttons without thinking too much.
If you choose to not abstract it, you can just draw the widgets exactly and how/where you want them.
The challenge will be supporting both StickC and Core without duplicating code all over the place.

[matthudsonau]

@matthudsonau If you're interested, happy to support, UIs aren't really my 'thing'. I think an easy start could be to trial replacing the M5ez::msgBox for the shutter control. All the M5ez code uses the underlying M5Unified library, so you could fairly easily call something entirely different to draw a new message box. Once you return, M5ez will redraw the canvas so it should just go back to 'normal'.

Grateful for the support. UIs aren't my thing either, but to be honest neither was any of this a week or two ago. I'm sure I can butcher something together that'll at least be a reasonable starting point

The challenge will be supporting both StickC and Core without duplicating code all over the place.

I'm sure I can just ignore this and it'll never cause any problems ever 😛 Hopefully everything below the UI can be abstracted away and used for both. I don't see much UI reuse, simply because the interfaces available on the Core are significantly better than the StickC

[matthudsonau]

I'm going to throw it here (because it should be handled by the UI changes): Connect should not be an option if the saved connection list is empty

[gkoh]

I'm going to throw it here (because it should be handled by the UI changes): Connect should not be an option if the saved connection list is empty

Good point. Neither should ‘Delete saved’.
This is straightforward to implement in the current system.

With more buttons, ie not M5StickC, there could be only a ‘Connections’ entry that supported both ‘Connect’ and ‘Delete’.