deed9bc...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
icon-info: Fix build
Previous commit relied on mixing declarations with code, which is not allowed with the build flags of this branch.
f4f353a...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
icon-info: Don't ask the theme for an icon it doesn't have
GtkIconTheme changed behavior from GTK3 to GTK4. Before, it would
return NULL for a non-existent icon. Now it returns a non-scallable
`image-missing` icon.
But our icon info code still relies on NULL icon to set a fallback.
The documented solution to get the old behavior back is to call
gtk_icon_theme_has_gicon(). Let's just do that instead.
Also use a more generic fallback icon that's been available in
adwaita-icon-theme for a few versions before our GTK4 port.
87c942b...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
list-base: Stop jumping to top on Menu key
Pressing the Menu key while the view is scrolled down causes the view
to jump up, which shouldn't happen.
This happens because of a faulty reimplementation of an edge case
handling in the GTK4 port. It's utterly broken and it's my fault.[0,1]
- The index from the selection filter model is wrongly applied
to scroll the view (as if it was the index of the unfiltered
model);
- If the `for` loop runs until the end, the `i` is not the
index of the last item: it's the length of the filter model.
- For list view, the focus child is the inner list view, not
the cell's parent, so this logic would work only in grid.
The first two points are fixable using GtkBitset instead of
GtkSelectionFilterModel, but the last point means this would
still not work under list view.
The proper solution requires a way to query the focus position,
which doesn't exist (yet? [2]).
Let's give up on the smart handling of corner cases and just get
the common case right. Even in the corner cases, this simple
solution is not too bad.
(cherry picked from commit 59c43786dc341b46cc9f491749193e679f78d5de)
a182264...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
list-base: Allow popover focus
We intercept focus tabbing before passing it to children in order to
emulate the tab behavior that would be introduced in gtk 4.12. But
this was really only meant to affect the content.
Instead it's affecting popovers attached to the view as its children.
So, adjust the logic to check the ancestor is the content widget.
7b34907...
by
=?utf-8?q?Ant=C3=B3nio_Fernandes?= <email address hidden>
preferences-window: Don't crash on reuse
Once upon a time, in a faraway spatial file manager land, there was a
way to open multiple preferences windows at once. Everytime a person
launched the "File Management Properties" from the system menu, a new
preferences window would always be spawned, even if there was already
one such window open. [0]
Back then, the preferences window was not modal and could be launched
even while there was no nautilus (excluding the special desktop one).
One day, a powerful wizard resolved this by summoning the existing
preferences window instead of spawning more.[1] Peace had returned to
the GNOME 2 land.
But the winds of change blew strong with GNOME 3. Desktop icons were
exiled to the hidden configurations and spatial file manager became
a myth of old, as the app-centric rule solidified. In that world,
Preferences became modal dialogs.[2] The preferences summoning spell
was still effective, but now had an unintended side effect: raising
the parent window along with the existing preferences dialog, even
summoned from another window. But this was nothing serious so nobody
even noticed it.
The spell turned into a curse due to the GTK 4 lifecycle changes.[3]
A closed Preferences window becomes a ghost window, lingering onto
its original parent window. Be warned: those who dare summon the
Preferences ghost once its parent window is gone, shall be crashed!
Henceforth, when opening Preferences, an existing window (either alive
or undead) shall be exorcised, before a new window is spawned with
from a new parent.
When the gtk list view is in the process of being destroyed, some of the
cells might still exist with an invalid reference to the nautilus view.
We are having an problem where the double click idle timeout from the
gesture click on the nautilus-view-cell times out when the view-cell
hasn't be freed but the nautilus view has. A good way to test this is
by clicking an item immediately followed by ctrl+w to close the tab
(freeing the view).
I played around with trying to get the gtk list view to free earlier
in the process (i.e. before the nautilus list base), but there were
still instances where the cell still existed by the time the nautilus
view was freed.
To be safe, make the unowned nautilus view a weak pointer of the
nautilus view cell so we can safely check for NULL values.
