Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Power Supply Issues #6

Open
damercer opened this issue Oct 14, 2016 · 7 comments
Open

Power Supply Issues #6

damercer opened this issue Oct 14, 2016 · 7 comments

Comments

@damercer
Copy link

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:

  1. 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.
  2. 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.
@rgetz
Copy link

rgetz commented Oct 15, 2016

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.

@rgetz
Copy link

rgetz commented Oct 15, 2016

I split issue 2 into its own issues in #7

@damercer
Copy link
Author

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.

@damercer
Copy link
Author

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

@dNechita
Copy link
Contributor

The following is an input widget prototype that handles the requirements mentioned in issue 1.

ps_underlined_digit_1
ps_underlined_digit_2

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.

@rgetz
Copy link

rgetz commented Oct 17, 2016

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?

@damercer
Copy link
Author

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.

@pcercuei pcercuei removed the bug label Jul 12, 2017
@adisuciu adisuciu added this to the phase2 milestone Sep 20, 2017
@adisuciu adisuciu added the ui label Aug 17, 2018
@adisuciu adisuciu modified the milestones: phase2, R1.2 Aug 17, 2018
@adisuciu adisuciu added this to Backlog in Scopy Feb 27, 2019
@adisuciu adisuciu removed this from the R1.2 milestone Nov 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Scopy
  
Backlog
Development

No branches or pull requests

5 participants