Some unmount operation busy-dialog fixes - #2826
Conversation
Previously it would remain open once the unmount operation completed and clicking the cancel button would have no effect. Pressing ESC would close the dialog though.
If there is only one busy process and it's pid is ours. Previously it would say "there are other processes" and list itself as "io.elementary.files". Now the unmount spinner shows and waits until the unmount operation completes.
Let it be abundantly clear to the user that an unmount operation is still in progress instead of just relying on the inconspicuous spinner. The texts of the dialog are different from the original to not mention "other processes" only "resource is busy" for this special case. The previous existing busy warning dialog and texts listing the other processes is still shown if there are in fact other processes involved.
|
This is a follow-up to #2823 to propose some fixes and usability improvements. |
|
@jeremypw another one of my drive-by proposed contributions - hopefully this is useful. |
jeremypw
left a comment
jeremypw
left a comment
There was a problem hiding this comment.
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 |
Use
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.
I'll look into it. |
This should be fixed by d3abac0 Please re-test the overall PR when you can, thanks! |
| public unowned GLib.File? src_mount = null; | ||
| public unowned GLib.File? dest_mount = null; |
There was a problem hiding this comment.
A little confusing that these a called *_mount but are not Mount objects. Could these not be called *_folder perhaps.
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. |
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. |
2 participants
Following changes proposed: