search

justcallmekoko / ESP32Marauder

A suite of WiFi/Bluetooth offensive and defensive tools for the ESP32
5.75k stars 626 forks source link

Compatibility with Odroid-Go and M5Stack #66

Closed RChadwick7 closed 3 years ago

RChadwick7 commented 3 years ago

Is a touch screen required to navigate menus? Or will Marauder run on non-touch devices?

justcallmekoko commented 3 years ago

@RChadwick7 The touch screen is required at the moment. Currently Marauder is not programmed to accept input from any buttons. I am working on a new project that may change this fact though

tobozo commented 3 years ago

@justcallmekoko look at this pull request on the M5Core2 repository, also the corresponding pull request on M5Stack classic to create a unified syntax for button.draw() (although limited to three buttons)

I don't know when and if this will be mainstream, but unifying the syntax will sure create a large compatibility field for the Marauder.

@RChadwick7 as soon as M5Stack accepts these pull requests I'll add the corresponding API entries in the ESP32-Chimera-Core to unlock native support for TWatch, Odroid-Go, M5Core2 and M5Fire but I have strong doubts on the M5Stack classic as it has no psram and the ESPMarauder seems to require that.

@justcallmekoko A quick TODO to make touch/button shim easier to adapt in the future would be to limit the menu items to three elements (smallest set), and make optional all these "touch-only" features (e.g. the drawing app the graph app) when touch-emulation is used instead of native touch.

That would solve both display resolution issues (240x240 doesn't play well with the current UI) and compatibility issues with custom DIY devices.

justcallmekoko commented 3 years ago

@tobozo Yea I will probably get rid of the draw tool since it was there just to see if it could be done. As you know with the "new project" I am going to need to add button support for navigating the menus and functions. Would we need a 3 item menu system for the M5Stack? Couldn't the right button be used to up, the left to be used for down, and the center used for select? If that scheme is used, couldn't the menu have as many selections as we want?

tobozo commented 3 years ago

Up/down/select sounds compatible with any 3-buttons set, 3-positions push-button-switch, touch (capa and resistive), and even yaw/pitch/roll controls.

But overflowing a menu is just a sign of a failure to implement a proper UI.

In terms of UX one should always avoid choice paralysis, paginated options in a menu are symptomatic that the UI failed to meet the hierarchical needs of the platform or the application.

With that in mind, the only sets that could have more than three items are lists (e.g. directory listing).

There's also the display limitation, all 320x240 display aren't 3.5'', so the same button may be very difficult to touch on a M5Core2 when it's very easy on a 3.2'' ILI9341 w/touch from aliexpress.

Fortunately avoiding this curlpit can be achieved by applying some web frontend rules for mobile phones (see google lighthouse).

Even on a 3.2'' display, when the UX rules are met, there isn't much space left for more than three buttons anyway :)

Since the DPI of any given display will affect the button size/margin/padding/font in your app, the smallest screen you want to support should be the one in reference for all the others.