Add option to swap A/B buttons in Settings menu with minimal changes (fix for #2034)

[ia]

• Please check if the PR fulfills these requirements

• The changes have been tested locally
• There are no breaking changes

• What kind of change does this PR introduce?
  Add option to swap A/B buttons in Settings menu with minimal changes.

• What is the current behavior?
  In Settings menu B/back button works as next/scroll and A/front as enter/change, while to go to Settings a user must press B/back button from Home screen, therefore in the Settings menu - to keep that mental model just created in a brain of a user - the further B/back button press should mean "go in the setting further/change a setting (as enter)", while pressing A/front button should work as scroll/going back, since a user on a reflex would press front button, because physically & logically it's located as "back" button when a user in the Settings menu. At least already a few users reported, that they would like to have this feature as an option. Original bug report

• What is the new behavior (if this is a feature change)?
  There is a new option to swap A/B buttons for Settings menu.

• Other information:

  • first of all, I wanted this feature for a long time myself, in fact I think it had to be by default since the beginning due to literally physiological reasons of ergonomics & usability described above;
  • second, I really like switch/case operator, I use it everywhere I can myself (partially because it's the essence of the infinite state machine concept), but in this case I don't know how much simpler to implement this option otherwise;
  • third, basically we have a trade-off: by swapping to if/else here, we get the less invasive solution possible without a need to overwrite different parts of code all over the code base to track down presses and messing with other functions & methods, and to support all of that with a headache in the future;
  • fourth, for reasons discussed in the other pull-request, since it's logic/SettingsMenu and there is a logic for mechanics in Settings menu including buttons processing (only in the Settings menu), I guess there is no more perfect spot to implement this option;
  • @Ralim, what do you think?
  • @discip, any comments about the option itself?

[ia]

Just to make sure...

It seems I did everything right here, didn't I?

I'm talking about that fall-through towards newMode = moveToNextEntry(cxt); in case BUTTON_B_SHORT: but only if this condition above here is true, right?

I still do some manual tests & checks, but at least it seems it works just like before. :)

[ia]

Hmmm... I think there may be a way to keep nearly original switch/case block, by adding another one...

[ia]

Just to make the rationale for this option more straightforward and simple:

• when I press right button to enter the Settings menu, my brain does expect that the next press of the same right button will enter the current selected Setting submenu (i.e., "enters further") or, if a setting is selected, its value will be changed;
• when I'm in the Settings already and just want to go back, my brain does expect that if I press left button, which is physically located just like virtual "Back" button in any modern browser or file manager, I will go back (or, in case with irons, first it will scroll down and then brings me back to the previous Settings menu level).

The same logic works if a user prefers left-hand orientation, but in a reverse button order obviously.

From the code base point of view, the provided solution here for this option seems as the less invasive and the more appropriate.

[discip]

@ia

• @discip, any comments about the option itself?

Since you asked I had to answer.
Your latest comment makes perfect sense and is equally applicable to the soldering menu.
In that menu, pressing the button closest to the tip starts the soldering process, while the farthest button disables it.

However, this logic does not hold true for the navigation in the debug menu. It would be beneficial to invert that too, in order to maintain consistency throughout.

[ia]

Since you asked I had to answer.

Thank you for your time...

Your latest comment makes perfect sense

... and thank you for your support!

and is equally applicable to the soldering menu.
In that menu, pressing the button closest to the tip starts the soldering process, while the farthest button disables it.

EXACTLY!!! YES, thanks, that's exactly I was talking about all that time, and that's why I'm so supportive to solve the original bug report #2034 with this option! That's why my brain still just can't adjust to default buttons' "mappings" in the Settings menu, even after all of these years of using my iron.

However, this logic does not hold true for the navigation in the debug menu. It would be beneficial to invert that too, in order to maintain consistency throughout.

Hmm... interesting notion - I've never thought of that to be fully honest with you, because I use debug menu very rarely, i.e. way much more rarely than Settings menu, especially when I test & debug some new features and/or options.

I will check how it scrolls now and how it will be scrolled with swapped buttons.
But how, do you think, should we handle the swap?

• make it by default without any setting
  • pros: less code, easy to implement;
  • cons: users may be a bit confused;
    • cons (for cons): although since it's debug menu, I guess there is no much difference to which side a user is sliding debug menu only to get needed information;
• cover swap in debug menu using the same setting as "Swap A/B";
  • pros: reasonable in its own way
  • cons: not quite obvious connection between "Swap A/B" for Settings and for Debug

Oh, wait... is there any other menus, where there is a way to scroll something being inside of a menu? Settings and Debug only, right? If so, then how about this: we could describe it (in the moving text "tooltip" for the option) as "swap A/B buttons for natural pressing in menus"! As in settings for a touchpad in any modern OS - "natural scrolling": some users like to scroll the screen content sliding fingers upside-down, someone - down-upside. It could be like a checkbox option for touchpads. ;)

P.S. Pardon for my nerdiness, and for the fact that I dedicate too much to this, but I like usability & ergonomics made right, and I don't like inconvenient things, because when they are done objectively right & reasonable, it's just a mental pleasure to use them at work, and when they aren't done properly, this is a mental torture for a brain - just look at most of modern interfaces around us today, especially on modern web :/

[ia]

However, this logic does not hold true for the navigation in the debug menu. It would be beneficial to invert that too, in order to maintain consistency throughout.

Aha, I see how it works... when I use Debug menu rarely, I don't have any problems, so that's why I even don't remember what buttons do what there... now I see. Well, since Debug menu is displayed by long B button with sliding from up animation, it's treated by my brain as a popup window, and the fact that you can close a popup focused window with the same button, which you use to show it, is very convenient and "subconsciously logical", I guess. So I would prefer to keep it in this way.

The only one thing which I would change, though, is the direction of sliding animation for Debug menu (since we're here talking about this) - from down to up, because in general, such information as version, build, etc. is placed on the bottom of interface usually (look at Android or iOS, for example, right?). Build version/date/number is always at the bottom, so from down to up animation would create that natural familiar feeling that a user is scrolling menu down for a debug information. What do you think?

[ia]

@Ralim, could you, please, check this pull request for code review, when you have time? Thanks.

[Ralim]

Any big logic reason for flipping direction?
I dont massively care but curious?

[ia]

Any big logic reason for flipping direction?

Yeap!... I did decide to use a creative approach for this little glimpse of "usability moment", mentioned it briefly above, I hope it makes sense:
"in general, such information as version, build, etc. is placed on the bottom of interface usually (look at Android or iOS, for example, right?). Build version/date/number is always at the bottom, so from down to up animation would create that natural familiar feeling that a user is scrolling menu down for a debug information."

P.S. Thank you a lot for approving this! I already use this option as always on, and for me this is waaaay much more convenient & easy [for my brain]. 🙏