Find/replace overlay: improve focus/tab order #2161

[HeikoKlare]

The FindReplaceOverlay currently uses the default focus order. When tabbing through the widgets, this means that when starting from the find input field you have to tab over all the search options before coming to the replace input field. Since the most often used navigation is between the two input fields for find and replace, they should come after each other in the focus order.

This change adapts the focus order of the involved elements:

• Tab between find and replace input field
• Tab between replace input field and the tools (starting from the search tools)
• Tab between search/close and replace search tools (instead of coming from search/close tools to the replace input field)

Fixes #2161

Proposed Tab Order

Behavior

Existing tab order:

Proposed tab order:

[HeikoKlare]

@thomasritter do you agree that this proposed order/behavior is as expected?
Unfortunately, I have been thinking about a "better" solution for too long, so I am (too) late for the upcoming release. But I consider it a great improvement with respect to usability of the find/replace UI, so maybe we could still bring it into RC1.

[github-actions]

Test Results

 1 802 files   -  19   1 802 suites   - 19   1h 51m 20s ⏱️ - 6m 10s
 7 725 tests ±  0   7 496 ✅ ±  0  228 💤 ±0  1 ❌ ±0 
23 977 runs   - 359  23 235 ✅  - 353  741 💤  - 6  1 ❌ ±0 

For more details on these failures, see this check.

Results for commit 1ecc87f. ± Comparison against base commit 69f6e45.

♻️ This comment has been updated with latest results.

[Wittmaxi]

This is the hack I was hoping we wouldn't need - yet, I fear it is the only logical solution to what we want (and I agree that we want this): a smooth transition from search to replace bar.

Is there a (good) way to wrap this functionality into "Accessible Toolbar"? Maybe we could add a method to the toolbars (or to the toolbar builder) allowing them to automatically do the dirty wiring so that we just need to tell toolbars A and B that "this button[A] -> that button[b]"

[HeikoKlare]

This is the hack I was hoping we wouldn't need - yet, I fear it is the only logical solution to what we want (and I agree that we want this): a smooth transition from search to replace bar.

I agree that the solution is not that nice, but I would not call it a hack either. I do not see any option than a custom handling of tab events, as a custom definition leading to an automated handling of tab event is not allowed across composite border, at least on Windows (if I am not mistaken).

Is there a (good) way to wrap this functionality into "Accessible Toolbar"? Maybe we could add a method to the toolbars (or to the toolbar builder) allowing them to automatically do the dirty wiring so that we just need to tell toolbars A and B that "this button[A] -> that button[b]"

We could wrap the establishment of each wiring into a method, but without quite some additional effort that would increase the number of listeners involved. Wrapping this into the accessible toolbar is not possible, because there are other elements than accessible toolbar involved (like the text field).

[Wittmaxi]

We could wrap the establishment of each wiring into a method, but without quite some additional effort that would increase the number of listeners involved. Wrapping this into the accessible toolbar is not possible, because there are other elements than accessible toolbar involved (like the text field).

I don't believe it would be worth it. One would expect that there is an inbuilt way to specify tab orders which do not respect the object-hierarchy (hence why I called this a hack when in reality you are right: this is a canonical solution)