Currently, list view doesn't use thumbnails for its first zoom levels:
SMALL (16px) and STANDARD (32px). So, it does display thumbnails for
LARGE (48px) and LARGER (64px). On the other hand, the icon view uses
displays for all zoom levels, the smallest being 48px.
In short: thumbnails are displayed for zoom levels that request an
icon size of 48 logical pixels. So, the minumum size of thumbs is 48px.
This is implemented by checking that the current icon size is equal to
or lower than NAUTILUS_LIST_ICON_SIZE_STANDARD (32px).
However, we are going to need to check this condition in other places,
so it would be best to have a constant specifically for this purpose.
For the sake of naming this constant reasonably, let's use the minumum
size of 48px and update the condition checking accordingly.
We want the text of all columns to be dimmed, except for the filename
column. For that purpose, we use GdStyledTextRenderer, which extends
GtkCellRendererText with support for CSS classes.
However, it can't actually use the standard .dim-label style, because
opacity is ignored, so we end up shipping an ugly css hack instead.
Also, GTK 4 makes GtkCellRendererText a final class, which should not
be subclassed.
So, achieve the desired result using pango alpha attribute, which
actually works well. (Note the final color is slightly different, but
it's actually more faithful to the dim-label style class, so I
believe it to be an improvement; it can be tweaked later in any case.)
gtk_show_uri_on_window() is gone in GTK 4. Instead, we are going to need
gtk_show_uri_full(), which uses an async result API.
Split the code in advance, to reduce the necessary changes at the time
of the GTK 3 to 4 switch.
We have signals defined in the GtkBuilder UI XML file. However, as we
are not using it as a template (we are not subclassing GtkDialog), we
still need to manually bind the callback symbols and even explicitly
bind them with gtk_builder_connect_signals().
In GTK 4 gtk_builder_connect_signals() is gone and the alternative is
setting the signal data (in this case, 'self') before loading the
UI definition.
However, we need to load the UI definition before we create 'self',
because some widgets are requires as construct-only properties. Given
this circular dependency, doing it the GTK 4 way is impossibile.
Therefore, just connect signals in code and remove them from the UI
file. This is compatible with GTK 4. And even under GTK 3 its simpler!
Unless it is already visible.
This fixes a regression caused by the previous commit. Making it a
separate commit because I'm not sure why this is needed now if it
wasn't before.
It's going away in GTK4. Also, as we use a key event controller now,
we can use gtk_event_controller_key_forward() instead.
This is how GTK4 implements gtk_search_entry_set_key_capture_widget(),
so reimplement it here. We were not going to inherit anyway, because we
need a custom widget for a tagged entry in GTK4.
When overriding the ::key-press-event we are able to do things both
before and after chaining up in a single funtion.
As the ::event-press-event is going away with GTK4, we are porting to
event controllers. However, they don't have a chaining up mechanism.
Instead, split the logic into two event controller signal handlers,
one for "before" (capture phase) and one for "after" (bubble phase).
This ensures behavior is preserved with relation to accelerators.
Inspired by Ernestas Kulik's earlier port.
Media keys are handled in the ::key-press-event signal.
This signal is going away in GTK4 and there is no reason not to set
these keyboard shortcuts the same way as all other accels.
The Favorites media key is set as an accel for the "win.bookmarks"
action, which has been removed many years ago along with the bookmarks
editor.
But now we have a Starred view, which fits nicely.
This accelerator has been set for a "win.search" action which
presumably used to exist in the past, but doesn't anymore.
Move it to the "slot.search-active" action.
The signal is gone in GTK4.
Here, it's used to trigger the zoom actions when the zoom media keys
are pressed.
However, the zoom media keys are also already set as accelerators,
since commit 593008d00d
Therefore, we can just drop this redundant code.
We have been keeping a copy of GtkEntry code to guess whether a key
event would insert text into the entry.
Not only is this a hack, it also relies on overriding the ::event signal
and chaining it up, which won't be possible in GTK4 where the ::event
signal is gone.
Instead of guessing, we can know for sure whether characters have been
inserted or deleted by listening to GtkEditable::insert-text and
GtkEditable::delete-text.
We already do the prefix completion manually by calling
gtk_entry_completion_insert_prefix(), because we want full control of
when we do that.
So, disable the automatic prefix completion. Also, this is necessary to
prevent a regression in the next commit.
We only want to do completions when we are typing at the end of the
text. So, we schedule completions on idle depending on this condition.
But we can achieve the same by checking scheduling unconditionally and
check for the condition on idle instead. This leads to simpler code,
resolves a FIXME, and takes code out of the ::event handler, which will
enable the port to event controllers in preparation for GTK4.
The ::event signal is gone in GTK4.
We already have a gesture for clicks, use it instead.
This commit also prepares for turning the menu into a popover,
by passing the x, y coordinates instead of a GdkEvent. This
is to avoid conflicts with the changes in another branch.
Event signals are gone in GTK4.
We rely on the chain-up for two cases:
- holding Shift while clicking
- clicking an unselected row (without holding Ctrl)
The later can be easily emulated in our side. For the former, we can
fall through and let GtkTreeView's default handler do everything.
Side effects of this change:
- secondary click while holding down Shift:
BEFORE: opens context menu without changing selection, even
when clicking outside selection;
AFTER: range-select without opening the context menu.
- click on expander while holding down Ctrl:
BEFORE: adds row to selection and expands tree simultaneously;
AFTER: expands tree without changing selection.
Both are exotic corner cases without an obvious expected behavior and
the behavior before this change is unexpected and inconsistent. So,
the side effects are neutral at worst. Not worth keeping the chain-up.
Primary and secondary click have similar code for handling selection
with modifiers, with some corner case inconsistencies.
Unifying the code path resolves the inconsistencies and simplifies the
code.
We have coordinates right there in the gesture ::release signal, but
are still getting coordinates from GdkEvent.
This is because gtk_tree_view_get_path_at_pos() requires bin_window
coordinates, which happened to be what the GdkEvent coordinates are
(because bin_window is the event's GdkWindow).
In order to use gesture coordinates, we need to translate them into
bin coordinates.
This function has only one caller and it relies on the passed GdkEvent
for everything.
However, in GTK 4, we are going to depend less on GdkEvent and more on
the gesture itself and its signal handler parameters.
So, inline the function to make sure we have everything at ready for
when we switch to GTK 4.
GdkWindow is an X11'ism that's gone in GTK4.
If the event is not in the bin window, then it's in the header, So, we
can check for clicks in the header using event coordinates instead.
gtk_tree_view_get_path_at_pos() requires bin_window coordinates, which
happened to be what the ::event coordinates were (because bin_window
was the event's GdkWindow).
However, with GtkEventControllerMotion we get widget coordinates. This
causes glytches with the underline.
Translating the coordinates fixes the regression.
Rebased and ammended by António Fernandes <antoniof@gnome.org>
(Some style changes in the original have been extracted into
the next commit, for ease of review).
Unlike NautilusFilesView, NautilusPlacesView is not a subclass of
GtkGrid, but instead it's a subclass of GtkBox.
Casting it to GTK_GRID fails at runtime, showing the Other Locations
view as empty.
This is a regression caused by e9ae1add9c
Fix it by treating it as a GtkBox.
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.
