The selected files list is chosen after the user confirmed the compress
operation in the compress-dialog which may result in files other than
chosen file being compressed.
Store the list of selected files when the user chooses the "Compress"
option from the menu, to avoid that
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1900
The right-click menu is arranged in a way in which "Open with default
application" and "Open With Other Application" are visually separated.
It's not comfortable for the user to need to scan the menu looking for
the "Open With Other Application" if the default option is not the
expected one.
This change just puts the two menu items under the same UI section, not
only bringing them visually together but also removing any line
separation between them since they can be considered to be part of the
same concept.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1268
The edit_name attribute corresponds to G_FILE_ATTRIBUTE_STANDARD_EDIT_NAME
attribute. It is almost identical to display_name, except if there is
invalid encoding, and is preferred when implementing renaming functionality.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1540
When files are selected the floating bar appears with info about their types,
count, and size. In certain cases, there is an extra space character before the
comma when the folder item count is not known. Also, there is an extra space
character at the end when the size for other files is not known. To fix those
issues, let's handle those cases differently.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1867
A new bug in uncrustify 0.73 causes a pointer type to be interpreted
as an arithmetic operation, thus adding a space. [0]
This causes the CI pipeline to fail on style-check job.
To workaround this, ignore the "space around arithmetic operator" rule.
[0] https://github.com/uncrustify/uncrustify/issues/3233
There are a few non-braced single-statement in the final cases, which
have gone unnoticed until detected by a recent uncrustify update.
Let's add the missing braces around single-statements even if it's the
last case.
The build log contains warnings about deprecated gexiv2 functions. Let's
port to the new API, unpin exiv3 and gexiv2 dependencies in flatpak manifests
and bump the build dependency accordingly to get rid of the warnings.
Nautilus can show "Unable to find the requested file. Please check the
spelling and try again." error when starting. The message doesn't indicate
what file was not found. Let's add the file name to that dialog to make it
obvious.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1793
The slot.files-view-mode action takes hardcoded id values. This may
break if the ids enumeration changes.
Instead, let's define the values with a macro which we can stringify.
While we are at it, drop the unused EMPTY id.
We define a NautilusWindow method in nauitlus-window-slot.c. That's
just wrong.
Also, there is no reason for this to be a NautilusWindow method,
rather than a slot one.
The only consumers are NautilusWindow and NautilusToolbar, and both
have a pointer to the current slot, so let's make this a slot method.
For convenience, also add a private NautilusWindow wrapper method.
Last commit removed the only subclass because switching slot class is
problematic, so we probably don't want to do it again.
This partially reverts 0a512d00b6
The NautilusOtherLocationsWindowSlot subclass has been introduced along
with its sibling NautilusDesktopWindowSlot.[0]
However, the desktop one is now gone, and this is the only subclass.
It does only 2 things differently from its parent class:
* Creates a NautilusPlacesView instead of a NautilusFilesView
* Disables the slot.files-view-mode-toggle and files-view-mode actions
There is little reason not to handle both things in the parent class.
Also, changing slots when going in and out of the Other Locations place
throws away the navigation data; while this can be worked around by
saving and restoring this data, this outweights any potential benefits
of subclassing.
This commit is equivalent to reverting [0], but due to code style and
other changes, a clean revert was not possible.
Effectively fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/32
[0] commit 5f295bd92c
The feature that allows opening a new window from the history popup menu
by middle-clicking hasn’t been working for three years, since the flags
parameter in nautilus_window_back_or_forward() is not honored. In some
places it’s used inappropriately, so it’s better to just drop the code
and rethink the approach if such a feature is desirable.
When the "Show Hidden Files" check button is toggled, the popover is closed,
however, when the "Show Sidebar" check button is toggled, the popover stays
opened. This is inconsistent and the popover should stay open in all cases.
This happens because of a bug in the `nautilus_toolbar_is_menu_visible`
function implementation, which is checking the visibility of the `view_button`
popover instead of the `app_menu` popover. Let's check the visibility of the
correct popover to fix this inconsistency.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1827
This reverts commit 54d1ad250e.
This signal has been added because NautilusApplication needed to update
the previewer when selection changes. It no longer does that, since the
previous commit, so this signal is no longer needed.
When the NautilusFilesView:selection property changes, this change is
notified to the slot, the the window, then the application, though a
chain of bindings and singals. The application class then calls a
NautilusFilesView method to actually update the preview.
The NautilusApplication class used to update the preview when the
active window changes, but that's no longer the case after the changes
in commit 0b7a7f95f8.
This whole roadtrip to NautilusApplication and back is useless now, so
let's handle it all in NautilusFilesView.
The description of a folder in the properties dialog precise the
mime-type but it is useless for folders
Test if the mime type is not equal to "inode/directory" before
adding it to the detailed string.
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1737
When the properties window is opened, the name field get the focus automaticaly.
The user can accedentily change the file name, so let's prevent the name field from
being automaticaly selected.
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1805
