Unfocus using escape key

[Jacalz]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

We want to make the applications as usable as possible with just a keyboard. This has ergonomic and usability benefits and so on. However, right now we do not quite allow a widget to easily be unfocused without using a mouse. The next best thing with a keyboard is currently just to focus the next item.

Related to #1515

Is it possible to construct a solution with the existing API?

Yes, it should be possible. It might require something similar to the AcceptTabs interface that we have now for letting widgets get tab keys.

Describe the solution you'd like to see.

I would like to have the focus manager handle unfocus of widgets when pressing the escape key. At the same time, I think it would be beneficial if it also closed dialogs (basically an “unfocus” of a dialog) when pressing the escape key as that would make applications even more usable.

As stated above, this might require an API to allow widgets to receive the escape key if they want to.

Cc @tilo

[andydotxyz]

I think the scope of this may want to be smaller than indicated.
In testing some other systems it seems that only text input fields (and not all of them) un-focus when Escape is tapped. Buttons, radios etc seem not to.
So could we just code it in to the Entry widget?

[dweymouth]

I agree with @Jacalz that escape should unfocus everything, or at least be configurable by the app to do so. Having just added some keyboard controls to my app, including some typedKey shortcuts at the window.Canvas level, being able to unfocus with escape would be very useful.

[andydotxyz]

or at least be configurable by the app to do so

We prefer not adding lots of new APIs for all possible variations of a widget. It is already possible to use escape to unfocus your widget if you want to.
If we want it to remove focus on all widgets then we can, though this is not what other toolkits do. We could have it escape from any text entry widgets, though some don't do this either.

In thinking about the initial request it was for better keyboard usability. At the root of it I am not sure that unsetting focus as a generic concept adds to usability because then you have lost keyboard context. Is it perhaps relating to getting out of multi-line text where the tab key is swallowed, and so you have to exit focus to keep moving with Tab/Shift-Tab @Jacalz?

[dweymouth]

Well for one, it's not possible to "focus the main window", i.e. unfocus all individual widgets, using the tab key. So if there are key events bound to the window canvas itself, you currently have to use the mouse to click on something and reset the focus back to nil/the window. Maybe this isn't that much of a usability harm since a lot of other toolkits already don't have this behavior, so users may be used to having to use the mouse to unfocus everything.

[Jacalz]

Sorry for my late reply. I agree with @dweymouth. Only unfocusing inside Entry would not work for applications that don't have any entry within the current view.

[Jacalz]

My main use case for it is to add global shortcuts for switching between tabs (ctrl+tab and ctrl+num). If it only was possible to unfocus in an Entry, it would not be possible to use the shortcuts when within some tabs that do not contain Entry widgets.

[dweymouth]

I played around with some other UIs (browsers, OS file manager, etc) and it does seem that using escape to unfocus everything is somewhat uncommon... but what would be needed for keyboard usability would be a way for key events to bubble up to the window if the focused widget didn't "do" anything with them. (e.g. in Firefox at least, pressing the arrow keys still scrolls the page if the focused UI element doesn't do anything with arrow keys). It seems like this would be a harder change to add to Fyne though, since it seems it would require focused widgets to indicate somehow whether each key event it receives while focused was actually handled, or if it should bubble up to the window.

What are your thoughts @Jacalz ?

[andydotxyz]

My main use case for it is to add global shortcuts for switching between tabs (ctrl+tab and ctrl+num). If it only was possible to unfocus in an Entry, it would not be possible to use the shortcuts when within some tabs that do not contain Entry widgets.

As far as I am aware focus does not steal shortcuts... only other shorcuttable items do - so we really need to be clear on the definition here... is it a focus issue or a shortcuts issue.

[andydotxyz]

It seems like this would be a harder change to add to Fyne though, since it seems it would require focused widgets to indicate somehow whether each key event it receives while focused was actually handled, or if it should bubble up to the window.

Before looking at how hard a solution is I think we have to really nail down the problem we are solving. After there is clarity there the right solution may become clear and then we aim to fix it irrespective of complexity...

[dweymouth]

I think there are at least two things here:

1. Shortcuts - it seems that widgets that have shortcuts steal all shortcuts from the global window when they have focus, at least widget.Entry does in Fyne 2.2.4. Is this intended, or should a shortcuttable item only steal the shortcuts it specifically registered? I think the latter would be reasonable (and would solve Jacalz's use case)
2. Focus - focused widgets receive all typedKey/rune events and prevent any from reaching the window canvas. This is reasonable behavior but harms keyboard usability unless there is either:
   2a. a way to unfocus all widgets with the keyboard, OR
   2b. a way for a focused widget to allow key events to bubble up to the window if it can't meaningfully respond to them (this seems to be the common way other UIs work, e.g web browser allowing arrow keys to scroll the page if the focused UI item doesn't use arrow keys)

[andydotxyz]

1. Seems like a good suggestion. 2. Is a little closer to describing workarounds. "Escaping" a focus so that your key can be sent elsewhere does not sound like an expected user interaction - with the exception of when your "whole focus" is in the widget I.e. Entry.

The idea of bubbling up events has been discussed before but it hugely adds complexity to developer code and has been avoided. In the case of shortcuts it may indeed make sense to push "up" those that are not registered on the current widget.

However the idea of keys not necessarily going to the input focused is less clear yes web browsers do it, but I don't think that is coded into the scroller I think the app / implementation handles it because it knows the domain. For example up in a web scroll is not the same as a list scroll or a table context. A generic solution as described isn't capable of that nuance, but coding it in the app is. This is why all our widgets are capable of being extended so you can add behaviours like this.

[Jacalz]

Sorry for the late reply. This thread got stuck in the bottom of my email inbox.

The problem that made me open this suggestion was indeed to allow tab changing commends to happen easier. However, I have though some more about this and also analysed more about how I use this feature in other apps.

I see this a bit like an accessibility help and improvement for making keyboard navigation more ergonomic. Navigating using only the keyboard in large/complex user interfaces can be tricky. If you are somewhere in the middle (or just not at the top of the ui), it will take a lot of presses of tab to get to the desired item. Using escape to unfocus plus just a few tab presses, makes it very ergonomic and fast to get to the desired spot.

I use this a lot in various applications on my system. Most often in the file browser but also in a few other places.

[andydotxyz]

Good point.
I wonder - should we do a middle ground of not making at the driver level but have all our standard widgets that accept focus add Escape to remove it?
Kindof thinking out loud here sorry.

[Jacalz]

Hmm. That's a good question. My opinion is that it would be best to do it at a driver level and have an opt-out like with tabs. Otherwise every custom widget will have to hook it up and that might lead to inconsistency for users expecting escape to unfocus.

[dweymouth]

Is this still relevant? From testing around with some other UIs it seems that using escape to unfocus as a default behavior is actually fairly uncommon. I think it could possibly be handled in Entry as a special case since entry accepts tabs and therefore you can't move focus to the next widget without having escape to unfocus it.

[Jacalz]

I still think it is very much relevant. At least for Entry and any other widgets that accepts the tab key and thus doesn't allow you to unfocus without using the mouse. I'd consider that an accessibility problem for anyone that has issues using the mouse.

[Jacalz]

I would not be against adding it to all widgets though with support for disabling it on a widget label. Doing it on a driver label and adding something similar to the interface we have for accepting tab or not.