GNOME Bugzilla – Bug 42168
Empty Trash confirmation should explain trash contents
Last modified: 2021-06-18 15:50:29 UTC
Currently, the Empty Trash confirmation dialog does not contain any details about what's in the trash. It would obviously be better if it mentioned the number of items and amount of disk space taken by the trashed items. Pavel told me that he and Arlo agreed to defer this past 1.0. ------- Additional Comments From sullivan@eazel.com 2000-08-15 10:39:35 ---- I resurrected the Trash component and moved existing Trash-related bugs into it. ------- Additional Comments From arlo@workthatmouse.com 2000-08-15 11:31:41 ---- I did not say it was okay to omit the number of items being thrown away, just the size that the items add up to. Can we move this back to usable? ------- Additional Comments From sullivan@eazel.com 2000-08-15 12:08:09 ---- Moved back to "usable". Once we have a NautilusFile object representing the trash, it should be straightforward to get the count for this dialog. ------- Additional Comments From eli@eazel.com 2000-10-16 19:37:44 ---- Batch-assigning QA ownership of remaining bugs to eli@eazel.com ------- Additional Comments From sullivan@eazel.com 2000-11-28 16:08:33 ---- Deferred a bunch more P5's, after Darin's input. ------- Additional Comments From eli@eazel.com 2001-03-26 11:19:48 ---- SPAAAAAAAAAM! (Jon Allen has taken these components; QA Assigning bugs to him.) ------- Additional Comments From bfrantzda@hmc.edu 2001-03-26 22:16:50 ---- It'd be nice if the trash icon, below ``trash'' had it's size in the same way that most directories have the number of files they contain. I don't worry about the trash 'till it's got a few MB in it. This would make it easier to use. (As a possible extention, the user could select a cutoff size that displaied a very-overflowing bin when the size crossed the threshold.) ------- Additional Comments From sullivan@eazel.com 2001-03-27 06:45:48 ---- I spun out the previous comment into a new bug report, bug 47899. ------- Additional Comments From darin@bentspoon.com 2001-04-23 12:41:32 ---- *** Bug 48135 has been marked as a duplicate of this bug. *** ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:36 ------- Bug depends on bug(s) 42147.
*** Bug 147934 has been marked as a duplicate of this bug. ***
Created attachment 32172 [details] [review] Proposed patch. This patch borrows code from the trash-applet. It adds item count and space used information to the detail text of the empty trash confirmation dialog.
Created attachment 32173 [details] Screenshot of changes.
UP ! There's an intersting patch to review here.
Thanks for your efforts! The patch in its current shape isn't acceptable, though. Instead of writing a custom low-level function, you may want to use nautilus_file_get_deep_counts on the trash URI, which you can gather through EEL_TRASH_URI. Note that an idle function (cf. src/file-manager/fm-properties-window.c) that calls nautilus_file_get_deep_counts might be appropriate here, since remote trashes can take very long.
Would this be a good gnome-love bug?
Created attachment 345894 [details] [review] trash: Explain trash contents on Empty Trash dialog. The current implemntation of the "Empty Trash" dialog does not provide any information about its contents, namely the number of items and disk space they occupy. To implement this enhancement, run_empty_trash_dialog() and do_run_empty_trash_dialog() were implemented on nautilus-file-operations.c to be used similarly to run_simple_dialog() and do_run_simple_dialog(), in order to provide us a way to update the secondary text on the MessageDialog. This info is updated using "trash:" NautilusFile deep-counts in a similar fashion it is used on nautilus-properties-window.c with its target files. To accomplish this, schedule_trash_contents_update() (which prevents updates from happening too often), trash_contents_update() (which updates the dialog's secondary text) and stop_trash_deep_count() (which disables deep-counts and monitoring for the trash's NautilusFile) were also implemented.
Review of attachment 345894 [details] [review]: Hey, it works!! Fantastic However the code and the UI needs work. Regarding the UI, is not clear whether the operation finalised or not, so we should show a spinner in the dialog while the counting is going on. I'm not sure where to put it, bur probably under the sentence. Also, here you use NautilusFile structure, until now you were not supposed to, because this file is for low level operations only (raw GFile). I think we want to change that and incorporate NautilusFile in here too, so it's fine for now, that is the reason of some of the details I reviewed in here: ::: src/nautilus-file-operations.c @@ +1498,3 @@ + size_str = g_format_size (total_size); + gtk_message_dialog_format_secondary_text (GTK_MESSAGE_DIALOG (data->dialog), + { can you use a multi-case basis? 1 file, 1 folder, 1 file multiple folders, multiple files one folder, multiple files multiple folders. So the UI would be something like: Case 1 file or 1 folder: $NAME will be deleted, totalling $SIZE. Case 1 file and multiple folder: $FILENAME and $NUMBERFOLDERS folders will be deleted, totalling $SIZE .... @@ +1501,3 @@ + total_count, + size_str); + } use g_autofree @@ +1545,3 @@ + NULL); + + use generic responses presents as GTK_RESPONSE_* when possible @@ +1561,3 @@ + + attributes = NAUTILUS_FILE_ATTRIBUTE_DEEP_COUNTS; + g_free (size_str); why do we need a monitor? I think what we need is call_when_ready no? @@ +1566,3 @@ + + /* Run the dialog. */ + can we avoid this and instead just show the dialog instead of running it? you can clean up on the signal callback @@ +1578,3 @@ + g_mutex_unlock (&data->mutex); + + data->timeout_id = 0; G_SOURCE_REMOVE @@ +1587,3 @@ + int res; + +schedule_trash_contents_update (gpointer user_data) why do you need this? What is the trash operation doing at this point? @@ +1591,3 @@ + data = g_new0 (RunEmptyTrashDialogData, 1); + data->parent_window = &job->parent_window; + RunEmptyTrashDialogData *data = user_data; create a new API in nautilus-file that get's the trash (I know you saw in this file doing it like this, the reason is what I mentioned before, we were not supposed to use the NautilusFile in here, just plain GFile.) @@ +1606,3 @@ + } + +} same, why is this needed? @@ +1609,3 @@ + res = data->result; + g_mutex_unlock (&data->mutex); +static gboolean spurious new line @@ +1613,3 @@ + g_cond_clear (&data->cond); + nautilus_file_unref (data->trash); +{ use g_autofree @@ +1615,3 @@ + g_free (data); + + RunEmptyTrashDialogData *data = _data; why this is needed?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.