I am quite stumped. According to the documentation:
when navigating a goup one has to use the LV_KEY_PREV and LV_KEY_NEXT keys
when using a roller, button matrix, tabview etc. it is keys LV_KEY_LEFT etc. that are being used.
My questions:
Why is it that a button matrix behaves differently than a group? Basically: what is the difference (apart from visual and memory footprint) between a group of buttons and a button matrix?
Why use LEFT/RIGHT instead of NEXT/PREV to navigate a roller or a tabview?
Basically: why inhibit the use of NEXT/PREV in button matrices, rollers etc.?
NEXP/PREV is used to navigate among the widgets. Button matrix and roller are complex but they are still 1 widget. LEFT/RIGHT/UP/BOTTOM is used to navigate inside the widget (roll the roller, select the next button of the button matrix)
The button matrix is 1 object which has many simple buttons inside. You have less freedom with it compared to a normal button. Speaking about groups: imagine that you have a keyboard (built from a button matrix with 50 buttons) and 2 normal buttons on the left and right of the keyboard. Now the left button is focused and you want to go to the right button. If the button matrix were 50 normal buttons you had to press tab 50 times. With the button matrix, it’s just one press.
Let’s imagine two rollers and one of them is selected. Now when you press LV_KEY_NEXT the other roller is focused. What would you expect?
@kisvegabor You make very good points. Thing is: how does one do when one only has 5 keys (up/down, left/right and select/enter)? Is it for the input device driver callback to know whether one is wanting to switch between objects (and then map, say, left/right to prev/next) or to navigate within one object? If that were the case then one would have to implement a state machine (or something equivalent).
On an aside: which keys would be mapped to prev/next on a 105 key keyboard? From what I read, you would use Tab (and shift tab) to simulate next (prev).
Good question. LV_INDEV_TYPE_KEYPAD for a full keyboard (e.g. normal PC keyboard) and LV_INDEV_TYPE_ENCODER for left/right/push. The 5 key keypad is somewhere in between but closer to encoder because there are no different keys for NEXT/PREV and LEFT/RIGHT. Unfortunately, there is no direct solution for this right now but seems not so difficult to extend the encoder handling to process up/down keys too. It can be added in the next version.
Thanks a lot. I just found a minor inconsistency in the documentation when it comes to encoder input devices.
in Porting I see: “By turning the encoder you can focus on the next/previous object.”
in Overview I see: “With an encoder, you should use only LV_KEY_LEFT , LV_KEY_RIGHT , and LV_KEY_ENTER .”
Does this mean: "If you use an encoder it handles movement by emulating LV_KEY_PREV/LV_KEY_NEXT and your code should handle the behaviour of LV_KEY_LEFT and LV_KEY_RIGHT" or does it mean “the encoder emulates both NEXT/PREV and RIGHT/LEFT”?
I’m not in a hurry. V6.x works for me (apart from the sdcard issue ) GC issues are quite annoying and difficult to root out. In V6 there is one in the ili9341 hybrid driver when using double buffering. It only manifests when deallocating the buffers, so one only encounters it at reboot time…
I have this exact question/problem while 5 key setup (up/down, left/right and select/enter).
Are there any examples on how to emulate the Edit and Navigate modes that LV_INDEV_TYPE_ENCODER mode provides, but while using LV_INDEV_TYPE_KEYPAD mode?
) GC issues are quite annoying and difficult to root out. In V6 there is one in the ili9341 hybrid driver when using double buffering. It only manifests when deallocating the buffers, so one only encounters it at reboot time…