Free42 NSTK ENTER behavior

[Thomas Okken]

I'm not saying it would, but it might help if the request were accompanied by one or two actual examples of how ENTER is "more efficient" than DUP.

If it weren't for backward compatibility, I'd personally prefer the [ENTER] key to perform "end number entry if it is active, DUP otherwise" in both modes. ENTER requires one fewer keystroke if you want to type a number and then fill the stack with it, but DUP requires one fewer keystroke if you want to duplicate the number in X in order to start a new calculation with it, while keeping the old number as well, and that is something I do all the time.

Which mapping is better is a matter of taste and usage patterns. I'm sure a good case, apart from compatibility, could be made for the old mapping, although I haven't seen it here. But there is also the "I don't need more feature requests" angle: if I were to satisfy every request for UI customizability, the Preferences screen would have dozens of additional settings, which would have taken a lot of effort to implement. Even if the impact of a new setting on the simulator core is just to add a check for some flag somewhere, the impact on the simulator shell is to add a check box, maybe change the dialog's layout or placement, test the new layout to make sure there are no unforeseen side effects, test that the change of the state file layout is handled correctly, and then, repeat the whole dance four more times because the user interfaces for Android, iOS, Windows, MacOS, and Linux are all different and share almost no code.

If the UI were based on Qt, I'm sure a lot of the hassle would go away, but that would be a big project on its own, and I am sure it wouldn't eliminate platform-specific issues completely. I've done cross-platform UIs in Java, which has a very mature UI toolkit, and still there were OS-specific issues to deal with.

Adding preferences settings could also be made easier by implementing something like the about:config view in Firefox. Not visually attractive, but it gets the job done, and designed for programmers, enabling them to add settings by just writing a couple of lines of code linking a variable to a UI widget. But implementing that view would be a big effort too.

In short, the unsatisfactory but workable compromise is for me to be guided by my own ideas in these matters, and just say no to user requests most of the time, not because I don't sympathize but because life is too short. I do make exceptions but unless I agree with a request from the outset, I tend to be very hard to convince. The only occasions I specifically remember implementing preferences settings that I didn't personally care about were for turning off auto-repeat (because of a user with arthritic hands who simply couldn't tap keys quickly and so was getting unwanted auto-repeating all the time) and haptic feedback (which for some people is a hard requirement while for me it is something I hate with a fiery passion).

I hope that clears things up. No hard feelings!