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.
Since the function is usually called from GtkWidget::drag-{begin,end} handlers,
taking a GdkDrop does not work, especially given that
::drag-action-requested is emitted without checking the type.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1220
This is an automated change doing these command:
git sed -f g gtk_widget_set_has_window gtk_widget_set_has_surface
git sed -f g gtk_widget_get_has_window gtk_widget_get_has_surface
git sed -f g gtk_widget_set_parent_window gtk_widget_set_parent_surface
git sed -f g gtk_widget_get_parent_window gtk_widget_get_parent_surface
git sed -f g gtk_widget_set_window gtk_widget_set_surface
git sed -f g gtk_widget_get_window gtk_widget_get_surface
git sed -f g gtk_widget_register_window gtk_widget_register_surface
git sed -f g gtk_widget_unregister_window gtk_widget_unregister_surface
git checkout NEWS*
Now that subtitle's default value "Searching" for OPERATION_MODE_SEARCH
is duplicated as it should be, we cannot reassign other strings to it
anymore, as that resulted in the original dupe of "Searching" leaking.
Fix this by only assigning the dup'd "Searching" after trying to get
more specific values, not before. We therefore need to set it to NULL
during its declaration, and that means we needn't in the final else.
Having a FileChooserDialog in location-entry mode then pressing
<primary>f to move to search mode would crash with an invalid free().
In that case, FileChooserWidget.get_subtitle() returned a static string
straight from gettext. This crashed when the GBinding from :subtitle to
FileChooserDialog’s HeaderBar:subtitle shortly tried to free the string.
Fix by duplicating the string before returning it, like all other paths.
https://bugzilla.gnome.org/show_bug.cgi?id=791004
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
GDK has a lock to mark critical sections inside the backends.
Additionally, code that would re-enter into the GTK main loop was
supposed to hold the lock.
Back in the Good Old Days™ this was guaranteed to kind of work only on
the X11 backend, and would cause a neat explosion on any other GDK
backend.
During GTK+ 3.x we deprecated the API to enter and leave the critical
sections, and now we can remove all the internal uses of the lock, since
external API that uses GTK+ 4.x won't be able to hold the GDK lock.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_timeout() and
gdk_threads_add_timeout_full() exist is to allow invoking a callback
with the GDK lock held, in case 3rd party libraries still use the
deprecated gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing timeout callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_idle() and
gdk_threads_add_idle_full() exist is to allow invoking a callback with
the GDK lock held, in case 3rd party libraries still use the deprecated
gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing idle callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
This replaces the use of ::button-press-event. There's two
issues with this commit:
1) We don't have a good way to do the equivalent of
gdk_event_triggers_context_menu with gestures
2) We have to defer to and idle to avoid ordering
issues with the treeviews own gestures
This is a bit of filechooser internals that gets shared with
nautilus, which is fine, but it shouldn't be part of our
public API. There are no other users than nautilus.
This API allows specifying a GType and va_args of a value of that type
to set the clipboard contents. This massively simplifies setting weird
object types into the clipboard.
2 example patches included in this patch are the GtkTextBuffer and the
file list in the file chooser.
Using gobject-introspection, this should work without specifying the
type, so that you can literlally say
clipboard.set ("Hello World")
or
clipboard.set (pixbuf)
which is why I've also marked all other setters as (skip). They just
exist in C as wrappers for type safety reasons.
This is in preparation of using input streams to show that these
coordinates aren't needed most of the time and can otherwise be saved
during GtkWidget::drag-drop.
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
Change constructors to reflect that.
While doing so, also add a fallback argument to the cursor constructors,
so it is now possible to create cursors with fallback.
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.
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
Showing all the different errors and warnings when renaming and creating
files/folders without potentially resizing popovers on every keystroke
requires us to know the size of the error messages beforehand, so pack
all of the possible error messages and warnings in labels and those into
a stack. This way we can also neatly crossfade transition between them.
https://bugzilla.gnome.org/show_bug.cgi?id=775636
When filechooer is re-used (instead of being created and destroyed
every time it's needed), it might happen that the directory the
application wishes to initially show is the same directory that
was shown last time the filechooser was used. In that case, make sure
filechooser knows that it does not need to do its default "select $pwd
or $home" routine.
https://bugzilla.gnome.org/show_bug.cgi?id=766122
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add a new signal with an open flags parameter and deprecate
the other-location signal.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add the signal missing parameter in order to allow it.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
With the location entry up in the header bar in save mode, we can
end up with the search model being in use when the user types in
the location entry. In this case, we don't make the Save button
sensitive as we should.
Having two entries in the dialog is somewhat confusing anyway,
so just stop the search when the user starts typing in the location
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=761757
Calling _gtk_file_consider_as_remote() with a NULL argument
results in warnings being thrown.
Note that query->priv->location being NULL is a state that does
not seem to be invalid by itself.
This could happen if you do search-as-you-type in a filechooser,
which has a filter that does not match anything *and* the current
"place" selected is "Recent".
https://bugzilla.gnome.org/show_bug.cgi?id=761552
Since 39c2d12330,
priv->operation_mode == OPERATION_MODE_BROWSE no longer
guarantees that priv->browse_files_model is the current
model of the list - we are only switching the models after
loading the new directory. Avoid triggering the assertion
in show_and_select_files by checking if we have right model
before calling it.
https://bugzilla.gnome.org/show_bug.cgi?id=761209
In some situations (no header bar, save mode), hitting Escape
would not do anything because the entry ate the key event.
Fix this by telling the entry to only handle Escape when there
is something to do, such as switching back to the path bar.
https://bugzilla.gnome.org/show_bug.cgi?id=761026
Commit 8e975b2 (Bug 753969) introduced check of parent accessibility.
Consequently it is not possible to save file if executable attribute
is not set, which might happen for some gvfs backends. Let's assume
that the folder is accessible even if the attribute is not set.
https://bugzilla.gnome.org/show_bug.cgi?id=760881
Since we are now interpreting button press events and
make our own double-click determination, we should not
handle double-click events that are generated by GDK.
https://bugzilla.gnome.org/show_bug.cgi?id=757950
When the search entry is shown, the 'special' nature of
., ~ and / should not trigger the location entry, because
that interrupts the search and is likely not what the
user intended.
https://bugzilla.gnome.org/show_bug.cgi?id=756505
Move focus to list when search results appear to make it
possible to select the first search result by just hitting
Enter. To keep this from interfering with keynav, we need
to make sure that we still handle Escape to search. And when
search comes up empty, we need to move the focus back to the
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=755926
The stack calls gtk_widget_grab_focus on the last focus widget,
which selects the text in the entry, so we need to make sure to
move the focus there first to keep that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=755931
When right-clicking in an empty folder, you should get a context
menu, not a crash. The code for positioning the popover was not
handling the eventuality of no row under the pointer. Just position
the popover right at the click location in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=755021
If we manually enter an unaccessible path in the entry, e.g
"/root/foo.txt", we should receive an error saying that the
folder is not accessible instead of showing the replace
confirmation dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=753969
We only load thumbnails when we find that the row is in the visible
range of the treeview. It seems that animated scrolling makes it so
that the bottommost row stays out of the visible range until it is
too late. To work around this, extend the range by one row in each
direction.
http://bugzilla.gnome.org/show_bug.cgi?id=753142
Interpret a unmodified primary click on the selection like a double
click. This makes it possible to activate a file or open a folder
without using double-click.
Make GtkSearchHit carry a GFile instead of an uri. Most of the
search engines already have the object around, and converting
to an uri and back is unnecessary extra work.
It is a bit pointless to have the file chooser get a uri from an
existing GFile to put in the query, only to have some of the search
engines reconstruct a GFile from it.
