| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And fix make distcheck.
Although libnautilus-private seem self contained, it was actually
depending on the files on src/ for dnd.
Not only that, but files in libnautilus-private also were depending on
dnd files, which you can guess it's wrong.
Before the desktop split, this was working because the files were
distributed, but now was a problem since we reestructured the code, and
now nautilus being a library make distcheck stop working.
First solution was try to fix this inter dependency of files, but at
some point I realized that there was no real point on splitting some of
those files, because for example, is perfectly fine for dnd to need to
access the window functions, and it's perfectly fine for the widgets
in the private library to need to access to all dnd functions.
So seems to me the private library of nautilus is somehow an artificial
split, which provides more problems than solutions.
We needed libnautilus-private to have a private library that we could
isolate from extensions, but I don't think it worth given the problems
it provides, and also, this not so good logical split.
Right now, since with the desktop split we created a libnautilus to be
used by the desktop part of nautilus, extensions have access to all
the API of nautilus. We will think in future how this can be handled if
we want.
So for now, merge the libnautilus-private into src, and let's rethink
a better logic to split the code and the private parts of nautilus than
what we had.
Thanks a lot to Rafael Fonseca for helping in get this done.
https://bugzilla.gnome.org/show_bug.cgi?id=765543
|
|
|
|
|
|
|
|
|
| |
The deletion rate shown to the user is wrong, it's coming out as a
massive number. An earlier fix corrected the deletion rate used to
determine if the message should use the plural. This fix is to make the
same change to the value shown to the user.
https://bugzilla.gnome.org/show_bug.cgi?id=759986
|
|
|
|
|
|
|
|
|
|
| |
A simple operator precedence mishap prevented the deletion rate during
long deletion operations from being displayed properly. Also, the
formatting of the message is subtly different from the others of this
kind because we don't have a predefined formatting token for a file
count, and it ended up missing a space character.
https://bugzilla.gnome.org/show_bug.cgi?id=759986
|
|
|
|
|
|
|
|
|
|
| |
A simple operator precedence mishap prevented the deletion rate during
long deletion operations from being displayed properly. Also, the
formatting of the message is subtly different from the others of this
kind because we don't have a predefined formatting token for a file
count, and it ended up missing a space character.
https://bugzilla.gnome.org/show_bug.cgi?id=759986
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=712620
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Vim and emacs modelines are used to specify some of the code style in the code.
However, this is misleading and poorly supported since nautilus had a mix of
code style for some time.
Also, the mode lines doesn't specify the whole code style, so we will need to
use a different tool as well to specify the whole code style.
For that, we can just use a different tool for everything.
So remove the mode lines, and in a short future we will reestyle the nautilus
code to have a single code style, and use a tool like editorconfig to specify
the whole code style.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Untitled"
When a new document is created using a template, the word "Untitled"
is displayed in front of the template name. For example,
creating a new document with a template called "document.doc"
will create new file named "Untitled document.doc".
This is obviusly a non-practical use of templates and this patch
aims to fix this miss-behavior.
The fix is simple, the word "Untitled" has been removed from the
code when a user creates a new document from a template.
https://bugzilla.gnome.org/show_bug.cgi?id=762774
|
|
|
|
|
|
| |
Use original basename (not path) when creating target path.
https://bugzilla.gnome.org/show_bug.cgi?id=721981
|
|
|
|
|
|
| |
Was an accidental commited patch.
This reverts commit 9bf4390e67e374f7f4f3ee6e757d12feb0d165e6.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Nautilus, trash operations are performed and finalized before the trash is
updated. Because of this, the option to undo trashing becomes available even if
the trash is not aware of new files. If an undo is then requested, the operation
would do nothing, because the files would appear to not exist in the trash. A
better solution would be to wait for the trash to notified, and then check that
the trashed files are actually there. Only then should a trash operation be
considered finalized.
Add a signal to the trash-monitor that is emitted when the trash changes.
Connect trash operations to this signal. On signal emission, asynchronously
check that the files are in the trash. Finalize the job if the check was not
cancelled and successful.
https://bugzilla.gnome.org/show_bug.cgi?id=762126
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus file operations are implemented as asynchronous jobs scheduled using
g_io_scheduler. Since g_io_scheduler has been deprecated, these operations
should be using the simpler GTask API. The helper functions used in the
operations have been changed in a previous patch so it is now possible to port
the jobs themselves to the new API.
The job structures are now data for tasks, which are handled by the existing
functions in separate threads. For finalizing the operations, the existing
"job_done" functions are now used as callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=761549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nautilus file operations are implemented as asynchronous jobs scheduled using
g_io_scheduler. Since g_io_scheduler has been deprecated, these operations
should be using the simpler GTask API. In order to make this change possible, a
first step would be to replace the scheduler in the helper functions called
during the jobs.
Replace g_io_scheduler_send_to_mainloop with g_main_context_invoke in helper
functions. Since g_main_context_invoke is not blocking, add a mutex and a
condition so the current thread is blocked until the operation is completed in
the main loop.
https://bugzilla.gnome.org/show_bug.cgi?id=761549
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Pointed by Mathias.
https://bugzilla.gnome.org/show_bug.cgi?id=755586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
We were using the current transfer information for
"duplicating <n> files", which should actually show
the total amount.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
We were doing it elsewhere except here.
https://bugzilla.gnome.org/show_bug.cgi?id=754322
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=754034
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.png
https://bugzilla.gnome.org/show_bug.cgi?id=747381
|
|
|
|
| |
This reverts commit 6f4fc647917364e0b86e6f485efca9d70bbe21f2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
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/new-folder.png
https://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
|
|
|
|
|
|
|
| |
Add spaces between em dashes when reporting delete progress for
consistency with the reporting of copy progress.
https://bugzilla.gnome.org/show_bug.cgi?id=721292
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=698694
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Those are invalid - if we find one, replace it with an underscore as
well.
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=673598
|
|
|
|
| |
Use g_list_copy_deep() instead.
|
|
|
|
|
|
|
| |
Instead of the path relative to the remote machine, in case the
destination of the link is native.
https://bugzilla.gnome.org/show_bug.cgi?id=148330
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=682603
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=682603
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=682603
|
| |
|
|
|
|
| |
Ensure the basename and extension have at least one char each.
|