QtVcp calculator physical keyboard support, quality of life things

[tangentaudio]

Provides much-enhanced support for physical keypad entry in the Calculator dialog as well as some other quality-of-life improvements.

• subclassed QLineEdit to add a key event handler that traps operator keys as well as a few other keys to make keypad support possible
• adds a validator to the QLineEdit so it only accepts standard notation numbers, this should remove the case where bogus data would cause a GUI crash (see a69e45a)
• a few "special keys" to allow keyboard keys to move to previous/next fields when e.g. editing the tool offset table, or to cancel out of dialog.
• extends the acceptOnReturnKey preferences option to send a "Apply Next" instead when it's available, for multi-field entries like the tool offset table
• robust handling of normal numeric keypad keys to perform calculations and enter values without having to click buttons in the dialog. not all calculator functions are tied to keyboard keys, so for more advanced calculations the dialog is still needed.
• adds a new label that shows the contents of the memory, presented below the line edit
• adds a new label that shows the currently pending operator to the left of the line edit
• fixes a couple of other small things per discussion with @snowgoer540, see a69e45a#commitcomment-153191294
• updated documentation

[snowgoer540]

Man these are some much needed improvements!

I do see a few issues:

1. Maybe unintended, but if you do say 5 then + then 5, hit enter and you get 10. If you press + more than once, it will add what is displayed to itself. So 10, 20, 40, 80, 160, etc.
2. Along the same line as 1, on most calculators it would keep repeating the last calculation if you keep hitting equals. For example, 5+5 (equals) 10 (equals) 15 (equals) 20. Is this possible to implement?
3. CLR ALL does not clear the operator to the left of the display
4. If you divide by 0, you get ####. Perhaps this should be Error? Also, if you click any other operator key, or equals after than, you get the following crash:

Traceback (most recent call last):
  File "/home/plasma/linuxcnc-dev/lib/python/qtvcp/widgets/calculator.py", line 335, in additiveOperatorClicked
    operand = float(self.display.text())
              ^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: could not convert string to float: '####'

5. I am sure it's something to do with how the dialog is called, but you cant clear the error (click Abort). Maybe there is nothing that can be done about this.
6. Not to be pedantic, but there is trailing whitespace at lines 214 and 236 of calculator.py
7. I am still a bit unsure what "Apply" does?

[tangentaudio]

1 - unintended by me, but I believe the original calculator had that behavior before. I tried a couple of things and haven't fixed this yet. It may be intentional by the original author (@c-morley ?)
2 - should be possible, but I'll need to look at it, likely in conjunction with 1
3 - should be fixed, as well as a few other circumstances where this might have happened. there may be more.
4 - fixed, this was old behavior i missed. it now highlights the background red on error, which will clear on the next digit or key entered. I hardcoded the error color for now, but will figure out if I can make it a state that can be used in a stylesheet.
5 - When I've had it crash in QtVcp code, generally it seems to not be recoverable and have to click "Abort" in the debug dump window that pops up.
6 - Hopefully cleaned up. I'm not sure why VSCode keeps leaving trailing turds like that, or doesn't just clean them up on file save automatically.
7 - I'm not sure how you're calling it, but I'm primarily using this as a way to enter the value for fields and not just a basic calculator. I made a new OperatorLineValue widget recently which is for entering a single value (e.g. RPM). It pops up the calculator when you click the widget. If you type in something in the calculator and "Apply," the plumbing in the code will make it populate the value of the widget. If you "cancel," it won't apply and will just close the calculator. You can also use this in the tool table editor to edit values, as well as the global offsets table. I imagine this might be an unusual thing in QtPlasmac. If you're trying to just use it as a calculator and not have it populate anything, I guess those buttons don't make much sense, so maybe we need a way to make it just come up with a "Close" button.

Thank you for the testing and feedback, by the way! Really helps make the code better in the end.

[snowgoer540]

1 - unintended by me, but I believe the original calculator had that behavior before. I tried a couple of things and haven't fixed this yet. It may be intentional by the original author (@c-morley ?)
2 - should be possible, but I'll need to look at it, likely in conjunction with 1

Definitely makes sense to look at them together.

3 - should be fixed, as well as a few other circumstances where this might have happened. there may be more.

Looks good, I wonder though, should CLR remove the pressed Operator? For example, if you press (or click) 5 +, there is no way to take back the +. In fact, if you press 5 + and then click say "x", it will multiply 5 x 5. Which I don't this is intended behavior... But this likely ties into 1 and 2 above.

4 - fixed, this was old behavior i missed. it now highlights the background red on error, which will clear on the next digit or key entered. I hardcoded the error color for now, but will figure out if I can make it a state that can be used in a stylesheet.

Looks great, thank you!

5 - When I've had it crash in QtVcp code, generally it seems to not be recoverable and have to click "Abort" in the debug dump window that pops up.

I see now that it's because I was calling it as a dialog, I copied how QtDragonHD calls it, because I figured it was most like how it was intended to be used. If I call it stand alone, then I can get to Abort during crashes.

6 - Hopefully cleaned up. I'm not sure why VSCode keeps leaving trailing turds like that, or doesn't just clean them up on file save automatically.

They're still there ... I use an extension called "Trailing Whitespace" by jkiviluoto which seems to work OK. I turned off trim on save though, as there are times when I don't want to change anything other than the line I'm editing and there is a ton of trailing white space. Anyways, it has the option and it works :)

7 - I'm not sure how you're calling it, but I'm primarily using this as a way to enter the value for fields and not just a basic calculator. I made a new OperatorLineValue widget recently which is for entering a single value (e.g. RPM). It pops up the calculator when you click the widget. If you type in something in the calculator and "Apply," the plumbing in the code will make it populate the value of the widget. If you "cancel," it won't apply and will just close the calculator. You can also use this in the tool table editor to edit values, as well as the global offsets table. I imagine this might be an unusual thing in QtPlasmac. If you're trying to just use it as a calculator and not have it populate anything, I guess those buttons don't make much sense, so maybe we need a way to make it just come up with a "Close" button.

Certainly makes sense! I agree with the Close button when used otherwise if it's possible.

Thank you for the testing and feedback, by the way! Really helps make the code better in the end.

You bet, I enjoy "breaking" code :)

[tangentaudio]

I made a quick screencap video of how the Apply/Cancel and Apply-Next/Back functions work.

https://www.youtube.com/watch?v=BNRqiMuVlNo

[snowgoer540]

I made a quick screencap video of how the Apply/Cancel and Apply-Next/Back functions work.

Thank you that is helpful!

[tangentaudio]

I discovered this thing is almost a direct PyQt port of a Qt C++ example. https://code.qt.io/cgit/qt/qtbase.git/tree/examples/widgets/widgets/calculator?h=5.5

I built the C++ example to test it and almost all of the quirks stem from that implementation. Trying to get proper behavior with that starting point is proving to be a mild nightmare. I can get one set of behaviors fixed but it tends to break another in the process.

It's going to need a re-think and reimplementation, in my opinion, and I'm not sure I have the motivation for that right now. I will try to see if I can get it "good enough for now" with some known bugs, so the other work I did is at least not a waste.