This will be the central function to switch operation modes: stop searches or the recent-files
process; switch widgets, etc.
We factor out the common code from recent_switch_to_browse_mode() and search_switch_to_browse_mode(),
and remove those functions. All the code that switched modes by hand now calls
the central operation_mode_set().
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
That code indeed lives in operation_mode_stop(), so use it instead of
having inlined duplicates.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We'll now prefix functions to change the impl->operation_mode with 'operation_mode',
for clarity.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Various paths in SAVE or CREATE_FOLDER return from ::should_respond() but
leave an asynchronous process running. This process checks some things
in the user's selection, for example, 'does the file exist, and if so
do we need to bring up an overwrite-confirmation dialog?'. When these
async processes complete *and* it is indeed time for the dialog to
be terminated (via the response-requested signal), we also need to
save the selection to the recently-used list - as ::should_respond() does
by itself in the cases when it can request a response immediately.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
To make life easier for users, when apps don't properly update the recently-used list
after choosing a file, we now do that directly from the file chooser.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Various paths in SAVE or CREATE_FOLDER return from ::should_respond() but
leave an asynchronous process running. This process checks some things
in the user's selection, for example, 'does the file exist, and if so
do we need to bring up an overwrite-confirmation dialog?'. When these
async processes complete *and* it is indeed time for the dialog to
be terminated (via the response-requested signal), we also need to
save the selection to the recently-used list - as ::should_respond() does
by itself in the cases when it can request a response immediately.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
To make life easier for users, when apps don't properly update the recently-used list
after choosing a file, we now do that directly from the file chooser.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The create-folder machinery doesn't handle that case yet; we may enable it later
once we figure out the implications for the GUI.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
It used to be that every part of the file chooser's code would show/hide the widgets
near the pathbar as needed. Now we have two central functions:
path_bar_update()
path_bar_set_mode()
These take care of all the widget shuffling; setting the visibility of the
pathbar, info bar, and Create Folder button as appropriate; setting the contents
of the info bar, etc. - based on the current operation_mode and action.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
We will centralize the place where all the pathbar-related widgets are created:
the location button, the pathbar itself, the Create Folder button, and in
subsequent commits, the info bar as well. We will deal with the pathbar/infobar
as a unit, instead of swapping them in and out in an ad-hoc fashion.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since the GtkFileChooserEntry already gets the recent-folder set upon it when a recent-folder
is selected, it already can give us the correct fully-formed path.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
They weren't being selected in the shortcuts bar when those modes were
activated programmatically, instead of through the user selecting
them from the user interface.
In RELOAD_EMPTY mode, when no folder has been selected by the calling app, we now
start showing the recently-used list. The rationale is as follows:
- In Open mode, the user is likely to pick a file he has used recently.
- In Save mode, the user is likely to want a destination folder which
he has used recently.
For the Save case, where we want to present the user with recent folders instead
of recent files, we will make the recent-list do so in subsequent commits.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Now we reparent the browse_path_bar_hbox to that spot in Save mode,
or to be above the file lists in Open mode. The pathbar makes for a very
clear indication of the location to save in.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
And with this we get rid of the craziness of having a separate filter model
for the combobox's model.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This effectively makes the file chooser always be in 'expanded' mode.
Later, we'll move the pathbar to the 'Save in folder:' line.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
If the user pressed Enter to confirm the file chooser while the filename entry
was empty, then gtk_file_chooser_default_should_respond() would go back and forth
between the cases for handling the filename entry and the file list.
Introduces a 'last-folder-uri' GSettings key, where we remember the last-opened
folder from the previous instance of the file chooser.
The idea is that this works globally, across all applications, so it will be
easy to do things like
1. Save an attachment from a mail (or some other file)
2. Open another program
3. Do File/Open and automatically get sent to the folder where (1) happened.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=644426
The model_cancellables have an extra ref when we get them from gtk_tree_model_get().
So, we need to unref them always. On the other hand, the cancellables that get
passed as arguments to the callbacks in question are memory-managed by
GtkFileSystemModel.
Reported by Morten Welinder <mortenw@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=646460
Async callbacks are delivered in idles, so we need to make sure
we get the gdk lock before calling any gdk/gtk stuff. This was
missing in a few places.
We were breaking prematurely out of the loop that goes through
each file that is pending selection; not only does that loop
disable filtering and show hidden files if needed, but it also
selects the files themselves. So we need to walk the whole
list of files.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=643170
The logic was to try to switch to that nonexistent folder and thus get
an error message presented. However, no such message actually appears,
as the file chooser tries to switch to the closest parent folder that
actually exists, without bringing up an error message --- this is done
to cope with the case of the file chooser being started with a folder
that doesn't exist anymore.
Now, we just bring up an error message directly when we detect that
the user types a subfolder name that doesn't exist.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This involves checking the toplevelness of new toplevels before connecting
but not the *old* ones for disconnecting signals. Also take care of handling
a row_reference that becomes invalid over the course of reparenting the
filechooser into another parent.
