# Focus Class Hierachy

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

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.

## Logical Widgets

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*

#### Fixed 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.

#### Flexible set 

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.

## Layer

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.
 
## Sublayers

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.

## Manager objects

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