Using a GtkBox to display a dynamic list requires us to manually add
and remove children, relying on the GtkContainer API, gone in GTK4.
Instead, we can use GtkListBox, which we can pass a model and let
it take care of creating and disposing of children for us.
After the GTK4 switch, we should probably replace it with GtkListView
to avoid the default behaviors of GtkListBox which we are adding
workarounds for.
The toolbar's UI definition is split among two files because we used to
have a NautilusContainerMaxWidth between them, which is not GtkBuildable.
With out custom container gone from the toolbar, we can simplify this,
while also reduce the usage of GtkContainer API, which is gone in GTK4.
We have been using NautilusMaxWidthContainer on the title widget in
order to set a size where it stops expanding and starts centering.
But we can achieve the same visual result (with default font) by
setting a the location entry's :max-width-chars to 88.
This is going to allow us to drop the custom container at a later
point, which is going to help wtih the transition to GTK4.
As a side effect, now the pathbar can grow beyond the max width if
neecessary to display more of a path. I see this as a nice bonus!
Build log contains deprecation warnings for gexiv2 functions.
Replaced `gexiv2_metadata_has_tag()` with
`gexiv2_metadata_try_has_tag()` and `gexiv2_metadata_get_orientation()`
with `gexiv2_metadata_try_get_orientation()`
Closes: #2033
I believe these are only included to prevent breakage of existing C
extensions, but as they're not intended for actual use we should mark
them with `(skip)`.
This has the added benefit of making the VAPI file generated from the
resulting GIR file much less noisy.
The button currently looks like a vertical pill, not a circle.
This is a regression from a2d5dafa05
Not using the GtkButton image API apparently requires us to add the image-button style class ourselves.
This is also gone in GTK4, so we should set the margin for all 4 sides.
In batch-rename-dialog.ui there is a case where :margin was set to 0,
which is the default, so just remove the tag in that case.
The "treeview-drop-indicator" style class was a thing in GTK2, but not
in GTK3. So, remove this old code which isn't even do anything visible
anymore. Also, the ::draw signal is going away when we move to GTK4.
Rebased and ammended by António Fernandes <antoniof@gnome.org>
This usage of GdkWindow is a X11'ism that's gone in GTK4.
Removing this doesn't seem to cause any visual or behavorial change at
the moment.
Rebased and ammended by António Fernandes <antoniof@gnome.org>
It's gone in GTK4 and removing this doesn't seem to cause any visual or
behavorial change at the moment.
Originally it was a workaround to some visual problem with button
shadows. Our pathbar buttons don't have shadows nowadays, and even if
testing with added shadows, there is no apparent issue nowadays.
Rebased and ammended by António Fernandes <antoniof@gnome.org>
It's gone in GTK4.
We get an icon from GMount. Assuming it's a GThemedIcon, so we can
simply get its first name and use gtk_window_set_icon_name() which is
still going to work in GTK4.
It's gone in GTK4.
Here it's used only as a fallback to a named icon.
Also, GNOME doesn't use window icons anyway.
So, just drop it to ease the port to GTK4.
It no longer exists, and the enumeration only contains normal and large
sizes, so hardcoded icon sizes are now used.
Rebased and ammended by António Fernandes <antoniof@gnome.org>
It's conveniently set as a property of GtkMountOperation, so there is no
reason not to pass both forward.
This is necessary for the preceding commit to actually work as intended.
Actually set the parent window, instead of juggling with GdkScreen,
which is going away with GdkScreen. Furthermore, parentless dialogs
should not exist, HIG-wise.
While we are at it, also remove gtk_window_set_skip_taskbar_hint()
which is going away with GTK4 too.
It's going away with GTK4.
Replace it with a GtkBox.
This will result in visual changes to the dialog, but the existing
visuals are outdated and a redesign is overdue anyway.
We are doing all GTK stuff from the main thread anyway. If we are not,
we are in big trouble anyway.
So, drop gdk_threads* API this in preparation for GTK4, where it won't
exist.
Rebased and ammended by António Fernandes <antoniof@gnome.org>
The templates submenu in the current location popover is recreated
every time the menu model is updated, but the old widgetry is never
destroyed.
This results in a memory leak and many warnings in the terminal output.
I couldn't find the root cause, after many investigations. However,
I've found that unsetting the model actually removes the old widgetry.
Let's do that as a workaround.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1705
Our AutoarExtractor::request-passphrase handler implements in invoking
the main context for the dialog from an operation thread.
This duplicates existing code that caters the same use case for the
file conflict dialog (using the `invoke_main_context_sync()` function).
Let's move the code handling of the password dialog into the
`src/nautilus-operations-ui-manager.c` file to make use of
`invoke_main_context_sync()`.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1829
