Confusing messaging about where arrow/cursor keys can go
ibex-are-goats opened this issue · comments
Note that the cursor keys will not traverse between Layouts.
Inside the standard text edit Widgets, the cursor key actions are overridden and instead they will allow you to for navigate around the editable text (or lists) as you would expect.
I see this in the documentation, but when I run experimental.py to test, the arrow keys DO allow some movement between layouts, and DO allow movement between some text widgets. This SEEMS like a bug, but since it's so obvious, I assume it is intentional somehow, and the documentation is just off.
For example, arrow keys can't traverse out of the large text field and into the small text field, but arrow keys CAN traverse back from the small text field into the large text field.
Similarly, the arrow keys can traverse from widgets on either side of the radio buttons into the radio buttons, but not traverse out of them.
And finally, the arrow keys DO allow traversing both to and from the first layout and layout2, which the documentation clearly says will not happen.
Maybe there are some options I'm missing to make these features work consistently, and the example is just weirdly made? My goal is to simply have the arrows move everywhere equally so the user doesn't need to discover the tab operation.
Sorry. I missed that line in the docs. As you have found, you can navigate between layouts with cursor keys these days.
There is some subtlety around cursor key navigation. Current function is a result of previous debates on what is typically supported in other systems and/or least surprising.
I'm open to further refinements, but wouldn't want to go back on previous decisions without good reason. Let me know if you have any ideas. Otherwise, we just need to tweak existing docs.
I'll give you my first impression without getting mixed up in past debates.
-
I expected the arrow keys to navigate everywhere.
-
When I read about the blocking of arrow keys, I expected it to be optional and configurable.
For my purpose, the blocking has no value. I'm making a simple 1-page app, and the users likely wouldn't have ever used DOS, so they have no memory of why certain widgets would block access or not. It will be assumed that when the cursor reaches the edge of a widget, it crosses over into the next widget in all cases. There will be little or no knowledge of the tab key function.
So my workaround, if I can manage it, will be to only use non-blocking widgets.
My long-term suggestion, assuming there are people who want the arrow keys locked out of certain widgets, is to implement a toggle option in each widget. Like "lock" defaults to off, but you can turn it on per widget. I find the "sometimes cursor enters widget, never leaves it" behavior extra confusing, so I assume the people who want that would want to control it too, so there would be two separate lock options: both "lock-in" cursor, and "lock-out" cursor.
I'm testing a variety of GUI frameworks, and I'm settling on asciimatics because it's mature and well-maintained, and cross-platform, and is manageable for me as a novice programmer.
Hope that helps! So, when I get back to coding, I'm going to attempt to build a GUI with ONLY single text boxes, check boxes, and buttons, because they all seem to allow arrow navigation.
To be fair, I compared asciimatics to a standard web form, which is just about what every modern user should expect to get these days...
You can find a simple form here (https://getbootstrap.com/docs/4.0/components/forms/#form-controls). As you can see, the cursor keys do not allow you to navigate in/out of any of those input widgets. Instead you have to use the mouse or the tab key to move on to the next one.
Asciimatics has the same support. In fact, it has gone one step better by allowing obvious transitions to other widgets that you get on your normal web forms. When we looked at #60, whether we stopped or not came down to what would genuinely help users when editing/filling in forms. The fundamental logic that felt best was:
- You generally want the keys to have the "expected effect" at the scope of the widget - i.e. cursor keys should traverse text inside a multiline edit.
- Where there is no obvious "expected effect", the navigation can be scoped at the level of the Frame - i.e. it makes sense to allow cursor keys to move between simple inputs (e.g. buttons).
So what to do when they clash? Is it better to allow users to whizz through the entire form holding down the down key, or allow them to get to the bottom of the multiline text input when they hit one? We thought the latter was best for how people usually bash cursor keys (e.g. holding down until they hit the end) when editing text.
It is possible to make this optional, though. I'd accept an MR if you wanted to make that change.
Honestly I've never used a keyboard for a website form. I was thinking only of duplicating the DOS apps I grew up with, or like a motherboard BIOS, where you navigate with arrow keys and the enter button.
I definitely agree that the arrow keys should move through text, and then move to the next widget when the text runs out.
I'm learning Python for the first time this week, so I doubt I will know how to contribute a MR ;) BUT I'm happy to lend english language support ;)
For now, I'm learning to build a GUI with the basic widgets: Text, CheckBox, and Button, and these support only-arrow navigation, so I don't need the radio or box widgets urgently yet. Still new here though. Thank you for all your work over the years :)
I've fixed up the docs now. Still happy to take an MR for the option to tweak navigation at some point, but won't be doing it myself. Closing this docs issue now.