After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 729927 - impossible to create a directory if the contents of the current one change
impossible to create a directory if the contents of the current one change
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.13.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
: 627896 779292 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-05-10 17:52 UTC by Emmanuele Bassi (:ebassi)
Modified: 2017-02-27 11:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Freeze file system model during editing (4.27 KB, patch)
2014-11-19 14:48 UTC, Emmanuele Bassi (:ebassi)
committed Details | Review

Description Emmanuele Bassi (:ebassi) 2014-05-10 17:52:55 UTC
steps to reproduce:

 1. have a file continuously update inside a directory (touch in a 1 second loop should do)
 2. open a "save" file dialog from any application and navigate to that directory
 3. from the file dialog try to create a new directory

result: the directory creation gets cancelled (with barely any user feedback) as soon as there's an update notification.

the file system model should be frozen while the user is creating a directory.
Comment 1 Emmanuele Bassi (:ebassi) 2014-11-19 14:48:07 UTC
Created attachment 291006 [details] [review]
Freeze file system model during editing

If a file system event arrives while GtkFileChooserWidget is asking the
user to edit the name of a newly created folder, the file system model
will drop the row with the editable cell, and the user will have to
start from scratch.

This makes creating new directories impossible inside a directory with a
file currently being downloaded, for instance, and it's really unhelpful
to the user because the editable row simply disappears.

We already have a mechanism in place to freeze the file system model, so
we can reuse it between the add_editable() and the remove_editable()
calls.
Comment 2 Emmanuele Bassi (:ebassi) 2014-11-19 15:42:32 UTC
to expand a bit on the issue:

 * changing a file is handled like addition and attribute changes
 * whenever a file changes, the file is queried and the model re-sorted
 * re-sorting the model cancels the editing because the editable row could change its position

in this particular case, the file changes size/mtime, but not its name, but obviously the GtkTreeView cannot know that.

by freezing the file system model, the sorting is deferred until the editing of the newly created directory is complete. since only sorting is deferred, the modified time and size cells are still updated.
Comment 3 Federico Mena Quintero 2014-11-20 02:02:00 UTC
Do you have a trace of where the editable row gets removed?

There are parts of the code that avoid touching the editable row, so in theory the rest of the file system model can operate as normal.  For example, see where gtk_file_system_model_sort() calls g_qsort_with_data(), starting from index 1 - not zero, since zero is the editable row.

I.e. I don't think freezing the model is correct here; we should find the root cause for why the editable row is removed.
Comment 4 Federico Mena Quintero 2014-11-20 02:04:18 UTC
(It may be enough to set a breakpoint in emit_row_deleted_for_row() when row is 0.)
Comment 5 Federico Mena Quintero 2014-11-20 02:10:32 UTC
(If you end up actually implementing gtk_file_system_model_sort_node() with a binary search or something, instead of making the entire model sort itself, well, I'll owe you a beer.)
Comment 6 Federico Mena Quintero 2014-11-20 02:19:55 UTC
(In reply to comment #4)
> (It may be enough to set a breakpoint in emit_row_deleted_for_row() when row is
> 0.)

... unless the treeview is stopping editing itself when resorting happens.  I have no idea if that is the case.
Comment 7 Emmanuele Bassi (:ebassi) 2014-11-20 10:37:05 UTC
(In reply to comment #3)
> Do you have a trace of where the editable row gets removed?

the row is not removed: the editing is automatically cancelled on sort by GtkTreeView.

> There are parts of the code that avoid touching the editable row, so in theory
> the rest of the file system model can operate as normal.  For example, see
> where gtk_file_system_model_sort() calls g_qsort_with_data(), starting from
> index 1 - not zero, since zero is the editable row.

it does not matter: gtk_tree_model_row_reordered() will emit GtkTreeModel::rows-reordered, and it will be caugth by GtkTreeView which will call gtk_tree_view_stop_editing() with cancel_editing=TRUE if there is a column currently being edited. the code is fine if you don't want to take into account the empty row currently being edited, but it does not matter one bit as to whether the editing will be cancelled or not.

freezing sorting while editing the name of the directory is a perfectly acceptable solution for this use case. I'm definitely not going to touch GtkTreeView sorting, at this point. what I would like, though, is a GtkFileChooserWidget that does not break user interaction in unpredictable and unfriendly ways because of a file system event.
Comment 8 Federico Mena Quintero 2014-11-20 21:14:29 UTC
Oh, okay, I didn't know that it was happening due to GtkTreeView.

Freezing the model sounds fine in that case.
Comment 9 Matthias Clasen 2014-11-26 04:23:22 UTC
Attachment 291006 [details] pushed as cbb2938 - Freeze file system model during editing
Comment 10 Emmanuele Bassi (:ebassi) 2015-05-10 09:42:52 UTC
*** Bug 627896 has been marked as a duplicate of this bug. ***
Comment 11 Emmanuele Bassi (:ebassi) 2017-02-27 11:06:52 UTC
*** Bug 779292 has been marked as a duplicate of this bug. ***