Commit 4a3742979d which removed
GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER slipped
a bad g_assert() refactoring, which is causing
a crash when selecting a folder in a GtkFileChooserButton
dialog.
Fixes#2635
which could happen after confirming the "file overwrite"
dialog and may result in a different file being overwritten
causing data loss.
The oblivious file selection can be done by a mouse
click or keyboard press sent inadvertently just after
confirming the "file overwrite" dialog (and before the
enclosing GtkfilechooserDialog is closed).
Fixed by adding a flag to ignore any button/key press
events sent to the file list. We set this flag just
after the user accepts the "file overwrite" dialog (which
means the enclosing GtkfilechooserDialog is about to
get closed). And we restablish the flag when the dialog
is shown again (in its map() handler).
Fixes data loss issue #2288
We don't really have an event anywhere close in most
cases, and we already pass GDK_CURRENT_TIME in half
the cases anyway.
If we want to be serious about this, we need to pass
the event itself, since future focus-stealing protocols
may not rely on just a timestamp.
After the :can-focus change in the previous commit, widgets
need to set suitable focus and grab_focus implementations
to implement the desired focus behavior.
This commit does that for all widgets.
This is a huge reorganization of GtkDropTarget. I did not know how to
split this up, so it's unfortunately all one commit.
Highlights:
- Split GtkDropTarget into GtkDropTarget and GtkDropTargetAsync
GtkDropTarget is the simple one that only works with GTypes and offers
a synchronous interface.
GtkDropTargetAsync retains the full old functionality and allows
handling mime types.
- Drop events are handled differently
Instead of picking a single drop target and sending all DND events to
it, every event is sent to every drop target. The first one to handle
the event gets to call gdk_drop_status(), further handlers do not
interact with the GdkDrop.
Of course, for the ultimate GDK_DROP_STARTING event, only the first
one to accept the drop gets to handle it.
This allows stacking DND event controllers that aren't necessarily
interested in handling the event or that might decide later to drop
it.
- Port all widgets to either of those
Both have a somewhat changed API due to the new event handling.
For the ones who should use the sync version, lots of cleanup was
involved to operate on a sync API.
This might happen for slow filesystems where a fast-content-type might
be provided instead. Don't try to manipulate that content_type if it's
NULL, otherwise we'll either throw warnings (at best) or crash (at
worse).
Conflicts:
gtk/gtkfilechooserwidget.c
It is enough to just set the parent (and make the parent
call gtk_native_check_resize in size_allocate).
This commit removes the relative_to argument to the
constructors of GtkPopover and GtkPopoverMenu, and
updates all callers.
The preview widget harks from a platform before time, when we didn't
have GIO, or a thumbnail specification.
Very few applications use it correctly, if at all; it has an horrid hack
to deal with the ownership of the widget's instance when accessed
through the getter function; it messes up the layout of the widget and
its label is less than useful when it comes to file names longer than a
dozen characters; it's a poor substitute for a proper thumbnail view.
GtkFileChooser's API predates GIO by a few years, so it started off with
filenames and URI as character arrays. After introducing GIO as a
dependency, the API included GFile-based entry points.
It's much more appropriate to use GFile everywhere, as we want to
encourage people to use GIO instead of passing random bytes to low level
POSIX API.
See: #2455
This is triggered by typing / or hitting Ctrl+L. Since we don't have a
visual indicator for this mode right now anyway, the reason for not
allowing it in recent mode cited in the comment just above the
early-exit is irrelevant.
Closes#2178
In GTK2, the filechooser was using a Paned, so switching between sidebar
and files list with the arrow keys didn't work (the slider would be
selected instead). So in
https://bugzilla.gnome.org/show_bug.cgi?id=161489 a crude hack was added
to make this possible.
Over the years the filechooser code has changed so that it now would do
this by default, yet the hack had been retained.
1. Rename the thing
2. Turn it from a signal to a vfunc
3. Pass the GtkCssStyleChange to it
We don't export any public API about the GtkCssStyleChange yet, it's
just a boring opaque struct.
The FileChooser ToolKit (fctk) had its own machinery to handle default
sizes which was completely busted and trying to marshal random numbers
through the widget hierarchy that maybe made sense in 2012 but don't do
now.
Get rid of it, just keep the dialog's GSetting - which funnily enough
used to be written by the dialog but written by the widget.
But that's fctk for you.
This is just not a feature we can support currently.
Doing it properly would require infrastructure for
a generalized :drag(sensitive) state highlighting
potential drag sites everywhere.
Creating a recent manager can be fairly expensive and we won't use it if
the widget is not visible or the recent mode has not been entered. Code
other places can already handle a NULL recent manager, so just create it
when entering the recent mode. And shove 25ms of startup time off the
widget-factory this way.
Delaying this by one frame by putting it in an idle just makes the code
more complex for no gain. The actual slow part is reading the
recently-used.xbel, which happens when creating the recent manager.
The value returned by gtk_widget_get_settings() depends on the widget's
display, so watch for notify::display instead of using (un)root for
this.
Fixes the warnings seen when show a file chooser from the inspector.
Because otherwise when the file list is sorted "by name"
and the new name causes the file to be re-sorted to another
row, the selection stays in the old row which is now
occupied by a different file.
Fixed by keeping track of the renamed file and revealing
it in the "row-changed" signal handler, which gets emitted
after a file is renamed.
Fixes issue #948
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.
