summaryrefslogtreecommitdiff
path: root/libnautilus-private
Commit message (Collapse)AuthorAgeFilesLines
* general: merge libnautilus-private to srcwip/csoriano/private-to-srcCarlos Soriano2016-04-25117-61403/+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
* toolbar: fix ops button so it gets removed when multiple windows openNeil Herald2016-04-222-0/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | In some cases, the operations button doesn't get removed from every Nautilus window. And if clicked, an empty popover will appear. One case is when the user starts a long operation, and then closes the popovers in all windows once the operations have completed (and before the buttons are due to be removed). All windows get notified that the operations have finished. But if there's a popover open in any window at that point, the windows don't schedule removal of the button - as the logic is to keep the buttons visible while there are popovers open. When the user then closes the popover in the last window, that window knows there are no popovers in the other windows, so it removes the button from it's toolbar. But there's nothing to notify the other windows to remove their buttons. The fix is to implement a more robust solution; instead of the windows checking the other windows for popovers (windows shouldn't know about the other windows anyway), the progress info manager maintains a list of viewers. When an popover is open or closed, the window tells the manager to update it's list of viewers. When there are no entries in the list, the info manager notifies all listeners (the windows), so they all know when to schedule removal of their buttons. https://bugzilla.gnome.org/show_bug.cgi?id=765019
* tree-view-drag-dest: use GdkSeat operationsErnestas Kulik2016-04-221-3/+5
| | | | | | | | | Some GdkDisplay operations have been deprecated in GDK 3.20. This commit replaces the deprecated code with new GdkSeat operations. https://bugzilla.gnome.org/show_bug.cgi?id=762235
* dnd: use GdkSeat operationsErnestas Kulik2016-04-221-3/+5
| | | | | | | | | Some GdkDisplay operations have been deprecated in GDK 3.20. This commit replaces the deprecated code with new GdkSeat operations. https://bugzilla.gnome.org/show_bug.cgi?id=762235
* canvas-container: use GdkSeat operationsErnestas Kulik2016-04-221-3/+6
| | | | | | | | | Some GdkDisplay operations have been deprecated in GDK 3.20. This commit replaces the deprecated code with new GdkSeat operations. https://bugzilla.gnome.org/show_bug.cgi?id=762235
* 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-undo-operations: fix missing includeCarlos Soriano2016-04-191-0/+1
| | | | | Having so many deprecation warnings obscure the real warnings... :/ Should run more frequently with those disabled.
* canvas-item: fix castingCarlos Soriano2016-04-191-1/+1
| | | | | Having so many deprecation warnings obscure the real warnings... :/ Should run more frequently with those disabled.
* desktop: move to a different folderCarlos Soriano2016-04-1513-2960/+0
| | | | | | For a better structured hierarchy. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* Revert "desktop: move to a different folder"Carlos Soriano2016-04-1513-0/+2960
| | | | This reverts commit c9dcccae611e40f48024bdfeccbb081fa10b7b15.
* desktop: move to a different folderCarlos Soriano2016-04-1513-2960/+0
| | | | For a better structured hierarchy.
* search-directory: fix missing ref to the queryCarlos Soriano2016-04-141-1/+1
|
* 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-dnd: remove the filesCarlos Soriano2016-04-142-168/+0
| | | | | | | We moved the code to nautilus-file, but forgot to remove the files. Remove them. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* directory: use gio extensions for directory dispatchingCarlos Soriano2016-04-148-39/+117
| | | | | | | | | | | | | | We needed to do some hackish code in order to allow types that are not included in nautilus-directory to dispatch the correct subclass. Instead of that, we can just create a "plugabble" system that allows directory types to be registered in the system, and implement a class vfunc that queries if the class handles a specific type of uri, falling back if none can handle it to the usual nautilus-directory. We can do this for the desktop directory and the search directory. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* desktop-icon-file: fix missing parameter in vfuncCarlos Soriano2016-04-141-1/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=712620
* desktop-icon-file: chain up for get_target_uriCarlos Soriano2016-04-141-1/+3
| | | | | | | In case we don't meet the conditions the parent function can still deal with it. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file: extract shared code for handling gone files on renamingCarlos Soriano2016-04-143-27/+37
| | | | | | Just to make it cleaner. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file: move special link to file instead of the viewCarlos Soriano2016-04-143-0/+26
| | | | | | This feels like belonging to the file itself rather than the view. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* canvas-dnd: set as NULL after freeCarlos Soriano2016-04-141-0/+1
| | | | | | So we don't double free it. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* mime-actions: move opens_in_view to fileCarlos Soriano2016-04-143-0/+25
| | | | | | | | | | | | | | | | And allow overriding of subclasses. Nautilus mime actions file currently uses the file as parameter, as if it was part of the nautilus file class. However it's hosted in a different file, even though we need to special case some subclasses of nautilus file for its management. imho, this code design is wrong, since it defeats the purpose of OOP. So move it to the nautilus file, allow overriding, and override this vfunc in the subclasses that need it, like the desktop-icon. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* program-choosing: remove unneeded desktop dependencyCarlos Soriano2016-04-141-1/+0
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file-operations: remove obsoleted desktop dependencyCarlos Soriano2016-04-141-2/+0
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=712620
* desktop-icon-file, file: override invalidate_attributesCarlos Soriano2016-04-142-9/+10
| | | | | | | | Since the desktop files needs to do nothing at all. This removes the last desktop dependency from nautilus file (yay). https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file: allow overriding invalidate_attributes_internalCarlos Soriano2016-04-142-2/+13
| | | | | | | | | We are special casing some cases where we want to do something different in subclasses. Allow to override this function so subclasses can use it. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* desktop-icon-file: move dnd handling to the subclassCarlos Soriano2016-04-142-4/+8
| | | | | | | Now that we can use inheritance for dnd handling, use it in the subclass instead of special casing on the parent. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file: allow overriding dnd handlingCarlos Soriano2016-04-142-0/+10
| | | | | | Subclasses may want to override some dnd handling. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file-dnd: move dnd handling to fileCarlos Soriano2016-04-146-26/+131
| | | | | | | | | | | | | | | | | We are requiring file handling like special casing subclasses in the dnd handling. We are currently doing it outside of nautilus class... which makes overriding on subclasses impossible. This design goes against inheritance design, so there is no point on making it that way if it defeats this purpose. So merge the handling of file dnd inside the file class itself, and in upcoming patches we will override that handling in order to use inheritance instead of special casing in the parent. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* desktop-icon-file: override get_target_uriCarlos Soriano2016-04-142-16/+25
| | | | | | | Now that we can do it in subclasses, use inheritance instead of special casing in the parent. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file: rename get_drop_target_uriCarlos Soriano2016-04-143-7/+7
| | | | | | | | | | | | | | | | | This get target uri is used for those which we have special handling on the activation uri, instead of the usual glib attribute G_FILE_ATTRIBUTE_STANDARD_TARGET_URI. So it behaves like a supergroup of those which have G_FILE_ATTRIBUTE_STANDARD_TARGET_URI, but we use it in the same way. We use for handling special files like desktop links on drag and drop, etc. However, this is useful for other parts of nautilus, and we will use it in a upcoming patch, so we can rename it in order to communicate the wide nature of the function. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file: allow overriding of get_drop_target_uriCarlos Soriano2016-04-142-0/+9
| | | | | | | So subclasses like desktop icon can make its own handling, instead of special casing in the parent. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* desktop-icon-file, file: move rename handling to subclassCarlos Soriano2016-04-142-40/+84
| | | | | | | Now that we can override the vfuncs needed for special casing the desktop icon files, move all that handling to the subclass. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file: allow overriding rename handlingCarlos Soriano2016-04-142-4/+31
| | | | | | We will need it for using inheritance instead of special casing. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* desktop: ensure desktop directory on application initCarlos Soriano2016-04-142-5/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now we were creating the desktop directory in a lazy way, like any other cached directory. However, we have the problem that at some point we have to dispatch between different types of files, when creating them for the cache. We cannot know when we will need to create the desktop directory for first time in order to discern between that type of directory, or the regular one. What we can do is ensure that we created the desktop directory before any other part of nautilus request it. In this way, we can create it on our subclasses of the desktop, and after that, nautilus will request the cache as a regular use, without the need to special case the desktop. For that, create the desktop directory when the desktop application starts, holding the reference so the cache doesn't release it, and then let nautilus work as expected. For that, in previous commits we moved the file dispatching to be inside the directory, so now any file creation happens inside the directory, and therefore we can control, when creating the desktop directory, what subclass will be called. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* desktop-directory: override creation of filesCarlos Soriano2016-04-142-9/+27
| | | | | | | | So we use inheritance instead of special casing, making possible to remove the desktop dependency for the creation of the desktop files. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* directory: allow overriding the creation of filesCarlos Soriano2016-04-142-0/+21
| | | | | | So subclasses like the desktop directory can do their own. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* file, directory: move file creation dispatching to directoryCarlos Soriano2016-04-143-25/+42
| | | | | | | | | | | | It's the directory who owns the files, and we were actually creating new files from nautilus directories in nautilus-file. We can move that code to nautilus directory. In this way, we will able to handle files of a specific scheme better, like the desktop, in future patches. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* nautilus-dnd: request file system info if not availableCarlos Soriano2016-04-144-5/+61
| | | | | | | | | | | | | | | | We were assuming we had in cache the files used for dnd, but with the desktop split that's not longer the case. What can happens is that we cannot discern whether the drop action should be a copy or a move, since Nautilus always performs a move if the file system is the same as the dragged files. To fix it, in a best effort mode, we will request to update the files information if it's not available. In future times it will be requested, and if the files are not freed, we will have the file system information available in order to decide a more appropriate drop action. https://bugzilla.gnome.org/show_bug.cgi?id=712620
* trash-monitor: change trash monitoring processRazvan Chitu2016-04-081-37/+28
| | | | | | | | | | | | | | | In Nautilus, the trash is monitored for state changes - going from empty to non-empty and the other way round. Monitoring is done by handling change signals from a regular file monitor. On each signal, an enumeration of the trash contents is started in order to see if it is empty or not. This causes issues when many files are trashed, because the gvfs trash backend is flooded with enumeration requests, resulting in CPU usage spikes. In order to fix this, the "item-count" attribute of the trash should be queried instead. Replace asynchronous enumeration with asynchronous information query and update the trash state based on the "item-count" attribute. https://bugzilla.gnome.org/show_bug.cgi?id=763218
* file-utilities: compute mount location title based on mount nameRazvan Chitu2016-04-051-0/+9
| | | | | | | | The label of a mounted location is displayed differently in the pathbar and in an open tab, due to different means of obtaining the location title. In order to fix this, use the mount name when computing the mount title for an open tab. https://bugzilla.gnome.org/show_bug.cgi?id=764573
* general: remove vim modelinesCarlos Soriano2016-04-04119-174/+55
| | | | | | | | | | | | | 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.
* bookmarks: don't allow bookmarking searchCarlos Soriano2016-03-302-0/+11
| | | | | | | | With the latest redesign of the search, there is not much point to bookmark a search, and instead, make the search again. Anyway, maybe it makes sense if we create a more complex search engine, but we can add support for it in the future, when it's needed.
* conflict-dialog: remove unused varCarlos Soriano2016-03-171-3/+0
|
* file-undo-operations: replace GSimpleAsyncResult API with GTaskRazvan Chitu2016-03-141-52/+39
| | | | | | | | In Nautilus, undo operations are performed as asynchronous tasks, using the GSimpleAsyncRequest API. Because this API is now deprecated, replace it with the GTask API. https://bugzilla.gnome.org/show_bug.cgi?id=763445
* Revert "file-undo-operations: modularize restoring files from trash"Razvan Chitu2016-03-111-94/+43
| | | | | | | | Modularization was done in preparation for another commit supposed to fix a trash issue. Since this issue is probably not from nautilus, this is no longer needed. This reverts commit 39798e28c9566656c248d3462195e0f9ae188bd9.
* content-bar: use const type for content typesCarlos Soriano2016-03-102-6/+6
| | | | This fixes warnings.
* 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-undo-manager: fix trash undo invalidationRazvan Chitu2016-03-071-9/+4
| | | | | | | | | In Nautilus, when the Trash is emptied, trash undo / redo operations are invalidated by the undo manager. However, only the undo operations should be invalidated, because a redo is not affected by the state of the Trash. In order to fix this, change the invalidation condition to only target undo. https://bugzilla.gnome.org/show_bug.cgi?id=763134
* nautilus-file: Don't show thumbnails for small zoom levelsAlexandru Pandelea2016-03-071-1/+16
| | | | | | | | | | | | | | | When the zoom level is too small, thumbnails become useless, as they are so small that they don't give any information. The solution to this problem is to use mimetype icons when the zoom level is too small In order to achieve this, there was added a function that returns true if the zoom is too small, nautilus_thumbnail_is_limited_by_zoom, meaning that the corresponding mimetype icon should be used instead of the thumbnail https://bugzilla.gnome.org/show_bug.cgi?id=752805
View Lorry Controller Status