lp1719474: Fix unresponsive scrolling through crates & playlists using encoder #1619
Conversation
uklotzde
changed the title
| QObject* parent) | ||
| : QObject(parent), | ||
| m_pConfig(pConfig), | ||
| m_clickedChildActivationTimeoutMillis(0) { |
There was a problem hiding this comment.
Because this is the default behavior, i.e. just process all system events and let the timer fire immediately. Almost the same behavior as before, just one roundtrip through the event loop. Prevents special case handling.
There was a problem hiding this comment.
But we could also define a default > 0 if that makes sense. Currently it is opt-in, only used by crates and playlists.
There was a problem hiding this comment.
So the timer fires mediately with 0? The Qt doc is not clear about that, or negative values.
There was a problem hiding this comment.
Totally clear about that: "As a special case, a QTimer with a timeout of 0 will time out as soon as all the events in the window system's event queue have been processed. This can be used to do heavy work while providing a snappy user interface: ..."
|
Ups,Yes now I see. |
|
And works as it should. |
|
In testing this, it's working fine, but could be user/hardware dependent on the delay time that provides adequate scrolling and loading responsiveness. In my case, I changed the delay to 250 ms and it was perfect. About the time I'm deciding I want to see the contents of the crate or playlist is when it loads now, but never loads while scrolling. 100 msec would still cause delays due to db loading as I would scroll across folders. Is this possibly a candidate for a config option in the library preferences dialog? |
|
No, we should not clutter the preferences with yet another option for this. It should just work. |
|
I agree with @Be-ing, we should try to find a sensible default. It would be difficult to explain such a configuration option to the causal user. Agreed, 100 ms is already very tight if you scroll slowly throw the list. I will re-test with 250 ms. |
|
In that case, I'd vote for bumping the delay up a bit to 200-250 msec. At 100 msec, my brain hasn't had enough time to decide if I want to see a particular playlist. It requires me to still have to scroll pretty fast to avoid hangups, making me have to concentrate very hard on scrolling, taking away from the 'it should just work' mantra. |
|
Next evolution: #1620 |
https://bugs.launchpad.net/mixxx/+bug/1719474
A delay of 100 ms provides (almost) smooth scrolling and doesn't have a noticeable impact on the responsiveness when clicking on a crate or playlist item using the mouse.
You need a controller with a properly mapped encoder to test this PR!