Now that filters may affect sensitivity of rows, we need
to clear the sensitivity column from the cache when the
filter changes. This fixes the problem where selecting a
different filter does not update the sensitivity of folders
until you change directories.
It bothers me that we call gtk_file_filter_filter(), then negate the result,
and the return *that* from node_should_be_filtered(). So, rename 'filtered'
throughout GtkFileSystemModel to 'filtered_out' to mean things that didn't
pass the filter.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
In particular gtksettings.h and gtkstylecontext.h needed to be included
in lots of places now.
Also, I order the includes alphabetically in a bunch of headers.
The new version does not need to muck with the entry, it just extracts
the required information. It returns a reference to the folder though,
as we extract the information now instead of returning something stored.
It used to be that _gtk_path_bar_set_file() would return an error if
it wasn't able to switch to the specified file, but that hasn't been
the case for a long while now, since the file chooser became async.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Add _gtk_button_event_triggers_context_menu() and use it instead
of checking for event->button == 3, so context menus are invoked
correctly on the Mac.
This will take you to the file's folder and select the file in question.
The menu item is only available in Recently-used and Search modes, so that
you can go from files in them to the 'normal' browsing mode.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
There's no real asynchronicity going on, anyway, so let's do both within
a single iteration of the idle handler.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
The mtime from GtkRecentManager may not the same as the file's actual
mtime, so the final result could appear unsorted to the user. Instead,
we will let the view do the sorting.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Years ago, when the location entry only appeared in a popup window, it used to appear
populated with the current folder's path. We had some logic to do this, but since now
the location entry appears in the main dialog, we can do away with that old code.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
This way we can re-create the contents of that box easily without disrupting
the rest of the file chooser.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
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.
GtkFileChooserDefault watches the toplevel and montitors "set-focus"
signal on it... however the connection needs to be remade when the
GtkFileChooserDialog is in an embedded toplevel.
Measure's taken: GtkWindow propagates hierarchy changes when
_gtk_window_set_is_toplevel() is called, gtk_widget_unparent()
unsets the widget's parent window earlier in the function so that
the possible hierarchy change is still able to properly access the hierarchy.
GtkFileChooserDefault checks if the "new" toplevel is indeed
gtk_widget_is_toplevel() but not the old one, GtkRange has been
updated to use gtk_widget_is_toplevel() inside it's hierarhcy_changed
vfunc, other classes already do this properly.
