Created attachment 216888 [details] [review]
mountoperation: use the Shell DBus proxy if available

Make GMountOperation look for an owner of org.Gtk.MountOperationHandler
if possible, and use it instead of the GTK-based dialogs.
This allows applications to use the implementation offered by the
desktop shell, if available, through a DBus private interface:
org.Gtk.MountOperationHandler.

Review of attachment 216888 [details] [review]:

Looks good to me.

::: gtk/gtkdbusinterfaces.xml
@@ +4,3 @@
+  <!--
+    AskPassword:
+    @id: an opaque ID identifying the object for which the operation is requested

What is the context in which the id has to be unique ? Just the calling process, or globally ?
Also, the parameter name is object_id in the xml

@@ +18,3 @@
+    The dialog will stay visible until clients call the Close() method, or
+    another dialog becomes visible.
+    Calling AskPassword again for the same mount will have the effect to clear

'same mount' == 'with the same @id', here ?

@@ +84,3 @@
+    <arg type="a{sv}" direction="out" name="response_details"/>
+</method>
+<method name="Close"/>

I would have expected this to take the id, but I guess that's not necessary because of 'one-dialog-at-a-time' ?

::: gtk/gtkmountoperation.c
@@ +767,3 @@
+                                                 default_user, default_domain,
+                                                 operation->priv->ask_flags, NULL,
+                                                 call_password_proxy_cb, g_object_ref (operation));

I think I would prefer to move the g_object_ref calls out of this hidden spot, and add a comment like 'Hold an extra reference to operation while handler_showing is TRUE'. That will make it easier to find the matching unref.

the corresponding shell bug is bug 678516

Note that GVfs has its own two copies of mount-operation-over-dbus code [1], so this would be a third one... not saying it's wrong or anything (it's the right approach, I think), guess I'm just concerned about how distributed GVfs is -  there's a lot of places where things can fail... not asking you to fix this, just that it's something to be aware of...

[1] : one in common/gmountoperationdbus.c, another in monitor/proxy/gproxymountoperation.c

Created attachment 216932 [details] [review]
mountoperation: use the Shell DBus proxy if available

---

Fixed review comments; 
- yeah, Close() doesn't need to take an ID because only one dialog can be shown at a time
- the mount<->ID was just a leftover from a previous version of the code that took a mount root path
- it's sufficient for the ID to be unique to the process, since the server implementation can always make it globally unique by appending to it the bus name of the caller

Attachment 216932 [details] pushed as 44fd03e - mountoperation: use the Shell DBus proxy if available

Pushed a version with some additional fixes to git master.