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
Adds file comparison based on actual file type, rather than generic
type category. For example .jpg and .png files will now be sorted
into two different groups.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1776
Signed-off-by: Rajat Jain <rajatjain.ix@gmail.com>
Commit 38803058cb introduced calls to
gtk_widget_show_all(), which causes the 'Rename' button to appear prematurely
when the dialog is created. Fix this by using gtk_widget_show() instead.
Take this opportunity to modify the call when creating the app chooser dialog
too as gtk_widget_show_all() doesn't exist in GTK 4.
"Copy To" or "Move To" dialog starting from the current location.
However, if the current location is starred://, GtkFileChooserDialog
prompts an error message "The specified location is not supported".
Instead, while in the Starred location, use the actual parent of the
selected item as a starting location for the "Copy To" dialog.
Fixes: #1243
Turn potentially infinite while loops into for loops with finite
amount of repetitions. In general 1000 tries should be sufficient,
so the chosen amount of 100.000 serves as an upper limit.
See https://gitlab.gnome.org/GNOME/nautilus/-/issues/1290
Remove usage of properties that are gone in GTK4, such as border-width.
Also, move the "Pattern:" label above the entry, drop the colon and
make it bold.
Now the Ctrl+S dialog is being built using the
GtkBuilder API, Now it's styling and can be
handled in the XML UI definition. The UI definiton
needs to be handled manually as Glade doesn't handle
the implementation of the GtkDialog used here.
invoke_main_context_sync() wraps the boilerplate needed for the file
operations thread to trigger UI dialogs and wait for their feedback.
It assumes that the UI task is completed by the time the invoked
function returns. This assumption presumably stems from the expected
usage of gtk_dialog_run().
However, gtk_dialog_run() is gone in GTK 4, so we should stop making
that assumption. Let's introduce an explicit way to signal that the
task is completed, such that it can be used either before or after
the wrapped function returns.
This will enable us to drop gtk_dialog_run() later. It will also
help with https://gitlab.gnome.org/GNOME/nautilus/-/issues/1829
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.
Also, while we are at it, move some object unreferencing from
.finalize() to .dispose(), which is where we should do it.
GtkButton lost its GtkImage-related API in GTK4, and should be used as
a regular container.
Note #1: In x-content-bar.c, this requires using gtk_box_pack_start()
and gtk_container_add(), which must later be replaced, respectively,
by gtk_box_preopend() and gtk_button_add_child() when switching to
GTK4. However, it's worth refactoring the code in advance such that
we can simply find and replace funciton calls later.
Rebased and ammended by António Fernandes <antoniof@gnome.org>
They need to be shown by code anyway. This prepares for GTK+ 4, where
widgets are shown by default unless explicitly hidden.
Rebased and ammended by António Fernandes <antoniof@gnome.org>
