For reading about this focus system you can read here https://phab.enlightenment.org/w/focus/
The current way of porting over was proposed by daveMDS:
Elm.win grabs for the keys for right left top down next prev, and just calls the move operation on the manager.
Each widget which currently handles focus needs to be ported to one of the focus types described on the wikipage.
If the currentl elm_focus.h stays as eo api after 1.18, we can migrate at any point later. The api can be adopted.
Roadmap for this work:
- Pull out efl.ui.object.focus efl.ui.focus.container from elm.widget, so we have a clean seperation (api wise) between a focus object and a container.
- Add a signal which gets emitted if the tree of widgetparents is changing, and this widget is propergated throuw the tree. This is needed for something like the following usecase. There is a box with a few children. this box is a resize object in a window. The elements will register themself in the window. Now the box gets reparented to the scroller, the scroller should emit a signal to its children that there is a new parent. Each widget should propergate them to theire sub-objects. (while working on this maybe cleanup activate/disable on_focus)
- Hook in a Efl.Ui.Manager register widgets themself in a sane way (disabled/active, can_focus, focusable children).
- Hook in a Manager in the scroller so only those elements are hooked into which are visible, also register the border elements of the scroller into the next upper manager, and use them to interact with this new ui level
- Same for Elm.win Elm.menu Elm.Hoversel (something else?)
- Start work on next/prev