GNOME Bugzilla – Bug 368931
incorrect file entry completion filling when dropping files to the files view
Last modified: 2016-03-10 21:49:58 UTC
Hi!, I noticed high CPU churn when running testfilechooser in gtk+/gtk/ and accidentally dragging and dropping a file from and to the file treeview, and it became worst each time I did that. Some investigation showed me that if the dropped file is in the same folder than the current one, it's anyways reloading the folder and telling the file entry completion widget to add again all files (effectively, files are shown several times after some DnD operations as commented before). With populated folders CPU churn seems to be produced by completion model reordering. I'm going to attach a patch that just selects the dropped file if it's in the same folder instead of going through the reload folder/select file process
Created attachment 75779 [details] [review] patch
I've noticed the same behavior through other methods: * in testfilechooser, pressing several times in the /usr/nonexistent button, it happens the same, if the test is modified to go to /usr/bin/nonexistent, CPU churn is again there due to the ammount of files. * pressing in the pathbar the currently shown folder. I guess you'll prefer a common fix in GtkFileChooserEntry to avoid reloading the completion rather than individual fixes, right? I may begin cooking a patch
Yes, the right fix should go in the file chooser entry. It should clear its completion list when _gtk_file_chooser_entry_set_base_folder() is called. The code is a bit hairy, and I don't remember it very well, but thanks for taking a look :)
Created attachment 76454 [details] [review] updated patch I've discovered that it doesn't go through that code path, the completion model keeps track of its current GtkFileFolder changes using its "files-added" and "files-removed" signals, particularly, the "files-added" handler is responsible of refilling the completion model each time the folder is got from the GtkFileSystem, producing the duplicates. I've done a patch that replaces the custom completion model with a GtkFileSystemModel, which already handles fine this situation. Also avoids duplicating some functionality.
Hello Federico (or somebody else) Whould it be possible to review the patch ? Thanks
the patch doesn't cleanly apply to trunk anymore. carlos, could you please check it and port it over to svn? thanks! from a quick look, it seems okay to use GtkFileSystemModel.
I've updated the patch, and it seems to work fine. the code has been simplified and the CPU churning is reduced (albeit, a profile might be better suited at confirming this than looking at the cpu monitor :-)). attaching the patch updated to trunk.
Created attachment 88655 [details] [review] Use GtkFileSystemModel as the completion model for GtkFileChooserEntry Use GtkFileSystemModel as the completion model for GtkFileChooserEntry The GtkFileChooserEntry widget uses its own completion model to keep track of the current GtkFileFolder changes using its "files-added" and "files-removed" signals; particularly, the "files-added" handler is responsible of refilling the completion model each time the folder that it gets from the GtkFileSystem changes, producing the duplicates. This patch replaces the custom completion model with a GtkFileSystemModel, which already handles fine this situation. Also avoids duplicating some functionality. The patch was originally done by Carlos Garnacho. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org> --- gtk/gtkfilechooserentry.c | 170 +++++++++++---------------------------------- 1 files changed, 42 insertions(+), 128 deletions(-)
Doh! thanks Emmanuele for updating the patch :)
*** Bug 515679 has been marked as a duplicate of this bug. ***
Emmanuele, Carlos: any progress on this?
Is this still relevant, after Federicos completion rework ?
Possible obsolete bug???
Obsolete!