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’.

[gkoh]

I'm trialling alternative UIs now and have ordered a M5Stack Core2 to facilitate testing. I'm hoping I can still retain a single UI for all devices.

[matthudsonau]

I think the single UI for all devices isn't the best idea; the Core2 has a touch screen, and it seems a bit wasteful not to utilise that

The learning curve was a lot more like a learning cliff though, which is why my progress died

[gkoh]

I think the single UI for all devices isn't the best idea; the Core2 has a touch screen, and it seems a bit wasteful not to utilise that

The library I'm testing (lvgl) separates the input devices from the widgets. This should allow us to use hardware buttons to navigate, but also define touch response. Either way, with a more advanced framework, we will able to support both buttons and touch, even if they're totally different UIs.

The learning curve was a lot more like a learning cliff though, which is why my progress died

100% understand this sentiment. I've been poking at different libraries for months before I found one that seems to be suitable.

[gkoh]

Progress update: Five complete rewrites later I have a 95% solution in an offline branch, and I'm still not happy with it. The UI code size has tripled along with the complexity.

On the other hand, it looks much nicer and is more flexible. I will try to publish a release candidate once I get to feature/crash parity with the existing UI.