Preface
Hello,
I’m working on an embedded Device with a Display(obviously) and a Keypad.
The Keypad is a Button Matrix with 5 Buttons Up, Down, Left, Right, Ok and Cancel.
I’m using these Buttons to Navigate my GUI.
The problem here is that I have no way to create Prev and Next Keys with my limited button count.
This should be a common problem with embedded devices but as far as i know there is no direct support for this in the lvgl Framework.
My workaround for this is to simulate the behaviour of an Encoder Type input device with a keypad input device.
I’m checking for the editing state in the input devices read callback and either send the NEXT key on pressing Down/Right or the PREV key on pressing Up/Left on my Keypad if the group is not in editing mode. If the group is in editing mode LEFT/RIGHT/UP/DOWN are send on the corresponding button input.
The Display i use is rather small so most of the time if i have widgets on the screen it’s either a menu which is used in navigation mode or a single editable widget which is set up to be in edit mode and focused.
The navigate/edit behaviour seems to be implemented for encoder devices, but encoder devices aren’t able to generate other buttons like up down ok and cancel so i have to use the keyboard input device.
Problem
Most of my problems with this kind of mode handling starts as soon as i try to navigate multiple editable Widgets. The idea is that if you select a widget in navigate mode that you are able to press the Ok button initiates Edit mode, the edit mode would have to be started by setting the edit mode for the current group of the input device and don’t send the Enter Button. I handle this in the read callback. The problem is that some widgets edit option is to send the Enter button e.g. Buttons Switches etc. these should not enter edit mode on pressing the ok key as this is not the expected behaviour for pressing ok on a button.
This leads to a block of if clauses to check if the Widget in focus is a widget which should just receive the enter button or needs the group to be switched over to edit mode.
Question
Is there a better way to do this should there be some sort of not full keyboard input device which is able to handle these restrictions as this use case is a mix between keyboard and encoder?