Page MenuHomePhabricator
Create Task
Maniphest T3670

Migrating to a new focus system
Closed, ResolvedPublic
Actions

Description

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

You can find a prove of concept https://git.enlightenment.org/core/efl.git/log/?h=devs/bu5hm4n/focus2. (test it and report if you are happy how it performce)

Related Objects

bu5hm4n created this task.May 22 2016, 7:59 AM
bu5hm4n updated the task description. (Show Details)May 22 2016, 9:16 AM
bu5hm4n updated the task description. (Show Details)May 29 2016, 2:27 AM
bu5hm4n updated the task description. (Show Details)May 29 2016, 2:34 AM
raster added a subscriber: raster.May 31 2016, 6:48 PM

"Elm.win grabs for the keys for right left top down next prev"

ummm... what do you do with an entry? it needs at least the arrow keys to function likely also next/prev too (tab/shift-tab) - you can't just grab them universally and steal them away.

as for the "parent change" signal... shouldn't this work in reverse? you propagate up the tree to the parent window so a focus manager can listen there for changes? so when a child changes its parent it just propagates to their the old parent or the new - or actually both, first a "del child" event to the old parent then a "add child" to the new parent? then the focus manager just listens to the top level knowing of all the child changes going on?

this will then not require registering as the focus manager can see all just watching toplevel (window)? you can then nest managers at different levels of the tree too as long as a parent manager knows how to deal with a child manager...

but then this begins to look like the current focus system - just every widget is a focus manager of its own. :)

bu5hm4n added a comment.May 31 2016, 11:53 PM
In T3670#54534, @raster wrote:

"Elm.win grabs for the keys for right left top down next prev"

ummm... what do you do with an entry? it needs at least the arrow keys to function likely also next/prev too (tab/shift-tab) - you can't just grab them universally and steal them away.

Hehe, i learned my lessen regarding this. It will just stay until all parts which need to be migrated over are migrated .... After That the normal event flow will handle those things.

as for the "parent change" signal... shouldn't this work in reverse? you propagate up the tree to the parent window so a focus manager can listen there for changes? so when a child changes its parent it just propagates to their the old parent or the new - or actually both, first a "del child" event to the old parent then a "add child" to the new parent? then the focus manager just listens to the top level knowing of all the child changes going on?

Mhmm no, this is by intend. The children are registering themselfs in the manager object. So when a child changes it unregisters in the old and registers in the new manager. The reason why i am doing this is to avoid a shitload of logic in the manager which can be done elsewhere. And from my POV this is way easier in the elm.widget code to do than in the manager.

this will then not require registering as the focus manager can see all just watching toplevel (window)? you can then nest managers at different levels of the tree too as long as a parent manager knows how to deal with a child manager...

This is exactly what I dont want to have. The widgets which wants to be focused just have to register themself to do so. I dont want that the parten manager must be the own knowing how to handle childmanager. If there is a childmanager this one will just be set as redirect, everthing else is handled in the implementation of the childmanager (and this is where it should be IMO).

but then this begins to look like the current focus system - just every widget is a focus manager of its own. :)

And this is exactly where i want to go away from. And i dont see where it beginns to look like the current focus system. The is a central graph where you can start debugging stuff and getting information from (currently not there). There is currently nothing like a inverse operation to the one you did before. So we are not on the road to the current focus system.

stefan_schmidt triaged this task as Normal priority.Feb 10 2017, 6:32 AM
subodh6129 added a comment.Jun 1 2018, 5:27 AM

please close if its done

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:54 AM
q66 edited projects, added efl: input, efl: widgets; removed Restricted Project.Jun 11 2018, 7:31 AM
Herald closed this task as Resolved. · View Herald TranscriptJan 15 2019, 10:05 AM

Ho Ho Ho! This issue was fixed by Santa!