Use cases for "show in file manager" action:

rhythmbox/banshee: I want to go to the file of a song to do file management.

transmission/deluge/epiphany/firefox: I downloaded a file and want to move it to a different directory or rename/open it. (The Downloads directory can be quite big, making it hard to find the file manually as it is now.)

All detailed actions are very useful for application integration and even shell scripting.

I develop Kupfer (application launcher and "commands" shell) which uses all kinds of application commands that are available. 'Focus a file' would be very useful (we currently have Thunar integration for the same thing), as well as Empty Trash. But first on the wishlist are file operations: Moving and Copying files. This is so that every program does not have to repeat the implementation of not only the operation itself but the progress display GUI and cancellation possibility etc!

I'm sure other tools will be quick to pick up nautilus integration as well.

Loose ideas:
* Consider also "Focus multiple files" action.
* Allow accessing the URIs currently selected file(s) in nautilus and a signal for when it changes.

We have discussed what D-Bus interface to use across file managers.  The discussion is here:

http://lists.freedesktop.org/archives/xdg/2011-May/011949.html

The thread ended with this interface:

org.freedesktop.FileManager1

void ShowItems (in string uris[], in string startup_id);
  Shows folder windows as necessary to show the specified URIs, and highlights/selects the URIs in question.

void ShowFolders (in string uris[], in string startup_id);
  Shows folder windows for the specified URIs, which are assummed to be folders.

void ShowItemProperties (in string uris[], in string startup_id);
  Shows file-properties windows for the specified URIs.

I'm assigning this bug to Akshay Gupta, who is working on this for the Summer of Code 2011.

For reference, this is the pattern from Document-centric Gnome: http://live.gnome.org/DocumentCentricGnome/Circulation%20for%20your%20files

https://github.com/kitallis/nautilus/commit/749eb0f78cca2bbaa9e4d2b032618ffa051b1e76

and 

https://github.com/kitallis/nautilus/commit/749eb0f78cca2bbaa9e4d2b032618ffa051b1e76

from https://github.com/kitallis/nautilus/commits/gnome3

can currently do this:

ShowFolders(file) → Launches containing folder window for file
ShowFolders(folder) → Launches folder window
ShowItemProperties(file|folder) → Launches property windows for each file/folder
ShowItems(file) → Launches containing folder window with file selected
ShowItems(folder) → This doesn't work at the moment and I'd require assistance writing this out. This is supposed to launch the parent folder with the child folder selected.

This also moves nautilus-dbus-manager from libnautilus-private/ to src/ and adds a new public method - nautilus_application_show_files() in nautilus-application

Please check coding style and/or other issues. 
Thanks!

Hi,

I was wondering has there been any progress done on this, because if not I would like to help.

Hi Dejan,

Akshay has already started to work on this, but I don't know the status.
If some Nautilus maintainer could have a look to the code, that would be great.

Regards.

I've updated Akshay's patches for nautilus master (which uses gdbus-codegen instead of marshalling things by hand), and pushed a branch called "freedesktop-dbus".

We have an implementation for this:

  <interface name='org.freedesktop.FileManager1'>
    <method name='ShowFolders'>
      <arg type='as' name='URIs' direction='in'/>
      <arg type='s' name='StartupId' direction='in'/>
    </method>
    <method name='ShowItems'>
      <arg type='as' name='URIs' direction='in'/>
      <arg type='s' name='StartupId' direction='in'/>
    </method>
    <method name='ShowItemProperties'>
      <arg type='as' name='URIs' direction='in'/>
      <arg type='s' name='StartupId' direction='in'/>
    </method>
  </interface>

Some notes about the implementation:

* These methods want different "show a folder and select a file inside it" (ShowItems) and "show a folder" (ShowFolders).  However, NautilusApplication only has a single version; it sees if the passed URI is a file or a folder, and shows the selected item or the folder's contents, respectively.  Everything works as expected until you call ShowItems("/some/subfolder") - that's supposed to show the "some" folder and highlight the "subfolder" item, but instead Nautilus shows the contents of /some/subfolder.

* I found no easy way to take the startup_ids from the DBus calls and pass them on to GTK+.

* There is a new nautilus/data/freedesktop-dbus-interfaces.xml, apart from the previous dbus-interfaces.xml.  The new iface is kept separate, as it has a different namespace, and gdbus-codegen produced really ugly code if left together in the same file.

* Rather than put everything in libnautilus-private/nautilus-dbus-manager.c, I put the freedesktop part in src/nautilus-freedesktop-dbus.c.  This avoids having to call stuff in src/ from libnautilus-private/ (Akshay ran into this problem), and in my opinion leads to a cleaner per-interface implementation.

Created attachment 202953 [details] [review]
nautilus-freedesktop-dbus.diff

For reference, these are the patches from the freedesktop-dbus branch.

Review of attachment 202953 [details] [review]:

Hi, I inlined some comments on the code below. Do you already have some consumer of this interface in mind?

Some other general comments:
- I would like the two dbus objects to have the same structure; as NautilusDBusManager is a GObject singleton, it'd be good if this freedesktop manager was the same
- It's possible to tweak the NautilusApplication code to make it select a subfolder inside the parent in case a specific flag is enabled
- As for the startup_id mess: is gtk_window_set_startup_id() of any help here?

::: src/nautilus-freedesktop-dbus.c
@@ +110,3 @@
+		g_object_unref (object_manager);
+		object_manager = NULL;
+	}

You can use g_clear_object on object_manager as well.

::: src/nautilus-properties-window.c
@@ +4971,3 @@
 	}
 	if (cancel_destroy_handler) {
+		if (startup_data->parent_widget)

You can merge these two nested conditions using an && in the first if.

Comment on attachment 202953 [details] [review]
nautilus-freedesktop-dbus.diff

>+static gboolean
>+skeleton_handle_show_items_cb (NautilusFreedesktopFileManager1 *object,

>+
>+	for (i = 0; uris[i] != NULL; i++) {
>+		GFile *file;
>+		GFile *files[1];
>+
>+		file = g_file_new_for_uri (uris[i]);

I don't really like this: g_application_open() already has code to handle file arrays, so can't you make an array of GFiles out of the uris and pass that?

>+static gboolean
>+skeleton_handle_show_folders_cb (NautilusFreedesktopFileManager1 *object,

>+	for (i = 0; uris[i] != NULL; i++) {
>+		GFile *file;
>+		GFile *files[1];
>+
>+		file = g_file_new_for_uri (uris[i]);

Same here

Thanks for the excellent review, Cosimo :)

I'll post updated patches, probably tomorrow.  You made my day with gtk_window_set_startup_id(); I didn't know that existed (and it's been there since 2.12...!)

Created attachment 203410 [details] [review]
First round of cleanups

This addresses all of Cosimo's comments; it's a git format-patch patchset.

* Turned NautilusFreedesktopDBus into a GObject.

* Adds nautilus_application_open_location() and uses that instead of g_application_open(), so that we can distinguish between showing a location plus a selection, and just showing a location.

* Adds nautilus_properties_window_present_with_startup_id().

* Cleanups as Cosimo suggested.

This is in the freedesktop-dbus branch.  If you think the code is OK, we can merge it to master.

One thing I haven't solved yet is how this will get activated.  We don't want a .service file, as multiple file managers may be installed and they may all implement this interface.  In theory, the appropriate file manager for your desktop environment should be launched.  Is there a way for gnome-settings-daemon or something to capture the "someone needs an org.Freedesktop.FileManager1" request from the DBus session daemon, and redirect it to a launched-in-time Nautilus?

(In reply to comment #13)

> This addresses all of Cosimo's comments; it's a git format-patch patchset.

Thanks for the updated patchset Federico!

> This is in the freedesktop-dbus branch.  If you think the code is OK, we can
> merge it to master.

I pushed a couple of commits on top of the freedesktop-dbus branch to address some additional minor bugs or coding style oddities. I am happy with the branch now, so feel free to merge it to master if you like my changes.

> One thing I haven't solved yet is how this will get activated.  We don't want a
> .service file, as multiple file managers may be installed and they may all
> implement this interface.  In theory, the appropriate file manager for your
> desktop environment should be launched.  Is there a way for
> gnome-settings-daemon or something to capture the "someone needs an
> org.Freedesktop.FileManager1" request from the DBus session daemon, and
> redirect it to a launched-in-time Nautilus?

Indeed, I can see how this can be tricky; this was discussed in the original thread here [1].
I don't really like the idea of a central daemon acting as a broker proxy here though, and I am almost 100% positive we don't want any of this logic in gnome-settings-daemon, so we probably want to install a .service file instead.

FWIW, applications that expect Nautilus to be executed, shouldn't call over this freedesktop DBus interface, but explicitly invoke nautilus from the command line, so I am not sure if this is really an issue.

[1] http://lists.freedesktop.org/archives/xdg/2011-May/011965.html

Comment on attachment 203410 [details] [review]
First round of cleanups

Marking as a-c-n, as for last comment.

(In reply to comment #14)

> I pushed a couple of commits on top of the freedesktop-dbus branch to address
> some additional minor bugs or coding style oddities. I am happy with the branch
> now, so feel free to merge it to master if you like my changes.

Perfect; everything looks good.  I like the cleanups.

(One nitpick: "static Foo *foo = NULL" - that puts foo in the .data in the binary, not in the bss, and the latter is cheaper.  Or at least that was the case years ago; I don't know if GCC is smart enough these days to say, "oh, this is zeroed anyway".)

I'll do two things before merging this into master:

- Now that nautilus_properties_window_present() just calls prepare_properties_window(), I'll move the code from the latter into the former and remove the helper function.

- Install a .service file, as you said.
 
> I don't really like the idea of a central daemon acting as a broker proxy here
> though, and I am almost 100% positive we don't want any of this logic in
> gnome-settings-daemon, so we probably want to install a .service file instead.

OK, I'll put in a .service file for now.

If fd.o interfaces start to proliferate, this will become a general problem.  I guess I'll ask in the dbus mailing list.  I *think* I'd be happy with a scheme that allowed a desktop environment to tell the DBus daemon, "hey, redirect service requests to me, and I'll probably figure them out" - kind of a DNS service.

> FWIW, applications that expect Nautilus to be executed, shouldn't call over
> this freedesktop DBus interface, but explicitly invoke nautilus from the
> command line, so I am not sure if this is really an issue.

About this, I didn't answer this question you had:

> Do you already have some consumer of this interface in mind?

Indeed; this is for the "show in file manager" commands that are appearing in applications.  The rationale is in http://live.gnome.org/DocumentCentricGnome/Circulation%20for%20your%20files

This is so that apps can have the file manager show the document they are editing, even apps that are not native to the desktop environment.  See things like http://redmine.yorba.org/issues/2129 - Shotwell *is* a Gnome app, but it shares the problems that other apps have historically had with wanting to show a file in the file manager - xdg-open can't do it, and calling a particular file manager is, well, not portable.

(In reply to comment #16)

> I'll do two things before merging this into master:
> 
> - Now that nautilus_properties_window_present() just calls
> prepare_properties_window(), I'll move the code from the latter into the former
> and remove the helper function.
> 
> - Install a .service file, as you said.

Ok, sounds good.

> If fd.o interfaces start to proliferate, this will become a general problem.  I
> guess I'll ask in the dbus mailing list.  I *think* I'd be happy with a scheme
> that allowed a desktop environment to tell the DBus daemon, "hey, redirect
> service requests to me, and I'll probably figure them out" - kind of a DNS
> service.

Yeah; the fundamental problem here is that we have two kind of plug capabilities at two very different points in the stack (DBus services and the mime system).
I also can see how delegating the spawning of session processes to a session broker could solve this, but I don't have enough knowledge of the DBus lower levels to understand whether this is actually a good idea, or feasible at all.
It is indeed a general problem though, that's why I was reluctant doing anything custom for this specific case in my previous comment.

> This is so that apps can have the file manager show the document they are
> editing, even apps that are not native to the desktop environment.  See things
> like http://redmine.yorba.org/issues/2129 - Shotwell *is* a Gnome app, but it
> shares the problems that other apps have historically had with wanting to show
> a file in the file manager

I see; Shotwell is probably a good example since it's possibly one of those applications commonly in use in more than a desktop environment. 

On the other hand, another part of me wonders if it's really reasonable for applications to assume supporting this kind of deep integration for GNOME/KDE/$your_linux_flavor_of_choice should come for free via some generic interfaces (e.g. if we named the interface org.gnome.FileManager instead of org.freedesktop.FileManager we wouldn't have this problem now); in other words I wonder whether it's worth all the extra complications, since probably an app like Shotwell will have fallback code to handle the case where it's not running with a file manager supporting this interface anyway.

(In reply to comment #17)
> Ok, sounds good.

Merged and pushed to master; thanks!!!

> It is indeed a general problem though, that's why I was reluctant doing
> anything custom for this specific case in my previous comment.

Yeah, no problem.

> On the other hand, another part of me wonders if it's really reasonable for
> applications to assume supporting this kind of deep integration for
> GNOME/KDE/$your_linux_flavor_of_choice should come for free via some generic
> interfaces (e.g. if we named the interface org.gnome.FileManager instead of
> org.freedesktop.FileManager we wouldn't have this problem now); in other words
> I wonder whether it's worth all the extra complications, since probably an app
> like Shotwell will have fallback code to handle the case where it's not running
> with a file manager supporting this interface anyway.

It's what ISVs have been asking for, for years :)

Anyway, we'll discuss it further.  Closing the bug for now.

And again, thanks to Akshay for doing the legwork on this.

For reference, this is now documented in http://www.freedesktop.org/wiki/Specifications/file-manager-interface

For reference, an example incantation for calling this from the command line:

dbus-send --print-reply --dest=org.freedesktop.FileManager1 /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems array:string:"file:///home" string:test

I'm not sure what one should provide as the second argument (StartupId) though.

Note that the --print-reply seems to be necessary, see this freedesktop bug:

https://bugs.freedesktop.org/show_bug.cgi?id=52372

The StartupId is as per the startup notification spec:
http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt

It's so that Nautilus can have the correct timestamp when popping up its new window.

Firstly, congrats to federico, cosimo and everyone who worked on this! ..

.. and now for anyone interested, I'm currently trying to push a firefox patch that uses this dbus interface to interact with the file manager when executing the "Open containing folder" action from the downloaded files list, so the file can be selected inside the folder (the same way this is done in firefox windows version). See here for more info:

https://bugzilla.mozilla.org/show_bug.cgi?id=417952#c12