Again on massive filesystems, the very first character
is likely to bring a likewise massive amount of search
results that we need to maybe query info for, then create
icons and widgets for. While it's impressive we can do
that, it's also expensive and likely pointless, for the
first character.
Typing a second character is however very likely to
considerably reduce the amount of items to categorize and
show. So start actually searching from there.
Testing on a filesystem with 1434099 files indexed, trying 5
semi-random 1 character searches (n, h, t, i, o) returns on
average 168K items (min. 78771, max. 331471), trying 5
semi-random 2 character searches (no, he, th, in, on)
returns on average 34K items (min. 11133, max. 94961),
which is a more approachable set.
Doing this is enough that typing on a filechooser search
entry feels completely fluid.
The search provider should make it sure there are some
specific GFileInfo fields set. Fix the mimetype extraction
from the query, and use that to fill in the missing gaps
the best we can.
When starting a search over a very populated filesystem, it
is possible that typing the first chars will return a too
high number of results. Even though iterating through the
cursor is in itself very fast, extracting the GIO information
from those many files at once is not going to be as fast.
In order to increase interactivity (i.e. not make things
possibly sluggish) iterate the cursor in an idle function
and add search results to the filechooser model little by little.
If the user keeps typing (as it is likely will happen), there
will be better chances to cancel and proceed to the next
query timely. If not, the results will be there soon enough.
As fancy as property paths are, recursive resolution of files
to a location increases the big O complexity enough that it's
not a great option on large homedirs with many indexed files.
Ensure the files are from the right location through a URI
prefix match, which does hits an index. This may dramatically
improve performance on large indexed trees.
Testing this query in an isolated testcase with a total
1434099 indexed files shows that it can run more than 1500 times
per second in this computer (an average of 15200 queries in
several 10 second runs), which presumably is a tad faster than
anyone can type.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4133
Cursor themes have recently started to reduce their coverage of
'legacy' cursor names, and reduced to the standard names. Support
this for the few cursor types that are still used in GTK.
This package name was Ubuntu-specific, and was dropped since 45.0-4
(the Debian version of a-i-t has a Provides for a-i-t-full). Use a
versioned build-dependency so that we definitely have all of the
necessary icons to run tests successfully.
Thanks: Heinrich Schuchardt
Print backend can be disposed together with all its printers
as a reaction to user stopping enumeration of printers.
Adding a weak pointer help us to detect that the backend
was disposed and hence the backend and its printers should not
be used anymore.
Fixes#6265
The GtkFileChooserEntry widget creates a file filter instance, but never
sinks its floating reference. Newer versions of GLib correctly warn if
an instance with a floating reference gets finalized.
Fixes: #6527
This is mostly the GIR XML, which must be in an arch-dep package
as specified by the GObject-Introspection mini-policy. Keeping it
in /usr/share means that it can at least be shared between multiple
installed multiarch instances.
If at some point in the future we have another transition as extensive
as time64, then libgtk-3-0t64 could conceivably be replaced by some
other package, which I have modelled here as libgtk-3-0xyz. If that
happens, we need to avoid deletion of immodules.cache, otherwise we
will have another bug similar to #1065494.
This implementation is based on the assumption that third-party input
method modules for GTK 3 will depend on GTK 3, therefore we should not
need to clean up the IM modules cache unless/until we reach the point
of having no IM modules installed.
If at some point in the future we have another transition as extensive
as time64, then libgtk-3-0t64 could conceivably be replaced by some
other package, which I have modelled here as libgtk-3-0xyz. If that
happens, we need to avoid deletion of immmodules.cache, otherwise
we will have another bug similar to #1065494.
This test-case depends on several implementation details of dpkg-repack
and libgtk-3-0t64, so it might need to be adjusted in the future. As
a result, I have marked it as flaky, so that failures in the official
autopkgtest environment will not be considered a release-critical bug
that stalls migration and requires immediate intervention by maintainers.
During the migration from libgtk-3-0 to libgtk-3-0t64, the package
that is responsible for "owning" /usr/lib/*/gtk-3.0/3.0.0/immodules.cache
changed from libgtk-3-0 to libgtk-3-0t64. Because dpkg does not have an
equivalent of RPM's %ghost files, the ownership of this file is managed
by social convention rather than by the package management system.
Unfortunately, libgtk-3-0's postrm as shipped in Debian releases from
2010 to the present is not aware of the possibility that another binary
package might need to take over responsibility for this file, and so
will remove it during purge (and in fact also during upgrades) in
accordance with the requirement that the package must not leave unowned
files behind. This causes input methods to be non-functional in GTK apps
until the next time the gtk-query-immodules-3.0 trigger happens to be run.
To disarm the problematic maintainer script, delete it during the new
package's preinst, similar to what was done for GLib in response
to #1065022.
A subsequent commit will improve the postrm so that if we find that we
need to migrate from libgtk-3-0t64 to libgtk-3-0xyz at some point in
the future, similar efforts will not be needed.
Closes: #1065494
Based on the reproducer I added to src:glib2.0 for the similar bug #1065022.
This one is simpler, because only architecture-specific multiarch files
are affected.
