Timeline: mouse handling improvements #606
Conversation
An easy-going vertical wheel scroll over the timeline is expected by users even if shuttleDial is enabled.
There was a problem hiding this comment.
First of all - many thanks for attacking this topic - Quaternion admittedly sucks at handling text selection, and scrolling still has some room for improvement. I'm not entirely happy with the number of newly introduced objects but I understand that the current model of pointer handling in Qt doesn't leave many other options. I'll give this a ride for a day or two, and if I don't stumble over serious issues I'll merge it.
There was a problem hiding this comment.
Unfortunately the selection part is not portable: "Support for QClipboard::Selection is provided only on systems with a global mouse selection (e.g. X11)." (from Qt docs). As a result, at least on Windows, just selecting the text immediately (right after releasing the mouse button) leads to two unexpected things:
- the text gets unselected; if I wasn't careful enough and selected too much or too little, I have to reselect it;
- the selection goes to the clipboard right away, potentially overwriting whatever I have there.
rpallai
force-pushed
the
mousehandling
branch
2 times, most recently
from
c4940ac
to
6b23716
Compare
|
I reworked text selection, now the selected text:
The only feature I have to reimplement is correction of the selection by shift + click. To tell you truth I wasn't aware of this capability until you had mentioned it. |
Dropped files will be attached, dropped text will appear in the input line.
It's also done. Please test. |
There is no doubt that the most clicked widget is the timeline. We click it to open pictures, to bring the window forward, to select text, etc. Unfortunately, these actions ended up with unfocused input line which was my primary reason to go ape on Quaternion. This patch introduces a strict focus policy on the timeline which means the timeline won't keep the focus for long, it will hand back to the input line when possible, when pressed mouse buttons are released. At the same time we had to implement our own TextEdit text selection mechanism because the original didn't pass through required mouse events. Added bonus that deselection now works for different messages (closes quotient-im#300).
|
Turned out I was a bit hasty. Your code prevents hyperlinks from working. |
|
Also, after spending some more time I now see that the original scrolling is actually about 3 times more precise (it's also slower but not as much) at least on my setup. A case for adjustable sensitivity is quite prominent. |
What do you mean under more precise scrolling exactly? Wasn't your jump length constant per every each wheelEvent, so non-linear? Perhaps Anyway, adjustable sensitivity is indeed important, I'll push that into the preferences window as it will be available (#605). |
|
That's the contention point: for me, 16px/notch is almost good enough (maybe a bit slowish). So it's really just about different tastes. |
|
Ouch, I didn't really mean to restore it so unceremoniously :( And of course let's make it configurable after merging #605. With respect to sensitivity - we can make it non-linear but it's yet another Pandora's box. From the UX perspective - very few people would even bother so much to precisely tune it. What I would introduce instead is adding the shuttle-dial style of treating wheel events - with notches controlling the speed rather than distance. That would effectively enable auto-scrolling (imagine speed-reading your timeline without having to constantly turn the wheel to show the next piece). |
No description provided.