-
Notifications
You must be signed in to change notification settings - Fork 1.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
add busy cursors to history paste/compress/discard #17301
Conversation
Yes, this is Plan B. |
Also add a verification popup if the operation is being applied to 1000 or more images.
c708078
to
85b15aa
Compare
Add a progress-bar modal dialog window in place of the busy cursor when applying a history operation to ten or more images. The dialog has a cancel button which will abort the bulk operation before completion. |
I'm not sure this is a good move, it introduces for the first time a busy-modal-dialog. |
True, but the existing behavior is effectively modal anyway, since it completely freezes the GUI until the bulk operation completes. At least this way, the user can cancel the operation before it completes, and implementation-wise we don't have the synchronization headaches encountered on the other PR. |
But then I'd prefer having the current progress status bar (bottom left of UI) with a busy cursor icon and making the UI non responsive except for cancelling the job using bottom left cross. |
I don't know how to do that, since the job system's "foreground" queues aren't actually blocking, they're just higher priority than the background jobs.... Already tried that approach. |
Then why not just adding a busy cursor and not make the job in background... So what we have in master but just with a busy cursor? |
The progress bar added in the last commit is running in the foreground -- making the dialog containing it modal prevents other things from running as a result of the GUI thread reacting to user actions, which might then cause interference such as we see in the other PR where the bulk processing is a background task. Unless there's some trick I haven't learned yet, if you want to handle interactions with a particuar widget (or even just update the screen), you still have to process events from all widgets. Making the one you are interested in (or one of its ancestors) modal causes the unwanted events to be ignored or blocked until later, so that only the desired events get processed. |
Is having a busy cursor, a background job started and |
@TurboGit I'm pretty sure that if I modify |
@ralfbrown : Just checking the status here, have you tested the @dterrahe PR on top of yours which should enhance the behavior as it was discussed? Let me know, I don't want to let this important PR not merged for too long to ensure lot of field testing. |
Haven't had time yet - probably tomorrow. |
@TurboGit Took a look, seems good to me. It's on top of the other PR, #17207, which should now be the preferred one with other user interactions blocked while the bulk action is in progress (since we get the progress bar with cancellation without a separate popup window and keep the busy cursor except while on the progress bar). |
Mooted by #17207. |
Also add a verification popup if the operation is being applied to 1000 or more images.
Simpler alternative to #17207 which doesn't have any of the complications caused by background execution of history operations.