Toolkit Focus

What is Focus

The attribute “focused” on a widget means that all none-mouse related events will be emitted at first on this widget. After that the not-taken events will be emitted down the widget tree.

There are 3 (and a half) possibilitys why a widget could get focus:

• Click on the widget. For the case the config of elementary is set to the policy ELM_FOCUS_MOVE_POLICY_CLICK and someone clicks on the widget, the widget will get focus.
• Mouse enters the widget. The widget will get focus when the mouse entered the coordinates of the widget. Also only happens if the config is set to the policy ELM_FOCUS_MOVE_POLICY_IN
• There was a key event which wanted to move the focus. “Moving the focus” can be done into 6 directions. Right, Left, Top, Down, Next, and Previous. Right, Left, Down, Top will move the focus to a widget which position is relative to the current focused widget on the right, left, down or top -side. The directions next and privious are more bound to the workflow of a user on the current set of widgets. So for example, you are having a formular where you can enter new clients for a adressbook, you will see a screen with input fields for name, last name, adress, the input fields are not aligned like a table, so moving focus down is not going to work. Using the mouse all the time to get focus to the next text field sucks. So moving the focus to the next possible widget which is needed to continue the workflow is more what we want. This is what the directions are describing.
• The last reason for getting focus is pretty trivial, when the ui is created and the window is shown, the focus has to start somewhere, if not users without a mouse are going to have a problem. So this is just a half reason, because some widget just need to get focus in the beginning.

What widgets should be focusable

In general widgets which are reacting on keyboard input should be focusable. But which widgets are really reacting on keyboard input.
Let me show you an example, a entry needs keyboard input to display the typed characters. Same for a scroller, since it wants to react on the page down/page up keys. So lets say we are having a entry as content of a scroller, and the scroller has the focus. Looking at the highlight it would look like the entry has the focus, since the scroller pratically consits out of the entry, but pressing “a-b-c-d-e-f-g-h-i-j-k” will not result in some displayed characters in the entry, since the keyboard input will be go to the scroller. We see this is BAD, the scroller should just react on keyboard input which is not used by the content.

With the assumation that content is focusable we can say that the scroller is reacting passiv on keyboardinput.

Now the usecase where the content is not focusable, for example a big image in a scroller. This would mean there is no possibility on using the scroller with keyboard input, Again BAAD! So we have some kind of hybrid here. For the case the content is focusable, its a passiv keyboard user, for the case the content is not focusable it is a active keyboard user.

To summerize:
We have four kinds of widgets, no, active, passive and hybrid keyboard using widgets.

Examples:

• Entry is a active-type widget.
• Scroller is hybrid.
• Checkbox is also a active-type widget, the logic of the widget react for example on enter and spacebar to toogle its state.
• Containers like Box Table or Grid are just containers they dont deal with keyboardinput, so they are no-type