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.

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);
 		}
 	}