This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Consider this bug:
1. Open a file chooser; switch it to $HOME
2. Start typing "~/Dow" with some file that *does* exist in your $HOME
3. Delete the inline-completion selection (e.g. the "nloads" after "~/Down").
4. While you are at "~/Dow_" hit Tab. No completion will occur.
This happens because of the following.
Say the GtkFileChooserEntry is in the process of loading $HOME,
because _set_base_folder() was called. If the entry contains no text,
then the FULL_PATH_COLUMN of the file system model will be set to
unprefixed filenames from $HOME, like
.ssh/
Documents/
Downloads/
somefile.txt
Later we avoid reloading the folder if g_file_equal(old_folder, new_folder).
However, the FULL_PATH_COLUMN gets populated in completion_store_set()
out of the actual filenames that GIO returned, plus the chooser_entry->dir_part.
If the user starts typing "~/Dow" then dir_part changes to "~/", *but*
the folder won't be reloaded since it is also $HOME. However, the completion
machinery assumes that FULL_PATH_COLUMN will contain prefixed entries like
~/.ssh/
~/Documents/
~/Downloads/
~/somefile.txt
So, we add an invariant that chooser_entry->dir_part and
chooser_entry->current_folder_file must change at the same time, and
must not get out of sync: If any of them changes, then the
completions are regenerated.
Make sure entering the three special strings ".", ".." or "~" in
the location entry works as expected. They already worked correctly
if you append a '/' to force them to be recognized as the 'folder'
part, but that should not be necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=752707
Make the file chooser entry optionally capture Escape
and emit a signal. Make the file chooser widget hide the
entry on that signal and go back to the path bar.
This gives us a two-level undo:
location entry -> path bar -> dialog close.
When the location entry is permanently displayed in the
header for save mode, we still let the first Escape close
the dialog.
When the file chooser changes directories, it tells the GtkFileChooserEntry to
change its base folder (i.e. the folder from which relative pathnames are resolved).
GtkFileChooserEntry then starts loading a GtkFileSystemModel asynchronously.
In the finished_loading_cb(), however, it would always ask the GtkEntryCompletion
to insert the completion prefix, since that finished_loading_cb() is what is also used
while the user is typing *in the entry*.
But when the entry doesn't have the focus (e.g. the user changed directories by double-clicking
on the file list in the file chooser), there's no reason to insert completions at all.
https://bugzilla.gnome.org/show_bug.cgi?id=672271
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Since FUSE locations can be handled safely by applications show these mounted locations regardless of whether gtk_file_chooser_set_local_only()
is set to TRUE
https://bugzilla.gnome.org/show_bug.cgi?id=586367
Instead of in the key_press handler, use a signal handler. The signal
handler runs before the default handler, and before other signal
handlers. In particular it runs before the signal handler installed via
gtk_entry_set_completion() which pops down the entry completion, and we
don't want that to happen.
The code does not change the code of the handler in any significant way,
it just refacotrs it to not call the parent anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=663573
This was removed previously, but is necessary to support the case where
no base folder is in use, which should cause an error. This can be
experienced in save mode in the recent files list.
https://bugzilla.gnome.org/show_bug.cgi?id=663573
That way, we can use the regular filtering features of the
filesystemmodel instead of having our own filtering function that
duplicates much of the matching code.
This also removes the broken-on-windows feature where files strting with
a dot were not autocompleted.
Use all the clever functions we invented in recent refactorings to
compute the file and dir part and the current folder.
This also fixes the bug where "./" was not taken as the current
directory but interpreted as a file named "./".
This returns the text that should be completed on. As this is somewhat
tricky to compute (and in fact one place did it wrong), let's make it a
function.
Now that we don't need to know anymore why insertion failed, we can
simplify the append function quite a lot.
A simple rule now: If we did not insert anything, beep.
Too much special code for no gain.
I did a totally unscientific questionnaire on GNOME IRC (assuming
autocompletion is for advanced users) and nobody even knew what this is.
So I suspect it's useless. Also, it's positioned completely wrong anyway
and nobody noticed so far. Last but not least, I'm trying to imitate
bash here and bash doesn't show feedback.
Use dispatch_properties_changed() instead of GtkEditable to watch for
changes to the to-be-completed text. This is necessary because various
functions in GtkEntry don't use the interface vfuncs and one only
becomes aware of them via notifications. I'm not sure this is intended
behavior, but it's how it works today.
Also, use the same code for triggering in all situations.
What the code does is this: It looks at the part of the text in front of
the cursor (or selection) and completes for it. Once the directory has
been enumerated, inline completion is activated. Note that popping up of
the completion popup is completely handled by GtkEntry.
