Skip to content
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

Merged
merged 8 commits into from
Jul 10, 2020
Merged

WTrackMenu: Display a modal progress dialog #2899

merged 8 commits into from
Jul 10, 2020

Conversation

uklotzde
Copy link
Contributor

@uklotzde uklotzde commented Jun 23, 2020

!!! Target branch is 2.3 although assigned to the 2.4.0 milestone. Don't merge before joint decision !!!

- [ ] Finalize & approve software design Good enough for now. We can change it when needed.

Not perfect and comes with some drawbacks, but still a huge usability improvement:

  • Display a modal progress dialog while batch processing multiple tracks
  • Allow to safely abort batch processing
  • Remove obsolete and performance killer method WTrackMenu::getTrackPointers()

wtrackmenu modal progress

Any ideas on how to implement a batch processing framework with less boilerplate and without the (implicit) usage of QCoreApplication::processEvents()?

@uklotzde uklotzde added this to the 2.4.0 milestone Jun 23, 2020
@uklotzde uklotzde mentioned this pull request Jun 23, 2020
11 tasks
@uklotzde uklotzde marked this pull request as draft June 29, 2020 22:23
@Be-ing
Copy link
Contributor

Be-ing commented Jul 3, 2020

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.

int estimatedTotalCount =
pTrackPointerIterator->estimateItemsRemaining().value_or(trackCount);
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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"

Copy link
Contributor Author

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.

@Be-ing
Copy link
Contributor

Be-ing commented Jul 4, 2020

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.

@Be-ing
Copy link
Contributor

Be-ing commented Jul 4, 2020

@hacksdump could you take a look at this when you get a chance?

@Be-ing
Copy link
Contributor

Be-ing commented Jul 4, 2020

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?

@katsar0v
Copy link
Contributor

katsar0v commented Jul 4, 2020

Wanted to test, got this error when tried to compile:

CMake Error at CMakeLists.txt:2206 (message):
  Secure credential storage support requires the Qt5::Keychain component.


-- Configuring incomplete, errors occurred!
See also "/tmp/mixxx/cmake_build/CMakeFiles/CMakeOutput.log".
See also "/tmp/mixxx/cmake_build/CMakeFiles/CMakeError.log".

But it seems to be a useful feature!

@Holzhaus
Copy link
Member

Holzhaus commented Jul 4, 2020

@katsar0v You need to install qt5keychain or set -DQT_KEYCHAIN=OFF during cmake configuration.

@katsar0v
Copy link
Contributor

katsar0v commented Jul 4, 2020

Yes, I installed it and updated the wiki. I will test again today later and report here

@katsar0v
Copy link
Contributor

katsar0v commented Jul 4, 2020

Ok, I built it. Tested it and it works well.

image

image

@uklotzde
Copy link
Contributor Author

uklotzde commented Jul 4, 2020

The new TaskMonitor abstraction allows to monitor and control multiple worker tasks in the future. Currently it uses QProgressDialog which only works well for a single task.

Added as a proof of concept for a more sophisticated UI solution. It could be extended in the future without affecting existing code.

@uklotzde uklotzde changed the title [WiP] WTrackMenu: Display a modal progress dialog WTrackMenu: Display a modal progress dialog Jul 4, 2020
@uklotzde uklotzde marked this pull request as ready for review July 4, 2020 22:36
@uklotzde uklotzde changed the base branch from master to 2.3 July 4, 2020 22:40
@uklotzde
Copy link
Contributor Author

uklotzde commented Jul 4, 2020

Rebased on and retargeted to 2.3 to check if this is feasible.

@hacksdump
Copy link
Contributor

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.

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.

@Holzhaus
Copy link
Member

Holzhaus commented Jul 6, 2020

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).

@uklotzde
Copy link
Contributor Author

uklotzde commented Jul 6, 2020

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.

@Be-ing
Copy link
Contributor

Be-ing commented Jul 10, 2020

Mixxx still becomes unresponsive with batch jobs, but at least there is some UI indicating what is going on.

src/util/itemiterator.h Outdated Show resolved Hide resolved
@Be-ing
Copy link
Contributor

Be-ing commented Jul 10, 2020

Just some minor comments, but otherwise looks good to me.

Comment on lines 26 to 28
// 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 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

@Be-ing
Copy link
Contributor

Be-ing commented Jul 10, 2020

Looks good to me. Waiting on CI.

@Be-ing Be-ing merged commit 80424d4 into mixxxdj:2.3 Jul 10, 2020
@Be-ing Be-ing mentioned this pull request Jul 11, 2020
5 tasks
@uklotzde uklotzde deleted the wtrackmenu_batchprocessing branch August 8, 2020 14:36
@daschuer daschuer mentioned this pull request Feb 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants