gtk_file_chooser_get_filter Make gtk_file_chooser_get_filter work for the non-portal GtkFileChooserNative (issue #1820)
See merge request GNOME/gtk!1959
`gtk_builder_get_parameters()` is a hot path, being called twice for
each object in each UI file in an application. The majority of objects
have ≤ 8 properties, which are each filtered into either `parameters` or
`filtered_parameters`.
Unfortunately, both of those arrays are created as empty `GArray`s, and
adding 8 elements to an empty `GArray` hits the worst possible case of
reallocating and `memcpy()`ing the array 3 times. As the array size is
doubled with each reallocation, the cost is not particularly well
amortised when the array size is small.
From the `ObjectInfo`, we actually know how many properties there are in
total, so just allocate the arrays at the right size to begin with.
This saves 7% of the instruction cycles needed to start up
gnome-software to the point where it’s showing its main window,
according to callgrind. gnome-software is making around 5500 calls to
`gtk_builder_get_parameters()`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This makes 'gtk_file_chooser_get_filter' work for the
portal native file chooser by handling the corresponding
'current_filter' argument in the response retrieved via
D-Bus.
In order to try to map the retrieved 'current_filter' to one
of the existing list of filters, use the retrieved filter's name,
similar to how xdg-desktop-portal-gtk does it when evaluating the
'current_filter' input parameter in 'options'.)
Note: This depends on the following merge/pull requests
which fix the filter handling in gtk for native file choosers
and introduce the 'current_filter' handling for FileChooser portal.
* https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1959
* https://github.com/flatpak/xdg-desktop-portal/pull/493
* https://github.com/flatpak/xdg-desktop-portal-gtk/pull/311
This fixes#1820 for desktop portal case.
Fixes: #1820
Before I tried this change, I thought it might break apps that do
transparent window background. So I checked a few that did this:
gnome-terminal, tilix, kgx. It worked, so it must work everywhere, right?
However, it just so happens that vte is drawn using CAIRO_OPERATOR_SOURCE
operator rather than CAIRO_OPERATOR_OVER like everything else. This means
that if vte widget is transparent, anything below it, like a black
decoration background, won't be shown.
So really it is still broken, so reverting it.
'gtk_file_chooser_get_filter' did not work for GtkFileChooserNative,
since the previous way did not properly handle the delegate dialog,
s.a. commit a136cbae8f
("filechoosernative: forward current_filter to delegate dialog",
2018-11-29) for details, wich basiscally fixed the same thing for
the 'gtk_file_chooser_set_filter' case.
This fixes#1820 for the fallback dialog. A solution for the portal
one (which also requires changes to xdg-desktop-portal and
xdg-desktop-portal-gtk as well) will be suggested in a subsequent step.
Bug: #1820
Trash monitor queries info from gvfsd-trash after each file monitor
change which can be problematic when too many changes happen in
a short time. Let's rate limit the number of queries...
Fixes: #1010
- Remove various unnecessary overrides for linked buttons.
- Add missing outline styles to the %linked_vertical ones.
- Consistently use :not(.vertical) instead of :dir(ltr|rtl) for linked
combo buttons.
- Remove :only-child styling from the messagedialog button. The
:only-child is equivalent to :first-child:last-child, so we don't need
the styling there specially.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2752
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/2549
Provide the minimal info necessary. Improves apparent responsiveness
(since we don't visibly clear and repopulate the list) and saves doing
file stat/reads on every file in the result set.
The filechooser tries to figure out whether it got results by poking
the model, but all files might go through the async GFileInfo querying
state.
Make all search engines (and the composite one) just notify about this
fact, so the file chooser can behave appropriately without waiting for
the async operations to finish.
Once upon a time, there was a function called gdk_event_get_scroll_deltas().
It returned %TRUE when an event had scroll deltas and that was used as the
condition to decide whether to push scroll deltas to the scroll history,
even when the both deltas are 0 for the stop event at the end of scrolling.
When GtkScrolledWindow kinetic scrolling code was adapted for
GtkEventControllerScroll, it was replaced with a (dx != 0 && dy != 0)
check. This prevented the stop event from getting into the history, and
instead allowed non-smooth scrolling to affect the history as they have
synthetic deltas with one of the values being -1 or 1 and the other on 0.
Instead, check the direction as we already have it as a local variable.
To avoid making this mistake again, add a static assertion that the
enum is in sync with gtk_license_info, and use the length of
gtk_license_info for the precondition check.
Signed-off-by: Simon McVittie <smcv@debian.org>
Resolves: #2734
On touch, the popup shown shall contain the 'select-all' button
only if a selection is in progress and if the entry is editable.
Let the button be shown always if selectable so that it’s more helpful.
When the code for this was copied from nautilus,
we forgot to adapt it for running in a library
instead of an application - gettext() doesn't work
in a library.
Fixes: #2690
Commit 07beb6dba2 made GtkAppChooserWidget useful with no content-type,
however when used in a GtkAppChooserDialog, this will lead to a confusing
"Opening (null) files" subtitle.
Fix this by omitting the subtitle altogether in that case.
This is a possible fix for https://gitlab.gnome.org/GNOME/gtk/-/issues/2657
Use a NULL return from g_file_query_info_finish() to detect cancellation
of the query, and avoid derferencing a stale pointer.
'window' is not the only toplevel css name, there are also 'dialog' etc.
Move it before .solid-csd style so that .solid-csd background takes
precedence.
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.
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
This comment was added in 93bcca7f02 but missed a
colon so it never actually generated documentation and the nullable annotation
never made it into GObject-introspection language bindings.
This crude regex does not catch any other instances of this mistake. The @
symbol is used to disambiguate signal doc comments from property doc comments,
since property docs usually don't have parameters.
$ pcre2grep -rM '\\* [A-Z][A-Za-z]*:([a-z\-]*):\n +\* @' gtk/
Various files are in git but not in dist tarballs. Some of them look
like potentially useful references for downstream distributors.
Signed-off-by: Simon McVittie <smcv@debian.org>
