Provide public API for manipulating focus of items in a collection widget about fyne HOT 6 OPEN

Seems related to #4472 but that issue is for List

It almost reads as the inverse. I think OP here is wanting to control focus of child items using keys, the 4472 is what I thought made sense when it sounded like the focus wasn't following selection.

I'd never thought of this as a use-case but it seems like a pretty reasonable thing that devs might want to do.

I don't think we have exposed any focus APIs before so will require some thought to make sure we get it right.

from fyne.

I'm not sure the problem is quite as stated. Should the item that has most recently been selected not become the focused item? Then this would be fixed with no new APIs

from fyne.

I see your point, but...

When navigating between items using the arrow keys, the items are not selected, they merely become currentFocus. I would expect my additional keyboard navigation ("jump to next item starting with letter X" or even "jump to next item with prefix XYZ") to behave similarly. If my keyboard navigation has to call Select(uid) in order to force the currentFocus to change, this would trigger OnSelected(), which is different from the way that the arrow keys work now.

As an example, if the current node has children A, B, C, D, and the item in focus is A, then hitting down arrow 3 times puts the focus at D. In my scenario typing "C" and then down arrow once would also end up with the focus at D.

You could then select D by typing KeySpace.

If I have to change focus by calling Select(), then C and D would both be selected in turn, which may not be what I want (OnSelect may perform some action with a side-effect, for example.)

from fyne.

Seems related to #4472 but that issue is for List

from fyne.

Oh, and while we are discussing focus, selection, and the Tree and List APIs.

1. Clicking the tree (to expand/close or select) should set the focus to the item interacted with. If I click on an item in the tree I still have to hit "tab" to move the focus to the tree in order to navigate up/down using the keyboard.

Lists behave better: Clicking on a list item sets the focus to that item, and the keyboard works right away. (But sometimes the highlight does not appear properly, leading to confusion about where the focus currently is. Having trouble reproducing this.)

2. I would like to be able to set a "double-click" handler on the list and tree. There is an OnSelect for single click, but no OnDoubleClick (or maybe OnAction, if we want to be semantic about it. I'm not clear on how Select vs. Action would work on mobile.)

3. The List widget "remembers" the currently selected and highlighted item, even if the list changes contents.

e.g. list contains A B C, with B currently selected. List changes to X Y. Y is marked as selected because it is ID#1 even though it's not the same item at all.
If I then switch the list back to contain A B C, B is marked.
If I select C then switch the contents to X Y, nothing is marked. But if I hit up arrow Y is highlighted, because the focus moved from ID#2 (which doesn't exist!) to ID#1.

IMHO the select and focus should be cleared when the list changes contents, but since there is no API for telling the list that the contents have changed, or for setting the focus, and since UnSelect doesn't touch the focus, there is no way to do this.

The state machine for currentFocus, tap/click, keyboard arrows, spacebar, FocusGained/Lost, Select/UnSelect is somewhat complicated. In my copious spare time I'll try to diagram it (current vs. desired).

Let me know if any of these points should be separate issues.

from fyne.

Thanks for your thoughts.

1. I think we resolved it in List and forgot tree. There is an ongoing discussion about what focus should do on tap, see #4376
2. Double clicking an item in a list can be done in user code. Either add that to the widget inside each item or extend the collection widget - whichever makes sense for the desired interaction.
3. We should not reset focus and selection if data changes. The data may be only a slight revision to a single row. Or it may turn out to be no actual change but a developer initiated refresh just in case. If you want to remove the selection in your own code then call UnselectAll.

I don't think there is anything in your list that calls for a new issue - it is either captured already or not an issue from what I can see?

from fyne.