Lv_group => tabindex

Feature request
1

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().

Missed things:

  • 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.

2

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.

3

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.

4

How do you mean it?

There are 2 things here:

  1. E.g. lv_list should have a “subgroup” for its buttons.
  2. E.g. a slider has no children. If you use an encoder you need to navigate to the slider (navigation mode) and switch to edit mode to change the value.

The second part can be reconsidered as well.

5

Could you clarify? It’s not a problem to subscribe [not existing now] keyboard events, for increment/decrement value.

Navigaion means “way to change focus” and so on. Dedicated control does no change focus. For example, some PC keyboars have buttons for volume control.

Not sure his neeed. Web works without this somehow. What use case do you mean?

value edit mode != subgroup mode. I see no principal problems here with encoder/joystick.

6

So you want to make an object see if you press e.g. “Volume up” (independent arbitrary key)?

Seemingly adding all buttons to the “group” could work as well.

One more conceptual question: Imagine there is a tab view with 2 tabs. What to do when an object on the inactive tab is selected?

  1. change tab
  2. do not focus that obejct
7

Yes. In more general form - direct control knob should have direct binding. That’s out of “group” (navigation via focus change) scope.

Looks like not good idea, more close to undefined behaviour. Answer for UB is “do anything you wish”.

8

Do you mean #1 or #2 is not a good idea?

9

I mean, it’s not good idea to try set focus on hidden object (except in scroll-able area).

1 Like