Currently user should care too much about groups, and unwanted tight coupling with driver exists (need driver pointer to update group change). I suggest use web approach, where “participation in grouping” is defined by tabindex and group is calculated automatically from layout.
User will see 3 simple methods: lv_focus(*lv_obj_t), lv_focus_next(), lv_focus_prev().
lvgl has no keyboard-like [input device] evens layer (already discussed, when i had to hack missed auto-repeat). Currently those are mocked via fake buttons, but that’s too primitive (and not beautiful).
Need to decide how to prohibit next/prev for end/start of lists. I think with can be done via custom event handlers (prohibit event propagation), to avoid extra attributes in each object.
This MAY conflict with existing navigaion approach. Need to check web “accessibility” specs about keyboard navigation, and think how to re-adjust.
I did not created issue, because to many uncertain things for now. But:
This part of lvgl look suspicious (don’t reuse web accessibility rules).
Tight coupling with driver is a pain.
“Fixing” will be the notable breaking change.
May be, this can live “as is” for some time. But it worth to discuss at least. I don’t think it worth schedule for v8. But, may be, for v9 or v10.
Thanks for sharing your idea! I was also thinking about reworking groups because they are really too complicated and counter intuitive now.
I was also considering the web approach but it doesn’t have a feature I found useful: it can handle only one group. It’s fine on the web as you have only one keyboard. However, in embedded world, you can have more encoders to for each channel of an instrument.
Anyway, I agree to proximate the two approaches. Even to have a default group (usually enough) and require extra action to add other groups.
Need to verify, is this really a “group” feature (method of navigation), or direct scroll control with custom key codes. Those things are completely different.
Right now i remember only one “missed” navigation feature - “subgroup”. When user may enter subset of elements and leave back to upper level. Web has nothing similar. This can be avoided by alternate design of navigation - instead of subgroup, show new popup page with elements for that “subgroup”.
I’m not very experienced about web accessibility features. But if you will have concrete questions or cases to investigate - kick me, i’ll try to reread specs.