-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
WTrackMenu: Display a modal progress dialog #2899
Conversation
Thank you for working on this tricky optimization. A popup dialog is an easy solution for the GUI design and I'm okay with merging that, but long term it would be better to design a place in the main window for a progress bar. That could also be reused for removing the Analyze library feature and the library scanner popup window. |
src/library/trackprocessing.cpp
Outdated
int estimatedTotalCount = | ||
pTrackPointerIterator->estimateItemsRemaining().value_or(trackCount); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused. Total count and remaining count are not the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Estimated = guessed. If unknown we take the number of processed tracks and adjust it when exceeding the maximum.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took me a while of reading the code to understand but it makes sense. Please add a comment:
"Before starting any tasks, total = remaining"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for insisting on a clarification. The update during the loop contains a bug. This never happened, because we only iterate over sequences of known size.
Should this go to the 2.3 branch considering we advised users to clear all keys and reanalyze in the 2.3 beta announcement? I don't care much either way, but it's worth considering. |
@hacksdump could you take a look at this when you get a chance? |
I haven't looked super closely at every detail, but overall this looks like a good improvement. It would be great if we could parallelize these batch operations, but IIUC that isn't possible until we get database transactions out of the GUI thread, right? |
Wanted to test, got this error when tried to compile:
But it seems to be a useful feature! |
@katsar0v You need to install qt5keychain or set |
Yes, I installed it and updated the wiki. I will test again today later and report here |
The new Added as a proof of concept for a more sophisticated UI solution. It could be extended in the future without affecting existing code. |
Rebased on and retargeted to 2.3 to check if this is feasible. |
I can think of something like the progress info in Jetbrains IDEs. It just shows a common status for all global background jobs in the bottom bar. |
It this window modal because Mixxx should not be used in the meantime? If it was possible to use Mixxx while the jobs are processed, we should make it part of the Notification area I proposed on Zulip: https://mixxx.zulipchat.com/#narrow/stream/109171-development/topic/Notification.20area (not now, I mean long-term). |
The modal progress dialog is used because it works out of the box and prevents concurrent UI interactions. Currently those tasks are executed one after another in a simple loop on the UI thread, not as detached jobs. Separate topic, out of scope here. The task monitoring component is already designed to support concurrent tasks in separate threads with its thread-safe signal/slot interface. It could be displayed in a separate area on the screen. When available the custom progress display of the multi-threaded analysis could be migrated, too. |
…u_batchprocessing
Mixxx still becomes unresponsive with batch jobs, but at least there is some UI indicating what is going on. |
Just some minor comments, but otherwise looks good to me. |
src/library/trackprocessing.cpp
Outdated
// The total count is initialized with the remaining count | ||
// before starting the iteration. If the this value is unknown | ||
// we use 0 as the default until an estimation is available |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// The total count is initialized with the remaining count | |
// before starting the iteration. If the this value is unknown | |
// we use 0 as the default until an estimation is available | |
// The total count is initialized with the remaining count | |
// before starting the iteration. If this value is unknown | |
// we use 0 as the default until an estimation is available |
Looks good to me. Waiting on CI. |
!!! Target branch is 2.3 although assigned to the 2.4.0 milestone. Don't merge before joint decision !!!
- [ ] Finalize & approve software designGood enough for now. We can change it when needed.Not perfect and comes with some drawbacks, but still a huge usability improvement:
Any ideas on how to implement a batch processing framework with less boilerplate and without the (implicit) usage of
QCoreApplication::processEvents()
?