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>
None of the cases where _gtk_file_chooser_entry_set_base_folder() appear to require
the entry highlighting the file's basename. Doing the highlighting actually makes
things look weird in Save/Recent mode if you
1. type a filename
2. click on a recent-folder,
as right after (2) your filename would get its basename highlighted for
no apparent reason.
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>
This lets us do proper completion in GtkFileChooserEntry even when no base folder
has been set. Completion for relative paths won't work, as usual, as expected.
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>
Introduces a 'LastFolderUri' settings 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
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>
This extracts the parent folders from the items in the recently-used
list. We'll use it in the file chooser to present a list of
recently-used folders.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
At http://dev.laptop.org/ticket/10643 we are seeing that drag-and-drop
within the Sugar shell causes all of Sugar's custom keybindings to be
removed.
This is because gtkdnd tries to unbind XK_KP_Space, which (on my systems)
is resolved to NoSymbol by XKeycodeToKeysym(). NoSymbol has value 0,
the same as AnyKey, and XUngrabKey(AnyKey) is equivalent to unbinding
all possible keycodes.
Fix this by catching NoSymbol before binding/unbinding.
https://bugzilla.gnome.org/show_bug.cgi?id=652402
For client-side windows, we need to queue a repaint when the background
changes. For native windows, the windowing system does take care of it,
but client-side windows are our own, so we gotta do it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=652102
