EdgeTX 3.0 Events handlig

[JimB40]

CURRENT

There are four types of events generated when a key is pressed on the radio:

FIRST - when the key first pressed.
BREAK - when the key is released.
LONG - when the key is held down for a bit.
REPT - when the key is held down for a bit longer (this can be sent multiple times).

Event constants are generated based on hardware key name and type of event (xxx)

EVT_PAGE_xxx
EVT_MENU_xxx
EVT_ENTER_xxx
EVT_EXIT_xxx
EVT_PLUS_xxx
EVT_MINUS_xxx
EVT_ROT_LEFT
EVT_ROT_RIGHT
EVT_UP_xxx
EVT_DOWN_xxx
EVT_RIGHT_xxx
EVT_LEFT_xxx
EVT_SHIFT_xxx
EVT_PAGE_xxx
EVT_PAGEUP_xxx
EVT_PAGEDN_xxx
EVT_SYS_xxx
EVT_MODEL_xxx
EVT_TELEM_xxx

if radio is equiped with touch screen aditionally touch events constants are defined

EVT_TOUCH_FIRST
EVT_TOUCH_BREAK
EVT_TOUCH_SLIDE
EVT_TOUCH_TAP

[JimB40]

CURRENT

Use cases when designing user interaction.

1. Multi function key.

• in this case let's call it 'press action' is always binded to key release BREAK (falling edge)
• FIRST (rising edge) is not used
• prior to sense BREAK (falling edge) OS will always check for LONG (more or less 0.5-0.8 sec) and REPT
• we have 3 options tu use:
  • LONG (ie used for context menu)
  • REPT (ie used to alter speed)
  • BREAK (ie used to perform default key action)

2. Single function key

• in this case let's call it 'press action' is always binded to key press FIRST (rising edge)
• killEvents() should be performed to supress other events (LONG,REPT,BREAK)

Coding with "single function key" option has visible UX/UI impact (it's faster) due to the fact there is no delay to check if user wanted LONG press.
BREAK can be genterated before LONG 0.5 sec delay (grey line on picture) and then LONG & REPT will not happen, or befor first REPT then key events que will be only FIRST,LONG,BREAK. Still there will be physical delay due to the fact action will be performed on key release.

When UX is coded with FIRST event overall UI speed is slighly faster.

[JimB40]

EdgeTX 3.0 Implementation

EVT_xxx naming

There are two kinds of EVT_xxx constants.

1. Physical (connected with hadrware key)
2. Virtual (connected with OS UI function)

Physical constants
names should follow strictly hardware key label if key is labeled on radio chassis.
Even today I debug simple mistakes because there is EVT_MODEL_xxx not EVT_MDL_xxx or EVT_TELEM_xxx not EVT_TELE_xxx

Going through available keys constants:

a. EVT_ENTER_xxx -> OK

b. EVT_EXIT_xxx -> OK

• key is usually labeled RTN, but I'd leave EXIT as historically RETURN was connected with big ENTER key on keyboard so it may be confusing

c. EVT_MENU_xxx -> OK

• mostly FrSky

d. EVT_PLUS_xxx, EVT_MINUS_xxx -> OK

• only on FrSky X9D

e. EVT_PAGE_xxx -> OK

• on radios with single page key. Mostly FrSky

f. EVT_PAGEUP_xxx -> EVT_PAGENEXT_xxx

• mostly on Radiomaster radios
• UP & DOWN is code heritage after first X9D. It carries physical direction information so it's confusing if key is labeled as on TX16S ie PAGE> & PAGE< (which one is UP?)

g. EVT_PAGEDN_xxx -> EVT_PAGEPREV_xxx

• mostly on Radiomaster radios
• UP & DOWN is code heritage after first X9D. It carries physical direction information so it's confusing if key is labeled as on TX16S ie PAGE> & PAGE< (which one is DOWN?)

h. EVT_ROT_RIGHT -> EVT_ROT_NEXT

• same as with page keys if rotary encoder is mounted verically or at angle (Tango) RIGHT & LEFT are confusing

j. EVT_ROT_LEFT -> EVT_ROT_PREV

• same as with page keys if rotary encoder is mounted verically or at angle (Tango) RIGHT & LEFT are confusing

k. EVT_SYS_xxx -> OK

l. EVT_MODEL_xxx -> EVT_MDL_xxx

• hardware key is labeled MDL

m. EVT_TELEM_xxx -> EVT_TELE_xxx

• hardware key is labeled TELE

n. EVT_UP_xxx, EVT_DOWN_xxx, EVT_LEFT_xxx, EVT_RIGHT

• those are connected with radios equipped with hat (joystick) - ie XLite, NV14, EL18
• to be consistent I'd go with EVT_HAT1_UP_xxx, EVT_HAT1_DOWN_xxx, EVT_HAT1_LEFT_xxx, EVT_HAT1_RIGHT_xxx
• additionally there should be EVT_HAT1_MID_xxx
• if there are more than 1 hat - EVT_HAT2_... constants

o. EVT_SHIFT_xxx -> EVT_OPT_xxx

• this hey is present only in XLite. Renamin is optional although radio docvumentation is naming this key as OPTION

Virtual constants

Virtual events contants are just alias to one of hardware key contants.
Naming and function follows OS UI function rather than hardware key

For most LUA dev use cases virtual EVT constants should be choosen
Exceptions now:

• LUA dev wants to implemeny multi function key support
• EVT_VIRTUAL_xxx implementation is broken :) Yes developing cross-radio LUA code I've encouterd many cases when alias was either wrong or not defined. Finally after many user issues, landed with own constants for each radio.

a. EVT_VIRTUAL_PREV
b. EVT_VIRTUAL_NEXT
c. EVT_VIRTUAL_PREV_REPT
d. EVT_VIRTUAL_NEXT_REPT
e. EVT_VIRTUAL_DEC
f. EVT_VIRTUAL_INC
g. EVT_VIRTUAL_DEC_REPT
h. EVT_VIRTUAL_INC_REPT
i. EVT_VIRTUAL_PREV_PAGE
j. EVT_VIRTUAL_NEXT_PAGE
k. EVT_VIRTUAL_MENU
l. EVT_VIRTUAL_MENU_LONG
m. EVT_VIRTUAL_ENTER
n. EVT_VIRTUAL_ENTER_LONG
o. EVT_VIRTUAL_ENTER_REPT

This list should be verified but looking what is defined I can see that inital idea drifted.
Sometimes there is REPT or LONG that is connected to hardware key behavior instead UI funcion.
IMHO virtual events shoud be only for OS UI function, if LONG press event is needed thee is physical key constant for that
So:

a. EVT_VIRTUAL_ENTER
b. EVT_VIRTUAL_EXIT
c. EVT_VIRTUAL_PREV
d. EVT_VIRTUAL_NEXT
e. EVT_VIRTUAL_DEC
f. EVT_VIRTUAL_INC
g. EVT_VIRTUAL_PAGE_PREV
h. EVT_VIRTUAL_PAGE_NEXT

regarding other vistual constants

• EVT_VIRTUAL_MENU should be alias to whatever opens EdgeTX Quick Menu

We should introduce

• EVT_VIRTUAL_MODEL
• EVT_VIRTUAL_MODELS
• EVT_VIRTUAL_RADIO
• EVT_VIRTUAL_APPS
  etc.