summaryrefslogtreecommitdiff
path: root/libnautilus-private/nautilus-file-operations.c
Commit message (Collapse)AuthorAgeFilesLines
* general: merge libnautilus-private to srcwip/csoriano/private-to-srcCarlos Soriano2016-04-251-7243/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* file-operations: fix deletion rateNeil Herald2016-04-221-2/+3
| | | | | | | | | 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
* file-operations: fix formatting of delete progressAlexander Shpilkin2016-04-221-2/+2
| | | | | | | | | | 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
* file-operations: fix formatting of delete progressAlexander Shpilkin2016-04-141-2/+2
| | | | | | | | | | 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
* file-operations: remove obsoleted desktop dependencyCarlos Soriano2016-04-141-2/+0
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=712620
* general: remove vim modelinesCarlos Soriano2016-04-041-1/+0
| | | | | | | | | | | | | 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.
* nautilus-file-operations.c: new files from template no longer begin with ↵Ricard Gascons2016-03-071-1/+1
| | | | | | | | | | | | | | | | | "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
* file-operations: fix copying from the trashOndrej Holy2016-03-071-1/+1
| | | | | | Use original basename (not path) when creating target path. https://bugzilla.gnome.org/show_bug.cgi?id=721981
* Revert "file-operations: check that trashed files are actually in the trash"Carlos Soriano2016-02-251-224/+20
| | | | | | Was an accidental commited patch. This reverts commit 9bf4390e67e374f7f4f3ee6e757d12feb0d165e6.
* file-operations: check that trashed files are actually in the trashRazvan Chitu2016-02-251-20/+224
| | | | | | | | | | | | | | | | | 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
* file-operations: replace io_scheduler with GTask APIRazvan Chitu2016-02-081-200/+157
| | | | | | | | | | | | | | 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
* file-operations: replace io_scheduler in helper functionsRazvan Chitu2016-02-081-9/+61
| | | | | | | | | | | | | | | 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
* file-undo-manager: rename undo_redo_flagRazvan Chitu2016-01-121-9/+9
| | | | | | | | | | | | | 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
* file-undo-manager: handle undo_redo_flag internallyRazvan Chitu2016-01-121-9/+9
| | | | | | | | | | | | | 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
* file-operations: always pop undo manager flagRazvan Chitu2015-12-241-1/+1
| | | | | | | | | | | | | | | 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
* file-operations: don't free ngettext stringsCarlos Soriano2015-10-061-4/+0
| | | | | | Pointed by Mathias. https://bugzilla.gnome.org/show_bug.cgi?id=755586
* file-operations: Let file/directory creation work on Google DriveDebarshi Ray2015-09-111-17/+158
| | | | | | | | | | | | | | | 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
* file-operations: use total number of files for reportingCarlos Soriano2015-09-081-1/+1
| | | | | | We were using the current transfer information for "duplicating <n> files", which should actually show the total amount.
* file-operations: fix crash when copyingCarlos Soriano2015-09-081-7/+4
| | | | | | | | | | | | | 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
* file-operations: unify commentsPiotr Drąg2015-09-011-0/+2
|
* file-operations: fix plurals translationCarlos Soriano2015-09-011-3/+17
| | | | | | We were doing it elsewhere except here. https://bugzilla.gnome.org/show_bug.cgi?id=754322
* file-operations: add comments for translatorsCarlos Soriano2015-09-011-0/+18
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=754034
* file-operations: fix plural translationsCarlos Soriano2015-07-241-15/+47
|
* file-operations: fix some minor typosPiotr Drąg2015-07-181-9/+9
|
* file-operations: rename report functionsCarlos Soriano2015-07-171-11/+11
| | | | | | | | 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_*
* file-operations: reduce the time for reliable transfer rateCarlos Soriano2015-07-171-1/+1
| | | | | | | 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.
* operations: show a notification when operation finishesCarlos Soriano2015-07-171-0/+21
| | | | | | | | | | | | | | 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.
* progress-info: allow finished infos to remain aliveCarlos Soriano2015-07-171-173/+392
| | | | | | | | | | | | 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.
* operations: implement new designCarlos Soriano2015-07-171-4/+24
| | | | | | | | | 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.
* view: show "New Folder" dialogGeorges Basile Stavracas Neto2015-04-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "view: show "New Folder" dialog"Carlos Soriano2015-04-081-2/+0
| | | | This reverts commit 6f4fc647917364e0b86e6f485efca9d70bbe21f2.
* view: show "New Folder" dialogGeorges Basile Stavracas Neto2015-04-081-0/+2
| | | | | | | | | | | | | | | | | | | | 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
* nautilus-file-operations: Use mount name if availableCarlos Soriano2014-10-091-10/+15
| | | | | | | | | | | | | 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
* file-operations: Add spaces between em dashesRoss Lagerwall2014-03-311-1/+1
| | | | | | | 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
* Updated FSF's addressDaniel Mustieles2014-01-311-3/+1
|
* file-operations: Don't crash after failed inhibitRoss Lagerwall2013-11-031-4/+4
| | | | | | | | | | 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
* Bug 698694 - Redundant options presented in operations on single filesWilliam Kunkel2013-08-311-44/+69
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=698694
* file operations: fix double unref and show invalid filename error dialogNelson Benitez Leon2013-08-161-3/+3
| | | | | | | | | | 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
* file-operations: replace control characters for FAT fs operationsCosimo Cecchi2013-08-161-5/+5
| | | | | | | Those are invalid - if we find one, replace it with an underscore as well. https://bugzilla.gnome.org/show_bug.cgi?id=706131
* libnautilus-private: don't use deprecated GtkImageMenuItem and GtkStockCosimo Cecchi2013-08-131-34/+36
|
* places-sidebar: make sure to always notify when unmountingCosimo Cecchi2012-12-111-16/+26
| | | | | | | | 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
* Make sure to use correct filename when restoring from TrashTimothy Arceri2012-11-301-3/+13
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=673598
* all: don't use eel_g_object_list_copy()Cosimo Cecchi2012-10-231-5/+5
| | | | Use g_list_copy_deep() instead.
* file-operations: use the local (FUSE) path for remote symlinksCosimo Cecchi2012-09-131-3/+3
| | | | | | | 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
* Don't verify symlinked target for I/O operationsTomas Bzatek2012-09-121-1/+13
| | | | | | | | | | | | | | | | | | 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
* file-operations: fix GList leakPavel Vasin2012-08-241-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=682603
* file-operations: move: fix potential GError leaksPavel Vasin2012-08-241-0/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=682603
* file-operations: fix GFile leakPavel Vasin2012-08-241-1/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=682603
* Use quotes consistently for error dialogsWilliam Jon McCann2012-08-221-1/+1
|
* Make getting extension more robustWilliam Jon McCann2012-08-221-1/+1
| | | | Ensure the basename and extension have at least one char each.
View Lorry Controller Status