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.
It is at least theoretically possible that gtk_entry_get_pixel_ranges
will return no ranges, and we should handle that without an
out-of-bounds access or segfault.
This fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1871627
All GTK3/4 apps on non-GNOME desktops aren't resizable if they are
tiled.
This patch makes the non-tiled edges resizable if we have per-edge
tiling, but not per-edge resizing information.
We might want to make all edges resizable, but that might not be fine
for tiling compositors.
The first time this function is called, has_xdg_output() returns
true, but haven't yet received all the xdg-output events, so wait
for that to be done. Otherwise, the logical size is 0, and nothing
useful comes from that.
This is the gtk3 version of !6722.
This fixes a problem that is apparent in
https://bugzilla.mozilla.org/show_bug.cgi?id=1869724, but that also
reproduces on any GTK application as described in
https://bugzilla.mozilla.org/show_bug.cgi?id=1869724#c16.
xdg_output sizes might be physical if the compositor doesn't scale them,
it seems. So to report the correct logical geometry in GDK pixels, we
need to detect this case. We do this by checking whether the wl_output
size matches the xdg_output size.
