add busy cursors to history paste/compress/discard

[ralfbrown]

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.

[TurboGit]

Only to be merged if #17207 is not solved over the week-end, right? I may also take over #17207 if you don't mind as there is no urgency on this and #17207 is a better proposal to me.

[ralfbrown]

Yes, this is Plan B.

[ralfbrown]

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.

[TurboGit]

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.

[ralfbrown]

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.

[TurboGit]

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.

[ralfbrown]

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.

[TurboGit]

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?

[ralfbrown]

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.

[TurboGit]

Is having a busy cursor, a background job started and void dt_control_job_wait(dt_job_t *job); called to wait it to end would work here? I'm still trying to see if we can avoid the new modal dialog...

[ralfbrown]

@TurboGit
I tried dt_control_job_wait on PR 17207, since that already has things rearranged to start an independent job for the bulk operation together with enabling the busy cursor while waiting. I had to fix dt_control_job_wait to actually wait (it was getting in before the scheduler actually started the job and thus returned immediately). Once I did that, there were no more GUI updates - the progress meter stayed at 0 until complete and didn't allow cancellation.

I'm pretty sure that if I modify dt_control_job_wait to use a trylock loop with dt_gui_process_events() inside instead of simply requesting to lock the mutex, we'll be back to all the issues of unwanted operations starting when the user clicks on something while the bulk history operation is in progress....

[TurboGit]

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

[ralfbrown]

Haven't had time yet - probably tomorrow.

[ralfbrown]

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

[ralfbrown]

Mooted by #17207.