-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Wacom Tablet support #4376
Wacom Tablet support #4376
Conversation
I see you're using tablet-specific Qt events. Does the mouse behavior remain the same? |
Yes, QMouseEvent is unaffected in any way. When QTabletEvent is not handled and not accepted, Qt generates a QMouseEvent. |
I just reread my code, another commit incoming. Need to fix the tabletRelease handler |
Alright, awesome. I will model the vector graph tension handles (#4367) after that. Would you be willing to test it if I ping you about it in maybe a week or so? |
Does it need special handling for tablet support? Can you send me instructions how to test your current working version? |
Clone/build the branch, add the plug-in ”Waveshaper 2” to the master effects chain, and try to drag the little circle in the middle of the line. I've implemented that functionality in a similar way to the knob dragging so I expect it to break in a similar way. I can just ping you when I have a fix implemented. |
What tablet are you using and which driver version? I agree that there are problems with tablets but I'm not seeing your issue with my particular tablet. I have other issues with my tablet. (intuos, driver: 6.3.29-6) Try raising the value of the knob with your stylus, hold it, check the value while holding the stylus motionless, then lower it while looking at the value. What I'm seeing on my end is that for a brief moment the value increases when going down with the stylus. It is as if the motion was buffered (it hadn't processed the final moments in its buffer of the stylus going upwards). Does my explanation make any sense? |
Interesting, what OS are you using, I am using Arch Linux, will check the tablet version when I get to my pc? Do you have the tablet in absolute mode? I could see this issue not being present if the driver actually stops giving updates when you are not moving, but the linux driver I am using does not behave like that. Have you tried building and running with my branch? Does it affect your issue? |
There are some situations where
|
Just a question: can we remove unnecessary and/or problematic calls to |
Due to the conflicts of #5360, it makes no sense to merge this as-is. |
I think even if we rewrite this PR correctly concerning
|
#5360 fixed the issue, so I'm closing this. |
Hi,
I have just started learning LMMS and found it quite difficult to control the Knobs with my Wacom pen tablet. I use my tablet to alleviate RSI strain of using the mouse, and have gotten quite used to it.
Unfortunately, the current implementation of the Knob is incompatible with a tablet set to Absolute mode (pixels on tablet are mapped roughly 1:1 to pixels on screen). Since in Knob::mouseMoveEvent
QCursor::setPos( mapToGlobal( m_origMousePos ) );
the cursor position gets reset, which then triggers a new QMouseEvent because now the cursor position is far away from the current tablet position (which is absolute). First I tried to hack the existing code, but my effort has proven fruitless, due to the nature of the Knob mouse handling implementation (though, I couldn't figure out a better way to do it either)
So I have implemented the TabletEvent interface. Any events that aren't handled by the new code get
event->ignore()
ed and then Qt spawns a regular QMouseEvent which then propagates as usual.So far, Knob is the only GUI element which I found that behaved strangely with my tablet, I will add support to any other elements if I find them.