Power Supply Issues
Here a few issues I've come across using the Power supply controls. There may be more coming as I use the software.
Power supply:
- When hovering over the entry widget the mouse wheel should increment / decrement based on the position of the cursor in the entry field. I.E. if the cursor is next to the 1’s digit step by 1, if next to the 0.1’s digit step by 100mV, if next to the 0.01’s digit step by 10mV.
- The word in the “enable” button should change to “disable” when the supply is on as well as change color, because the function of the button has changed.
Doug:
I think the first issue will be impossible to do on a touch enabled device, but would be useful for a traditional user input devices.
It's more general purpose than just the power supply - it's a general purpose text input / widget thing. You just want to click on the widget (so the widget becomes "active"), hover the pointer overtop a number column (ones, tens, hundreds, or thousands) and use the scrollwheel to increment or decrement the value?
Does that describe things properly?
I would need to let Dan or Paul comment. It might be difficult to implement due to cross platform / font issues.
I split issue 2 into its own issues in #7
Yes, I get the point that it might be hard to get the current cursor position to determine the amount to increment but I've seen software that does this. Can't remember where right off.
I figured out how to do this in Python using 17 lines of code so it should be doable in QT.
I'm adding this feature to the next version of ALICE that goes out.
You are right though, the mouse wheel is not always supported the same across different OS. Even if only functional in Windows still nice to have.
Doug
The following is an input widget prototype that handles the requirements mentioned in issue 1.

This is how I think it should work:
- you click on the widget value. At this point the regular edit cursor appears. The orange underline will move where the cursor moves.
- now you can press up/down keyboard buttons or scroll up/down to change value.
- or you can press on the of up/down buttons on the left of the control at which point the edit cursor will disappear (since the label lost focus to the up/down buttons) but the orange underline still remains wherever the edit cursor was last left by the user.
Once touchscreen devices it might be difficult to use gestures to scroll up/down and the up/down keyboard buttons might no be available. In this case the Plus and Minus buttons ca be used instead, on both desktop and touchscreen devices. One downside of using the Plus and Minus buttons this way is that when you enter a new value using a keyboard, the last position of the orange underline will be at the end. From this point on every click on the Plus or Minus buttons will change the 0.01 digit.
That looks good to me.
The addition would be limit handling.
- if the value is at "9", and is incremented, the value increments (and carries), and the orange underline stays on the same digit/location.
- if the value is at "0", and is decremented, a carry occurs, if the carry succeeds, then the value turns to "9", and the orange underline says on the same digit/location. If the carry fails (there isnt anything to carry from), the value stays at 0, the orange underline moves over, and the next value is decremented.
If units change, the orange underline value follows the same value. For example if it is set to 0.823 volts, and the underline is under the "8" value, and the units are changed to milliVolts, (823 mV), the orange underline stays on the "8" char.
Does that make sense?
I think what is proposed is good. The handling of the "carry" that Robin suggest is complex but probably good from the user's perspective. I like the idea of using the arrow keys as well as the mouse wheel.