Just as the error, warning and question dialogs, the FileConflictDialog
may also pop up unexpectedly during a lengthier operation.
The same idea of the previous commit is applied here.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1988
Warning, error and question dialogs may pop up unexpectedly during
lengthier operations and the user may end up selecting an unwanted
action.
This patch introduces a delay of 2s for dialog activation when
the total elapsed time of the job that created the dialog is
greater than 2s.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1988
It's gone in GTK4.
Anything we are doing on ::destroy can be done on ::dispose().
Extra care must be taken, however, because GObject.dispose() may be
run multiple times; for this reason, move some things to .finalize().
This reverts commit 1c83d6af8b.
It did a little to much and this introduced at least one bug: when
going from a regular folder to other-locations:///, the current view
menu keeps displaying invalid actions (New Folder, Properties, etc.),
which, if activated, crash the application.
Let's revert first and do it right in the next commit.
GTK discourages subclassing widgets.
The only reason we are subclassing here is to add struct fields. But we
don't need to subclass a widget for that. We don't even need to subclass
GObject. A plain data struct is enough.
GtkContainer is gone in GTK4.
Use per-class child-adding methods. For the cases where such methods
are unavailable in GTK3, introduce small wrapper functions with the
same signature as the GTK4 methods, to help with the transition.
The only action we need is to stop loading.
The code to cleanup actions relies on GtkContainer API, gone in GTK4.
So, specialize the code on the stop button.
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.
