Nautilus undo manager previously relied on a stack-like implementation of its
operating state. The stack operations (pushing and popping) were removed in a
previous commit due to possible unexpected behavior and errors. The flag alone
now has an inadequate name for what it represents.
Rename the flag to "is_operating", since it is set when the manager is
performing an undo / redo operation and unset otherwise. Rename the associated
getter function accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=759850
Nautilus undo manager reuses undo information based on a flag that marks whether
an undo / redo operation is currently being performed. Previously, the flag was
managed both internally and externally. This proved to be unnecessary and even
harmful, as it led to an unexpected behavior.
Remove push and pop functions and handle the flag explicitly, at the start and
at the end of an undo / redo operation. Replace external use of pop with the use
of a getter function, also introduced in this patch.
https://bugzilla.gnome.org/show_bug.cgi?id=759850
Nautilus undo manager reuses undo information based on a flag that is pushed
when an undo operation begins and popped during the operation itself. In the
case of trashing / deleting files, the flag was not popped in some situations,
which caused the next operations to not be undoable.
Flip operands of a logical operator so the flag is always popped, avoiding
issues caused by lazy evaluation.
A better solution would be to always update the flag internally in the manager,
and only peek its value externally.
https://bugzilla.gnome.org/show_bug.cgi?id=759850
Immediately check the volatility of the newly created file or directory
and switch to using the "real" persistent URI. The following operations
are affected:
- creating new directories
- creating new files from templates
- dragging & dropping text to create new files
- copying and moving of files and directories
The Google Drive backend doesn't support creating symbolic links so we
ignore that case.
https://bugzilla.gnome.org/show_bug.cgi?id=751481
Commit 2db9a295 introduced an obvious crash, not sure how
I managed to make it in if it was part of the tests and seems
it was working for other people.
Anyway, we were using the wrong argument, which pointed
to a wrong address when reporting operations, and that was
causing a crash.
To fix it, remove the spurious argument.
https://bugzilla.gnome.org/show_bug.cgi?id=753282
Some of them were not actually the one reporting the status,
but instead just the preparing status.
That was confusing since the actual functions that report the
progress status for move/link/count were report_copy_progress.
So just call them report_preparing_*
Currently it was 15 seconds, which is a little too much. Most
of the time 8 seconds is enough, and even more with SSDs. In this
way we are able to provide feedback of the remaining time to the
user in a more reasonable time.
When the operations popover is not visible, we have to give
feedback to the user about if an operation finished.
For that, show a in-app notification in case the operation popover
is closed and a operation finishes. Also, to link the notification
with the operation button, make the button pulse for a second.
The code interaction between nautilus-file-operations and nautilus-progress-info
start to get crowed. At some point, the best we can do is delegate all the
progress UI part to nautilus-progress-info, providing all the needed information
like the CommonJob, TransferInfo and SourceInfo; so we avoid the current
odd interaction between them. This is a future work.
We want to not hide the operations and the operations button
in the toolbar if the popover is open. For that, we need to
allow operations widgets to remain alive even when the operation
is finished.
For that we need to add a new status state to copying/moving/trashing,
like copied/moved/trashed.
On the way, improve the wording of file-operations to match the mockups,
and also make the report operations code more consistent to each other.
Now operations reside in the toolbar, in form of a button with
a popover. In this way we avoid to have a nautilus window hanging
around for it.
When no nautilus window is open, the persistence handlers of nautilus
are enough. This use a notification if the server supports it or
a systray icon in case it doesn't.
This commit introduces the "New Folder"
dialog, which asks the folder name before
actually creating it.
With the introduced changes, the folder
is created with the given name instead
of creating it first with the generic
"Unamed folder" and then renaming it.
The dialog has a "delayed message" logic,
where typos are immediatly recognized, but
coincident folder names appear ~2s later.
This dialog is part of the ongoing effort
to modernize Nautilus to better fit GNOME
standards, and the latest mockups can
be found at [1].
[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/create-folder-wires.pnghttps://bugzilla.gnome.org/show_bug.cgi?id=747381
Currently custom_basename_to_string uses the base name or display name
of the files for the copying and moving dialog.
In the cases of unlabeled removable drives, the name is a code, showing
in the dialog a not very friendly name.
gtkplacessidebar and nautilus-pathbar uses the mount name retrieved by
g_mount_name if available.
Use that fir the operations dialogs as well to display a more friendly
name to the user and to be consistent with the sidebar and pathbar name.
https://bugzilla.gnome.org/show_bug.cgi?id=738087
If gtk_application_inhibit fails, it returns a 0 cookie. When this
invalid value is passed to gtk_application_uninhibit, Nautilus crashes
if glib or gtk is compiled with minimal debug checks.
So, only call gtk_application_uninhibit if a non-zero cookie is
returned. Also, use the correct type for inhibit_cookie (guint).
https://bugzilla.gnome.org/show_bug.cgi?id=709015
Remove a superflous g_object_unref() call plus show error dialog when
creating a new file with an invalid file name for the destination
file system.
Fixes bug 706131
https://bugzilla.gnome.org/show_bug.cgi?id=706131
When unmounting from the sidebar with an operation other than eject, we
still need to set up the progress notification, as some drives return
FALSE for can_eject.
https://bugzilla.redhat.com/show_bug.cgi?id=885133
Nautilus verifies the destination for free space, read-only ability
and such. This however doesn't work for symlink pointing to a directory.
Internally (in gio) we call statfs() but that actually stats the fs the
symlink is on, instead of the place symlink is pointing to. This appears
to be a limitation of POSIX statfs().
To work around this limitation, let's disable these extra checks when
destination is a folder and symlinked.
The bug manifestation are false error messages preventing to create a file
or directory when parent fs is read-only but contains a symlink to rw fs
which is the desired destination.
https://bugzilla.redhat.com/show_bug.cgi?id=844713
When unmounting, we might first prompt whether the trash should be
emptied or not on the target volume. If we do so, make sure the callback
from the empty trash job has the right prototype, to avoid crashing
later trying to interpret a gboolean as a pointer to a data structure.
https://bugzilla.gnome.org/show_bug.cgi?id=670595
Also, make the mtime checks actually useful; we need to check the
trash::deletion-date attribute and match it with the time we trashed the
file (which we can easily know using g_get_current_time()).
