summaryrefslogtreecommitdiff
path: root/src/nautilus-mime-actions.c
Commit message (Collapse)AuthorAgeFilesLines
* mime-actions: use explicit slot for opening locationsCarlos Soriano2015-12-111-1/+5
| | | | | | | | | | Even if we wanted to always use the active window as the default action to open locations, seems gtk_get_active_windows doesn't work as expected for us. Until we figure out the problem, pass explicitly the target slot that the caller provides so users don't experience the location opening in a different window than the expected. https://bugzilla.gnome.org/show_bug.cgi?id=756499
* directory: assume recent as localCarlos Soriano2015-12-021-26/+1
| | | | | | | We were assuming trash and native_path as local, but not recent, which is wrong. So assume recent as local, with the benefit that we can use it for mime type polling and remove some dead code now.
* mime-actions: fix indentationCosimo Cecchi2015-11-161-8/+8
|
* mime-actions: print error in a g_warning() when not in a dialogCosimo Cecchi2015-11-161-1/+4
| | | | | Make sure we don't eat errors without at least printing them on the terminal.
* mime-actions: fix double free in error pathCosimo Cecchi2015-11-161-2/+0
| | | | | The "unhelpful error dialog" code already takes care of freeing the activation parameters. Make sure it does not do that twice.
* mime-actions: check for name owner for PackageKitCosimo Cecchi2015-11-161-4/+7
| | | | | We might not have a PackageKit name owner. Check for that case, or the system will think that it can install extra applications.
* general: separate handling of windows/slots/viewsCarlos Soriano2015-08-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is another step towards the isolation of the management of the direcotories, views, slots and windows. The current situation had a few issues: - the comunication of changes in the model was done in a bidirectional way. So for example, sometimes the view updates directly the slot, sometimes directly the window, and sometimes the window was listening to changes on the model and updating the slot, view, or model itself. Problem with this is, encapsulation is wrong, the code paths are confusing, and the public API exposed is big. - public API is big, so even if sometimes if convenient to not do the same thing twice, having public API that is actually covered by the GLib or Gtk API doesn't worth it, if the complexity of the API grows too much. In Nautilus case, specifically on the slot, we were allowing all kind of convenient API, but it was behaving differently depending on small connotations. - management was not encapsulated. So the window was modifyng the model, or doing actions that belongs to the slot or the view. The same thing for the slot and the view, and similarly for the application and the window. For example, we were handling the flag for creating new windows on a specific window, instead of relying on the application management. Similar cases for the slot and the view. - there were multiple code paths for opening a location. This is one of the biggest changes on the patch. We were exposing API to open a location in every component, and we were using that API from other components above or below the hierarchy randomly. So for example the view was using the opening location API from the slot, the window, and the application; but with the same pourpose, opening a location in the active window. - API was not explicit. For example sometimes we wanted to open a location in the current active window, but somtimes it was implicit and sometimes not, and to be safe we were making it explicit on the caller. - we were using mutiple code paths with the same intention. This is related to the previous one, the intention in every caller was not clear. This patch tries to improve the situation, also thinking on the future rework of the views and separation of the desktop handling. The patch applies the following rules: - If the API is provided somehow by nautilus-file or Glib or Gtk, don't add new API. Custom API is fine if it is used inside the component itself, since the added complexity for tracking code paths is not that important. - Use one way communication, from the top level to the innermost component. In case that the component needs top level features, ask the most top level. A specific example, the view provides opening a new window with a selection. Although encapsulation is good, there is not a good way to avoid the dance from the model to the view to the slot to the window to the application. So instead of that, allow a quick shorcut only communicating to the top most level. In this way, the code path is always the same (therefore much easier to debug or to change code) and encapsulation is preserved. - don't break encapsulation. Only allow management of the component to the component itself or its parent. So for example, the slot is the one that manages errors on what happens in the slot itself. Exception to this is the application, that needs access to all the hierarchy for specific situations. For example for updating the dbus locations or to discern between a desktop window or a common window. - if two way communication is needed, listen changes through properties. We have been moving to properties lately, since it clearer and cleaner and allow a few features that are useful like listening to its changes withouth explicit API for it. This allows to bind properties in a clean way throuh the hierarchy and not breaking the encapsulation. In this patch most of the ground work is done, and some things are remaining like moving all the loading of the location to the view instead of the slot. Even if it is convenient to have some management on the slot to share between the views, some views don't use models at all, or they are not common files, like the other-locations, and this breaks the situation. At some point what we want for the files-view is having a common model API, that can be on top of nautilus-file or in nautilus-file itself. With this patch, a serie of improvements can be done now, and they will come in future patches.
* Remove more unused methodsCosimo Cecchi2015-05-231-208/+0
| | | | Found with cppcheck.
* Revert "mime-actions: resolve symbolic links before launching the application"Cosimo Cecchi2014-05-121-10/+2
| | | | This reverts commit fe1965f2cafc4616caaea0ae048bf1ff5c8975f5.
* Updated FSF's addressDaniel Mustieles2014-01-311-2/+1
|
* Revert "mime-actions: filter applications not supposed to be visible"Cosimo Cecchi2013-09-171-24/+0
| | | | | | This reverts commit 7770b63d6726bc7ab4b886d6bd3edd009e622e55. https://bugzilla.gnome.org/show_bug.cgi?id=702681
* src: don't use deprecated GtkImageMenuItem and GtkStockCosimo Cecchi2013-08-131-7/+7
| | | | | There's another occurrence of GtkImageMenuItem right now, for the "Open With..." menu which is harder to fix.
* view: use g_app_info_get_name() for application names in Open With menusCosimo Cecchi2013-03-251-2/+2
| | | | | | | This is consistent with the Shell and what is used in the properties/Open With dialog. https://bugzilla.gnome.org/show_bug.cgi?id=696374
* mime-actions: filter applications not supposed to be visibleCosimo Cecchi2013-03-221-0/+24
| | | | | | | Ensure NoDisplay=True applications don't end up in our Open With context menus. https://bugzilla.gnome.org/show_bug.cgi?id=696372
* Normalize signal namesWilliam Jon McCann2013-01-221-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=692234
* mime-actions: minor cleanupCosimo Cecchi2012-11-121-5/+3
|
* mime-actions: don't invalidate symlink info twiceCosimo Cecchi2012-11-121-7/+0
| | | | | | | | | We already trigger a nautilus_file_call_when_ready() on the symlink file, which will include link information. Invalidating symlink info manually here will make us read invalid information in the ready callback instead. https://bugzilla.gnome.org/show_bug.cgi?id=687937
* view: use "Run" in menus for launching executablesCosimo Cecchi2012-11-051-0/+10
| | | | | | | When the expected action is running an executable file, we should use the term "Run" instead of "Open" in our menus. https://bugzilla.gnome.org/show_bug.cgi?id=687631
* all: don't use eel_g_str_list_copy()Cosimo Cecchi2012-10-231-1/+1
| | | | Use g_list_copy_deep() instead.
* mime-actions: resolve symbolic links before launching the applicationCosimo Cecchi2012-10-191-2/+10
| | | | | | | | | | We already do this for all other kind of references, and I think it makes sense to do it for symbolic links too. This also ensures applications don't have to deal with e.g. ensuring backup files are saved relative to the original file and not the symlink, as reported in https://bugzilla.gnome.org/show_bug.cgi?id=686465
* Quote the use of file type descriptions in error messagesWilliam Jon McCann2012-09-131-2/+2
| | | | | | | So that we don't have things like: "There is no application installed for backup file files." https://bugzilla.gnome.org/show_bug.cgi?id=683752
* Make sure the file is trashable before offering to move to TrashWilliam Jon McCann2012-08-301-7/+10
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=154478
* Don't show apps that don't support files or urisWilliam Jon McCann2012-08-271-10/+13
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=682729
* Use more specific text for unmount/eject error messagesWilliam Jon McCann2012-08-221-3/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=590513
* Use double quotes instead of ascii quotesWilliam Jon McCann2012-08-141-8/+8
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=681808
* Don't show a full path in the dialog for unknown file typesWilliam Jon McCann2012-08-141-12/+5
|
* all: remove nautilus_window_slot_go_to()Cosimo Cecchi2012-04-231-2/+1
| | | | | We don't want to have similar but slightly different code paths; consolidate use of NautilusWindowOpenFlags everywhere and simplify code.
* view: show applications for non launcher desktop filesCosimo Cecchi2012-03-071-3/+2
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=319981
* mime-actions: don't spawn a warning if we have only one applicationSandro Mani2011-09-071-1/+2
| | | | | | | Don't show a confirmation dialog when we're opening a number of files with the same application. https://bugzilla.gnome.org/show_bug.cgi?id=649811
* mime-actions: don't free the activation parameters earlyCosimo Cecchi2011-05-011-13/+12
| | | | | | | This fixes a segfault when clicking on the "Select Application" button when opening a file with no default applications, like in https://bugzilla.redhat.com/show_bug.cgi?id=699850
* all: merge NautilusNavigationWindow into NautilusWindowCosimo Cecchi2011-02-171-2/+1
|
* all: remove NautilusWindowOpenMode enumerationCosimo Cecchi2011-02-171-9/+2
| | | | The mode is now always decided by the GSettings preference.
* mime-actions: update the filtered out desktop files for foldersCosimo Cecchi2011-01-111-1/+1
|
* window-slot: cleanup of window_slot_open_location() functionsCosimo Cecchi2011-01-111-2/+2
|
* Rework architecture of NautilusWindow/NautilusWindowSlotInfoCosimo Cecchi2011-01-111-25/+28
| | | | | | | | | | | | | | | | | | | | | | In the past, nautilus was designed keeping in mind the concept that it might not just be a file browser, but a sort of platform to embed various kind of views in it. - libnautilus-private: general lowlevel items, such as the icon container, NautilusFile, I/O and so on - src: general widgets and UI items - src/file-manager: file manager views, agnostic of what's in src/, for the sake of being pluggable enough This is really not applicable anymore, as nautilus won't go in any direction other than being a file manager; at the same time, this complicates code and architecture quite a lot. In this commit, as a first step towards a more clean codebase, we remove the NautilusWindowInfo and NautilusWindowSlotInfo interfaces, using NautilusWindow and NautilusWindowSlot directly. Note that there should be no actual code changes, only moving of pieces around.
* mime-actions: move nautilus-mime-actions to src/Cosimo Cecchi2011-01-111-0/+2365
View Lorry Controller Status