Some unmount operation busy-dialog fixes

[vjr]

Following changes proposed:

• Automatically close the busy warning dialog when the unmount operation finishes. Previously the dialog would not close when the cancel button was clicked although pressing ESC worked.
• Special-case to show different dialog messages if the only process is ourself.
• Exclude ourself from the list of other processes when shown.

[vjr]

This is a follow-up to #2823 to propose some fixes and usability improvements.

[vjr]

@jeremypw another one of my drive-by proposed contributions - hopefully this is useful.

[jeremypw]

Thanks for this - I agree with the intention. Just a couple of suggestions for further clarification.

• Label the "Cancel" button "Do not unmount" or something similar to clarify the exact consequence of pressing it.
• When it is Files only using the resource, we could give more information regarding the file operation - or better, disable the sidebar eject button altogether?
• Expand "Please wait" to clarify what it is the user is waiting for. e.g. " will unmount when the operation finishes."

[vjr]

Thanks for this - I agree with the intention. Just a couple of suggestions for further clarification.

• Label the "Cancel" button "Do not unmount" or something similar to clarify the exact consequence of pressing it.
• When it is Files only using the resource, we could give more information regarding the file operation - or better, disable the sidebar eject button altogether?
• Expand "Please wait" to clarify what it is the user is waiting for. e.g. " will unmount when the operation finishes."

I've updated the text in 6ee3d9f how does it look?

I don't know how to set custom text for the CANCEL button - how do I do that?

Not sure how to do item 2 - when Files is the only app using it - how to detect this without the UnmountOperation - or gather more info about whats being done?

[jeremypw]

I don't know how to set custom text for the CANCEL button - how do I do that?

Use ButtonsType.NONE in the dialog new function and then use add_button in the construct clause. It doesn't matter what response id you choose since this is ignored in this case.

I've updated the text, how does it look?

Not sure whether the balance between brevity and exactitude is right yet. Here is something I mocked up:

This probably goes too far into verbosity but it is up to the user to decide whether to wait or cancel unmounting.

I found an issue if the operation in question is a Files transfer. If the transfer is cancelled while the dialog is open, then the dialog does not close and, if cancelled, further attempts to unmount throw the dialog again even though there are no Files operations in progress. This is probably an issue with Files operations code rather than this PR.

Not sure how to do item 2 - when Files is the only app using it - how to detect this without the UnmountOperation - or gather more info about whats being done?

I'll look into it.

[vjr]

I found an issue if the operation in question is a Files transfer. If the transfer is cancelled while the dialog is open, then the dialog does not close and, if cancelled, further attempts to unmount throw the dialog again even though there are no Files operations in progress. This is probably an issue with Files operations code rather than this PR.

This should be fixed by d3abac0

Please re-test the overall PR when you can, thanks!

[jeremypw]

@vjr

Not sure how to do item 2 - when Files is the only app using it - how to detect this without the UnmountOperation - or gather more info about whats being done?

In principle some information can be obtained from the ProgressInfo objects listed in ProgressInfoManager, however at the moment I think some changes would be required to get this to work which are outside the scope of this PR.

I am drafting some more ported Vala code which includes a FileOperationsManager that maintains a list of ongoing jobs. If this is made available to the UI then it should be straightforward to display the required information.

[jeremypw]

This should be fixed by d3abac0

This commit does fix the issue - thanks! The only comment I would make is that if the ongoing Files operation is cancelled then the dialog closes without unmounting the mount which is in contrast to what happens if the operation is allowed to proceed to the end and contradicts the text in the dialog somewhat.

[vjr]

This should be fixed by d3abac0

This commit does fix the issue - thanks! The only comment I would make is that if the ongoing Files operation is cancelled then the dialog closes without unmounting the mount which is in contrast to what happens if the operation is allowed to proceed to the end and contradicts the text in the dialog somewhat.

Ah yes, my brain fart, should NOT cancel the unmount when the file op is cancelled, it should proceed to unmount, i'll see about fixing, but yes, probably best to wait on your porting/file-operations PR(s) to get merged first, then can revisit my PRs one at a time.

[vjr]

@vjr

Not sure how to do item 2 - when Files is the only app using it - how to detect this without the UnmountOperation - or gather more info about whats being done?

In principle some information can be obtained from the ProgressInfo objects listed in ProgressInfoManager, however at the moment I think some changes would be required to get this to work which are outside the scope of this PR.

I am drafting some more ported Vala code which includes a FileOperationsManager that maintains a list of ongoing jobs. If this is made available to the UI then it should be straightforward to display the required information.

@jeremypw sounds good, i think it's best to wait for your new PR(s) to get merged so i can revisit mine to update them to take advantage of the ported code and the new file operations manager.

[jeremypw]

@vjr It should be OK to finish and merge this PR before my work - it doesn't touch the same code. The thing about showing more info about Files operations is not essential and can be left for future PR.

[vjr]

I found an issue if the operation in question is a Files transfer. If the transfer is cancelled while the dialog is open, then the dialog does not close and, if cancelled, further attempts to unmount throw the dialog again even though there are no Files operations in progress. This is probably an issue with Files operations code rather than this PR.

I've reverted d3abac0 in 7f276ef because this issue you observed seems to be just appearances due to the way kernel buffer cache is happening. Meaning, if you cancel a transfer, the unmount dialog does not close because the transfer dialog disappears but under the hood the cancel is still in progress, and the unmount dialog will in fact close if you wait some time. Could you try that?

Other scenario you mentioned, if you cancel the transfer and then immediately cancel the unmount, the transfer cancel is still in progress, so when you retry unmount, the busy dialog reappears, but it will eventually close and the unmount will happen when the underlying kernel buffer cache completes.

Could you re-try and see if what I've observed is also happening at your end?

[vjr]

If this PR is ready (enough) to approve/merge we might just go ahead with it and see if the other earlier PR(s) to sync and the progress dialog fixes will help to make this issue clearer in that the cancelled transfer dialog stays open until actually finished the cancel.