This reverts commit 2ed533c3e1.
This also made the filechooser dialog not save the window size anymore,
which does not depend on the gtk_window_get_position() removal.
... when going between recent and browse. It just looks weird to have
this transition while the treeview model is just cleared/repopulated
without any transition.
along with a new 'type-format' setting that allows
to choose the output format for the "Type" column.
The options implemented for this setting are:
'mime' : Output from g_content_type_get_mime_type().
'description' : Output from g_content_type_get_description().
'category' : It uses the corresponding generic icon
of the mime type to group by categories (aka basic types).
This produces a more compact output than previous options,
and allows for type families to be grouped together, so eg.
after sorting by "Type" column, jpeg and png images will
be placed together, or the various types of archiver files
will also be grouped together.
This format was copied from and currently used by Nautilus
list view, so we also improve consistency with Nautilus.
Bugzilla entry for Nautilus implementation is:
https://bugzilla.gnome.org/show_bug.cgi?id=683722
The list of type families or categories can be checked on:
https://developer.gnome.org/icon-naming-spec/#mimetypes
This 'category' format is set as default.
Issue #362
We don't support that setting life-updating anyway. So, instead of
getting the value *every time we format a time*, get it once for the
filechooserwidget and reuse that value.
The old default of 148px doesn't work everywhere. Instead, pick a
default value of -1 and measure() the sidebar widget in the
filechooserwidget in that case. Other values >= 0 are still handled as
before.
Leave it to the ::hits-added handler to switch to the list of search
hits. This way we don't get a weird transition when the current search
didn't have any hits and the next one doesn't either.
Searches with hits still feel good.
Instead, use the new way of activating default.
I think most of the default handling in
GtkFileChooserDialog should be dropped, but
for now this keeps things working.
When hitting Escape in the location entry,
we were not moving the focus anywhere,
causing focus to be NULL, and key bindings
to stop working. The visible effect was
that Ctrl-L / Escape / Ctrl-L would not
get back to the location entry, as expected.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1851
When hitting Escape, the file chooser will go
into search mode, because the search entry
consumes the key to emit the ::search-stopped
signal. Recognize this situation and avoid
switching to search mode in this case.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1850
We were forwarding key events to the search entry
and unconditionally considered search started
afterwards. That is not correct, since things
like a Ctrl key press should not trigger search.
Fix this by only switching to search mode when
the event was actually consumed.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1829
This makes the search entry show up again
when I type. There is still some misbehavior
where the entry loses focus again, and Escape
does not work to exit search.
Change the reorder api to insert after a sibling,
so that moving to first place becomes reorder (... NULL).
And add a insert_after api that can replace the common
container_add / reorder_after (... NULL) combination.
Update all callers.
