Focus management improvement

[pharo-graphics]

Focus management improvement

[GlennCavarle]

It seems logical to me that an element which is not in the graph scene cannot actually requests the focus.
But, having a way to define the default focused element would be good.

[syrel]

Actually it can 🙂
Imagine a scroll list of text editors. Elements that go outside of viewport get removed from scene graph but they still can be focused and can receive keystroke events.

[syrel]

The point here is that requestFocus could just set focused to true if element is not in the scene graph. As soon as it is added to the space we check if focused is true and actually give element focus.

Check how it is done in other graphical frameworks. There users can configure visual elements first (set color, font size, focus if needed) and only then add to the scene

[GlennCavarle]

I checked how it is done in other graphical frameworks (android, jquery, Qt, Javafx, iOS UIKit).
All of them have a kind of requestFocus which has an effect only if the element is attached to the scene graph.

Specifying the element that want the focus first is another mechanism, mainly a boolean to mark the element as the first responder. But this boolean has an effect only when this element is attached to a scene graph.

An element which is not attached to a scene graph cannot be an event target and cannot be the focus owner. Simply because at this moment, you cannot know in which space it is.

I would see the basic focus specs like that:
(i checked what it is already introduced in the current version of Bloc)

• When a space is shown we have:
  • to make it the focused space
  • to request the focus for the first element that need it (would be based on mentioned boolean)
• When the focus changed we have:
• to toggle the focused space
• to dispatch blur event to the previous focused element
• to dispatch focus event to the new focused element
• When a keyboard navigation is detected, we have:
  • to find the next or previous focusable element
  • to request the focus for this element
• The focus can be changed in 3 ways:
  • mouse/touch click
  • keyboard navigation
  • programmatically (with requestFocus)

What do you think ?

[syrel]

Glenn, what you say it totally right and I agree :)
But we are talking about different things.
Of course you can not give focus to an element that is not in the space because you don't know which space. I'm saying that we need a mechanism to request focus to an element, so that only when it is added to the space it will get focus. Here is a pseudo-code example:

space := BlSpace new.
child := BlElement new.
"here goes configuration step. The problem is that we can not always know when element
is going to be added to space and to which space. We just want it to be focused once
it is added to scene graph"
child background: Color red.
child requestFocus.

space root addChild: child.   "<- child will get focus AFTER it is added to concrete space"

previous snippet should be consistent with:

space := BlSpace new.
child := BlElement new.
child background: Color red.

space root addChild: child. 
child requestFocus.   "<- child is in space already and gets focus instantly"

both examples should have the same effect => order should not influence on result.

Android does give focus to the child during adding:

check:
ViewGroup#addViewInner(View child, int index, LayoutParams params,boolean preventRequestLayout)

...
 if (child.hasFocus()) {
    requestChildFocus(child, child.findFocus());
 }
...

Also check View#requestFocusNoSearch(int direction, Rect previouslyFocusedRect) which is called from requestFocus.
It marks View as it "has" or should have focus, but it does not actually receive events.

[GlennCavarle]

(Reading the View class is so terrible... I forgot that Android was the king of int & boolean flags )

Ok, we need:

• (1) a way to actually request focus for an element attached to a scene graph
• (2) an option in element to make it potentially the default focus owner when it will be added in the scene graph (it depends on the other elements also marked as needing focus)

Currently requestFocus only does (1) and maybe we have to provide a more high-level API to handle both (1) and (2) in one way. I don't know if requestFocus is the right place (and name) to do that.

And we have to consider that:

• We need something like a focusable option
• We need probably a way to define the order of focusable elements during keyboard navigation (children order by default)

[syrel]

(Reading the View class is so terrible... I forgot that Android was the king of int & boolean flags )

Ahahah 😆

Currently requestFocus only does (1) and maybe we have to provide a more high-level API to handle both (1) and (2) in one way.

Exactly! I absolutely agree. Indeed, it would be really nice to have a uniform way to actually request focus and request request focus (sorry for calembour). I personally think that even current requestFocus with a small modification could work in both (1) and (2) cases.

[girba]

This is fixed