summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* placesview: autogenerate from gtk+ repowip/csoriano/autoplacesviewCarlos Soriano2016-03-0912-566/+626
| | | | | Instead of manual copying and replacing symbols, use a script to copy from gtk+ repo and replace any symbol or problematic part.
* Updated Korean translationChangwoo Ryu2016-03-081-1845/+2319
| | | | (cherry picked from commit 93860099b811031473b106a24899a2d646db74f3)
* floating-bar: make the stop smaller than normal buttonsCarlos Soriano2016-03-072-9/+10
| | | | | | | | | | With the latest changes on gtk+ the button sizing changed and made the button in the floating bar taller. To fix it, remove the padding from the button. Also improve how the button is created using the "new" gtk+ functions. https://bugzilla.gnome.org/show_bug.cgi?id=763249
* 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
* files-view: added alt+return shortcut for propertiesJoseph-Eugene Winzer2016-03-072-2/+7
| | | | | | | | | | | | | | | | | | With nautilus 3.16 the properties shortcut was changed from alt+return to ctrl+i. alt+return is a known shortcut in other applications for showing file properties, so it was proposed to add alt+enter and altgr+enter as shortcuts in bug 662081. nautilus_application_add_accelerator() does not accept multiple shortcuts per action, so I used gtk_application_set_accels_for_action() and bound view.properties to the array open_properties. Also the additional shortcut was added to the shortcuts overview. Unfortunately, I couldn't find a reliable way to bind altgr for the shortcut, as modifiers are dependend on the X server mapping. https://bugzilla.gnome.org/show_bug.cgi?id=662081
* files-view: add Open With App menu item for all itemsaki2372016-03-071-3/+1
| | | | | | | | | | | | | The menu item "Open With Application" is not available for most files. This is a valid menu item for files and folders of all types where the selected item can be opened in some other application. To fix it : The condition in the "src/nautilus-files-view.c" that adds open with application action has been modified so that this menu item appears in the context menu for all cases (except when the right click is triggered in empty space) https://bugzilla.gnome.org/show_bug.cgi?id=566477
* window, progress-persistence-handler: change notifications APIRazvan Chitu2016-03-072-14/+14
| | | | | | | | | | | | | In Nautilus, notifications are sent using GApplication functions and are not tracked. This leads to notifications that are not being cleared when Nautilus is closed. In order to fix this, sending and withdrawing notifications should be done with the methods of NautilusApplication. These methods automatically track and clear them when the application is shutdown. Replace GApplication functions for sending and withdrawing notifications with corresponding NautilusApplication functions. https://bugzilla.gnome.org/show_bug.cgi?id=763129
* application: handle notifications internallyRazvan Chitu2016-03-072-0/+68
| | | | | | | | | | | | | In Nautilus, operations such as unmounts create notifications that are not withdrawn on application closing. This leads to issues such as notifications that persist even after reboot. In order to fix this, the application should keep track of the notifications sent in order to withdraw them when it is closed. Add helper functions for sending and withdrawing notifications. Add "shutdown" signal handler for removing notifications on application closing. https://bugzilla.gnome.org/show_bug.cgi?id=763129
* 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
* 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
* window: update sidebar other-location signalCarlos Soriano2016-03-072-4/+4
| | | | | | We reverted the change of the signal in gtk+ and added a new one to avoid breaking API. Use the new signal.
* content-bar: don't auto destroy the widgetCarlos Soriano2016-03-071-9/+5
| | | | | | | | | | | | | | | | | | | We were auto destroying the content bar if the mime type couldn't be handled. This is wrong since the caller is not aware of anything, trying to show or do other things with the destroyed widget. I'm not sure how this even work, if it worked at all. Previously it wasn't crashing because gtk+ was failing gratefully, however, with the gadget rework, this makes gtk+ crash. We fixed this in the previous patch, only creating the content bar if we can handle the myme types. This patch adds a few more guards and, in any case, avoid to destroy the widget inside the widget itself. https://bugzilla.gnome.org/show_bug.cgi?id=762703
* window-slot: only create x-content-bar if necessaryCarlos Soriano2016-03-071-0/+3
| | | | | | | | We were creating the x-content-bar every time, then the content bar was destroying itself (?) if no content type could be handled. Just avoid to create the content bar if no necessary. https://bugzilla.gnome.org/show_bug.cgi?id=762703
* content-bar: move more content type handlingCarlos Soriano2016-03-073-7/+28
| | | | | | | And rely on file-utilities to check whether we can should handle those mime types. https://bugzilla.gnome.org/show_bug.cgi?id=762703
* content-bar: move content type handling to nautilus-fileCarlos Soriano2016-03-073-76/+79
| | | | | | | All the other content type functions are there, and we will need it anyway in an upcoming patch. https://bugzilla.gnome.org/show_bug.cgi?id=762703
* content-bar: update modelineCarlos Soriano2016-03-071-1/+1
|
* file-utilities: update modelineCarlos Soriano2016-03-071-1/+1
|
* window: hide delete notification on undoRazvan Chitu2016-03-071-1/+3
| | | | | | | | | | | In Nautilus, after a delete operation, an undo notification is shown to the user. If the operation is undone by other means (such as the Ctrl+Z shortcut), the notification is not automatically hidden, which can lead to an invalid undo operation. In order to fix this, hide the notification on an undo operation. Hide notification in the "undo-changed" signal handler. https://bugzilla.gnome.org/show_bug.cgi?id=761546
* Updated Slovenian translationMatej Urbančič2016-03-051-918/+1350
|
* Update Latvian translationRūdolfs Mazurs2016-03-051-1957/+2560
|
* Updated Polish translationPiotr Drąg2016-03-041-30/+31
|
* Updated Hungarian translationBalázs Úr2016-03-041-480/+522
| | | | (cherry picked from commit ee478c159d9b1650e2dd024d3cff2617ba1cb628)
* Updated Brazilian Portuguese translationArtur de Aquino Morais2016-03-041-292/+295
|
* Updated Kazakh translationBaurzhan Muftakhidinov2016-03-041-99/+102
| | | | (cherry picked from commit ce572168c4f7f7d48655139961613b79c2f1deed)
* Updated Greek translationTom Tryfonidis2016-03-031-83/+83
|
* Updated Greek translationTom Tryfonidis2016-03-031-107/+107
| | | | (cherry picked from commit 98b0c7ac7351cb98ff9173893ded382c0a7381ad)
* window-slot: workaround search bar double borderCarlos Soriano2016-03-032-0/+8
| | | | | | | | | | We currently have a double border in the view due to the search bar using a revealer, which always allocates 1 px and therefore shows the bottom border. Since to fix it we would need widgets able to allocate 0 px, which is current impossible, we workaround it with a CSS style that moves the content 1 px upward.
* pathbar: add image-button class to iconic buttonsCarlos Soriano2016-03-031-0/+4
| | | | Request from Lapo.
* Updated Polish translationPiotr Drąg2016-03-031-440/+508
|
* file: use _() directly for date formattingCarlos Soriano2016-03-031-15/+15
| | | | | | | | | | We don't need to use N_() since it's not an array, but just a const char. This was causing problems with the date format not being translated, since N_() only marks for translation, but doesn't allow translator to actually translate. https://bugzilla.gnome.org/show_bug.cgi?id=750917
* shell-search-provider: make it work againCarlos Soriano2016-03-031-2/+1
| | | | | | | | | | | | | | | | | | | We removed the search action with a rework on the whole handling of views/slots/search-query handling to decouple the code better and not expose API that is not needed outside. The problem is that we actually needed a way to search from the application, since gnome-shell search provider communicates in that way. However we missed this since it was just an action in the application, which made us don't catch this. Now we allow a search in the whole stack but in a cleaner and direct way to not be in the same situation in the future. This patch use that to make the shell search provider work again. https://bugzilla.gnome.org/show_bug.cgi?id=762076
* general: allow to search from any part of the stackCarlos Soriano2016-03-038-0/+79
| | | | | | | | Expose the search function on the whole stack. We will need it for searches from the gnome-shell provider. https://bugzilla.gnome.org/show_bug.cgi?id=762076
* window-slot: remove unused priv varCarlos Soriano2016-03-031-1/+0
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=762076
* application: return the recent created window in open windowCarlos Soriano2016-03-031-1/+3
| | | | | | We will need it in an upcoming patch. https://bugzilla.gnome.org/show_bug.cgi?id=762076
* application: update modelineCarlos Soriano2016-03-031-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=762076
* shell-search-provider: don't crash if file doesn't have pathCarlos Soriano2016-03-031-1/+2
| | | | | | | | | Some backends doesn't support g_file_get_path, like the trash backends, and we were crashing trying to create a description with a NULL path. For those, just use the uri as a description. https://bugzilla.gnome.org/show_bug.cgi?id=762076
* preferences-window: add context to ordinalsCarlos Soriano2016-03-031-3/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=762851
* notebook: avoid updating if no childrenCarlos Soriano2016-03-033-1/+24
| | | | | | | | | | | | | | We were having a critical when a tab was searching and we closed the window due to the view reporting it's not loading anymore when the notebook already removed the slot. This is due to the slot working independently to the notebook, and the view reporting to stop loading on dispose, which is fine since the view needs to report its new status to the window as well. However the window also update the notebook when is the notebook that removes the slot and therefore dispose the view. To avoid that, check on the window if the notebook still contains the slot or not, and update only in that case.
* notebook: update modelineCarlos Soriano2016-03-031-1/+1
|
* files-view: select first file even when directory not fully loadedCarlos Soriano2016-03-031-0/+3
| | | | | | | | | | | | | | | Currently we were waiting until the view was fully loaded to select the first file. This is fine when only navigating. However, for search, we actually want to select the first file in order to allow the user to open right away the most relevant file. Let's see if this brings problems on icons jumping in large directories, but I hope it doesn't in the most common cases. https://bugzilla.gnome.org/show_bug.cgi?id=762595
* files-view: select first on loading only if no previous selectionCarlos Soriano2016-03-031-4/+12
| | | | | | | | | | | | Avoid to select the first file if there is a selection already. Although we were checking for the pending selection, it could be that there is a selection already because the user selected a file. This will be needed also for an upcoming patch, where we always select the first file on displaying new files, even if the directory is not fully loaded. https://bugzilla.gnome.org/show_bug.cgi?id=762595
* list-view: unselect all items before selecting a new oneCarlos Soriano2016-03-031-0/+1
| | | | | | It shouldn't happen, but better to be correct here. https://bugzilla.gnome.org/show_bug.cgi?id=762595
* files-view: fix styleCarlos Soriano2016-03-031-1/+1
|
* files-view: remove unused functionCarlos Soriano2016-03-031-20/+0
|
* properties-window: add comments for translatorsCarlos Soriano2016-03-031-3/+3
| | | | | | First, Second, Third were lacking context. https://bugzilla.gnome.org/show_bug.cgi?id=762851
* Updated Kazakh translationBaurzhan Muftakhidinov2016-03-031-390/+446
| | | | (cherry picked from commit 988a195a3d310359d00784a5575639add4137f40)
* Updated Brazilian Portuguese translationEnrico Nicoletto2016-03-031-211/+274
| | | | (cherry picked from commit 31be4e6c98f21927272578cc3d0d961c2002c60a)
* Updated Greek translationTom Tryfonidis2016-03-021-1475/+2095
| | | | (cherry picked from commit d1204c5576b9abc71d5790f0dc914178cfadcdce)
* Updated Hebrew translationYosef Or Boczko2016-03-021-2/+7
|
View Lorry Controller Status