Allow the knobs to change when the mouse is moved horizontally

Bug #767409 reported by jus on 2011-04-20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bill Good

Bug Description


Currently the mouse movement is only tracked vertically for knobs. If a knob is placed near the top of the screen ( like in the Deere skin), there is litte room left for moving the mouse.

Related branches

jus (jus) on 2011-04-20
summary: - Allows the knobs to change when the mouse is moved horizontally
+ Allow the knobs to change when the mouse is moved horizontally
Bill Good (bkgood) wrote :

I've always been a fan of what Traktor does here, they hide the mouse pointer and capture input (or they continuously set the pointer to its original position and use the delta to change the control), and when you release the mouse button, your pointer reappears where the original mouse-down signal occurred. This enables the user to continue the use of the "up-down mouse-control" paradigm, I think making some controls only modifiable by horizontal movement might be confusing.

Another option would be to do what (for instance) KDE's Okular (document viewer) does, in dragging, when the pointer reaches the top of the screen, the pointer immediately is moved to the bottom of the screen and the user can continue dragging, and vice-verse.

jus, do you have any thoughts on these?

Changed in mixxx:
assignee: nobody → Bill Good (bkgood)
importance: Undecided → Low
milestone: none → 1.9.1
status: New → Confirmed
jus (jus) wrote :

Thanks for reply Bill.
I have expressed myself vaguely, it is not my intention to make knobs only modifiable by horizontal movement. My idee was to somehow capture these movements too. The process that you described first sounds good.

I have not worked with KDE Okular so can`t say if the continuous mouse movement is practical. For most users on non KDE systems it would be at least unexpected.

RJ Skerry-Ryan (rryan) wrote :

Bill have you made progress on this? Something like the attached should work

Bill Good (bkgood) wrote :

I've written some code to do what I described above (hide the cursor, capture movement, cursor reappears at original position on mouse up). The patch is attached. I didn't like its effect when I first implemented it on Windows, but I've since lost that code and rewritten in on Linux, where I like it. I'm going to test it on Windows again, could someone test on OSX?

I'm still of the opinion that allowing horizontal or vertical movement is overly-complicated, but I'm not feeling particularly strongly about it either way.

jus (jus) wrote :

Hide the cursor, capture movement, cursor reappears at original position on mouse up - all confirmed working on MacOS 10.6.7
Like it.

RJ Skerry-Ryan (rryan) wrote :

I like the effect but hiding the cursor feels weird. Traktor keeps it visible while you do that?

With your patch it's especially confusing when I try to move horizontally -- I would suggest we merge our patches so that the distances traveled is the amount the knob is turned by and the direction it applies depends on which is the greater movement in either axis (e.g. if you moved dominantly upwards or dominantly rightwards then the knob turns clockwise).

Bill Good (bkgood) wrote :

Traktor hides it as well. It'd look really funky if it wasn't hidden, because the cursor would continually glitch back to where it started (as that's how it solves the problem of changing the control near the edge of the screen). I'm down with merging the two, though.

Perhaps there's a way to highlight the knob being adjusted so it's obvious what's going on?

jus (jus) wrote :

If you turn a knob, he (the marker on it ) changes. Isn't that obvious enough? If not we simple need to change the buttons image sequence.

Really, i found the hidden cursor helpful cause it gives you full view on the changes. The missing cursor feels weird the first few times , but suddenly it all makes sense :-)

Bill Good (bkgood) wrote :

Here are the two combined. Any thoughts?

The behavior with cursor-hiding has precedence with Traktor, and my personal opinion is that the movement of the knob is plenty of feedback. User clicks, cursor disappears; if a user is bothered by the disappearance, all one must do is let go of the mouse button and the cursor reappears exactly where it disappeared and it certainly shouldn't seem surprising, what does a cursor have to do with a knob, anyway? It does take a little getting used to (like jus, when I first used it, I have to double-take but I quite liked it afterwards).

RJ Skerry-Ryan (rryan) wrote :

Works well for me on Linux. I like it a lot actually -- you're right after using it for a bit I got used to the mouse disappearing. Did you try it on Windows? If it works there then let's go for it for 1.10.

Changed in mixxx:
milestone: 1.9.1 → 1.10.0
Bill Good (bkgood) on 2011-05-03
Changed in mixxx:
status: Confirmed → Fix Committed
RJ Skerry-Ryan (rryan) on 2011-12-25
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers