summaryrefslogtreecommitdiff
path: root/src/nautilus-location-entry.c
diff options
context:
space:
mode:
authorCarlos Soriano <csoriano@gnome.org>2015-08-26 17:11:45 +0200
committerCarlos Soriano <csoriano@gnome.org>2015-08-28 23:48:17 +0200
commit28f50cfe6ee7290b92d4a69c7ee557f07d73cd64 (patch)
tree4f51b1d2d4fe90494d675cd50ca8ee3bc3227c8e /src/nautilus-location-entry.c
parent3309ea4c9b4a0d7dd324d366f3b50fe95685d579 (diff)
downloadnautilus-28f50cfe6ee7290b92d4a69c7ee557f07d73cd64.tar.gz
general: separate handling of windows/slots/views
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.
Diffstat (limited to 'src/nautilus-location-entry.c')
-rw-r--r--src/nautilus-location-entry.c10
1 files changed, 2 insertions, 8 deletions
diff --git a/src/nautilus-location-entry.c b/src/nautilus-location-entry.c
index f0c637d09..4c738bed2 100644
--- a/src/nautilus-location-entry.c
+++ b/src/nautilus-location-entry.c
@@ -225,11 +225,8 @@ drag_data_received_callback (GtkWidget *widget,
gpointer callback_data)
{
char **names;
- NautilusApplication *application;
int name_count;
- NautilusWindow *new_window;
GtkWidget *window;
- GdkScreen *screen;
gboolean new_windows_for_extras;
char *prompt;
char *detail;
@@ -290,13 +287,10 @@ drag_data_received_callback (GtkWidget *widget,
if (new_windows_for_extras) {
int i;
- application = NAUTILUS_APPLICATION (g_application_get_default ());
- screen = gtk_window_get_screen (GTK_WINDOW (window));
-
for (i = 1; names[i] != NULL; ++i) {
- new_window = nautilus_application_create_window (application, screen);
location = g_file_new_for_uri (names[i]);
- nautilus_window_go_to (new_window, location);
+ nautilus_application_open_location_full (NAUTILUS_APPLICATION (g_application_get_default ()),
+ location, NAUTILUS_WINDOW_OPEN_FLAG_NEW_WINDOW, NULL, NULL, NULL);
g_object_unref (location);
}
}