When filechooer is re-used (instead of being created and destroyed
every time it's needed), it might happen that the directory the
application wishes to initially show is the same directory that
was shown last time the filechooser was used. In that case, make sure
filechooser knows that it does not need to do its default "select $pwd
or $home" routine.
https://bugzilla.gnome.org/show_bug.cgi?id=766122
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add a new signal with an open flags parameter and deprecate
the other-location signal.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add the signal missing parameter in order to allow it.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
With the location entry up in the header bar in save mode, we can
end up with the search model being in use when the user types in
the location entry. In this case, we don't make the Save button
sensitive as we should.
Having two entries in the dialog is somewhat confusing anyway,
so just stop the search when the user starts typing in the location
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=761757
Calling _gtk_file_consider_as_remote() with a NULL argument
results in warnings being thrown.
Note that query->priv->location being NULL is a state that does
not seem to be invalid by itself.
This could happen if you do search-as-you-type in a filechooser,
which has a filter that does not match anything *and* the current
"place" selected is "Recent".
https://bugzilla.gnome.org/show_bug.cgi?id=761552
Since 39c2d12330,
priv->operation_mode == OPERATION_MODE_BROWSE no longer
guarantees that priv->browse_files_model is the current
model of the list - we are only switching the models after
loading the new directory. Avoid triggering the assertion
in show_and_select_files by checking if we have right model
before calling it.
https://bugzilla.gnome.org/show_bug.cgi?id=761209
In some situations (no header bar, save mode), hitting Escape
would not do anything because the entry ate the key event.
Fix this by telling the entry to only handle Escape when there
is something to do, such as switching back to the path bar.
https://bugzilla.gnome.org/show_bug.cgi?id=761026
Commit 8e975b2 (Bug 753969) introduced check of parent accessibility.
Consequently it is not possible to save file if executable attribute
is not set, which might happen for some gvfs backends. Let's assume
that the folder is accessible even if the attribute is not set.
https://bugzilla.gnome.org/show_bug.cgi?id=760881
Since we are now interpreting button press events and
make our own double-click determination, we should not
handle double-click events that are generated by GDK.
https://bugzilla.gnome.org/show_bug.cgi?id=757950
When the search entry is shown, the 'special' nature of
., ~ and / should not trigger the location entry, because
that interrupts the search and is likely not what the
user intended.
https://bugzilla.gnome.org/show_bug.cgi?id=756505
Move focus to list when search results appear to make it
possible to select the first search result by just hitting
Enter. To keep this from interfering with keynav, we need
to make sure that we still handle Escape to search. And when
search comes up empty, we need to move the focus back to the
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=755926
The stack calls gtk_widget_grab_focus on the last focus widget,
which selects the text in the entry, so we need to make sure to
move the focus there first to keep that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=755931
When right-clicking in an empty folder, you should get a context
menu, not a crash. The code for positioning the popover was not
handling the eventuality of no row under the pointer. Just position
the popover right at the click location in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=755021
If we manually enter an unaccessible path in the entry, e.g
"/root/foo.txt", we should receive an error saying that the
folder is not accessible instead of showing the replace
confirmation dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=753969
