This article should give a overview which focus classes are existing.
First of all, there are different types of widgets:
Focusable widgets (Something like Elm.Button). The widget can get focus.
Logical widgets, they are having a set of other widgets, which are named as children. A logical widget cannot get focus on itself, but its children can get focus, as long as they are focusable, or one of those childrens can get focus (Needs improvement)
Layer widgets, when they get visible they create a new layer of UI, which is pausing and overriding the previous layer that was visible. The focus is setted into a widget at this layer
Sublayer widgets, scrollable area in a UI is a layer that is connected to the rest of the UI at its border elements. That is what we call sublayer here.
Elm.Widget is implementing a mechanism to ensure that its registered for the case the following properties are given.
visible is set
can_focus is set
tree_unfocusable is not ist
tree_disabled is not set
The top most widget is a Efl.Ui.Win
It also ensures that the widget parent is at least registered as logical element.
After the logic has figured out how this widget should be registered, it calls focus_state_apply with the confguration is figured as most usefull.
Efl.Ui.Focus.Composition is a helper class for dealing with logical widgets.
You can use it in two modes, lets call them fixed set and flexible set
You can just set the set of children with composition_elements_set, you need to keep the list updated each time the set for you changes, so the implementation has always the fixed set which it will hand to the manager. Be aware that calling composition_elements_set too often in a short time may harm your performance.
This is meant for api usages where you have many set changes, and dont want to call composition_elements_set each time the set changes. You can take gengrid items as a reallife example.
You can use this mode by calling dirty each time you know that your set has changed, if the composition then needs the exact information then it will call
prepare. In the prepare call you need to call composition_elements to set the exact order of children your set is currently representing. Prepare will only be called after that again, if dirty was called in the meantime.
For supporting a layer widget you can inherit from Efl.Ui.Focus.Layer.
The mixin inherits from a the focus manager interface, the inheritor from this mixin has to present a Efl.Ui.Focus.Manager implementation.
The implementation of the mixin can take care of setting the focus manager as redirect once the object gets visible. It can also be set to cycling the popup in the new layer or hiding the popup once focus moves to a widget outside that layer.
For sublayers there is Efl.Ui.Focus.Manager.Sub. The inheritor of that widget has to implement the Efl.Ui.Focus.User and Efl.Ui.Focus.Object interface. Once the
EFL_UI_FOCUS_USER_EVENT_MANAGER_CHANGED event is emitted, the implementation will take care of registering the border_elements of the manager itself in the manager where we have changed to.
Efl.Ui.Focus.Manager is just a interface. The Standard implementation of the Interface is Efl.Ui.Focus.Manager.Calc.
The interface itself only offers navigation and information getters, adding & removing widgets is not in the interface but in the object itself. Reason for that is that you can implement your own adding logic, that works better with the data structures you are working with.