Showing a file in the file manager

[Jannis Pohlmann]

Hey,

On Fri, 20 May 2011 11:12:56 -0500
Federico Mena Quintero <federico at ximian.com> wrote:

> We can certainly standardize on the UI operations.  What should we use
> for the name - org.freedesktop.FileManager1 ?  (numbered for further
> additions)

Sounds fine to me.

> I just threw this together quickly; haven't validated it or anything:
> 
> <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection
> 1.0//EN"
> "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
> 
> <node>
>   <interface name="org.freedesktop.FileManager1">
>     <method name="ShowFile">
>       <arg name="uri" direction="in" type="s"/>
>       <arg name="parent_window_id" direction="in" type="x"/>
>       <arg name="timestamp" direction="in" type="x"/>
>     </method>
> 
>     <method name="ShowDirectory">
>       <arg name="uri" direction="in" type="s"/>
>       <arg name="parent_window_id" direction="in" type="x"/>
>       <arg name="timestamp" direction="in" type="x"/>
>     </method>
>   </interface>
> </node>
> 
> Both signatures for the ShowFile and ShowDirectory methods are
> identical
> - uri, parent_window_id, timestamp.
> 
> The URI is obvious; it's just the thing you want to be shown.
> 
> The parent_window_id is the X window that is the nominal "parent" of
> the resulting file manager window, for if your file manager wants to
> do an animation indicating "this window came from here" (hmmm, do we
> need source (x,y) coordinates as well?).
> 
> The timestamp is that of the event that caused the command to be
> invoked, for startup-notification - so that we can get window stacking
> correct.
> 
> Do we need a method to show the properties of a file, as PCMan
> suggested?  I'm not clear on how this would be used from an
> application.
> 
> (I think we should start with those methods, and only later discuss
> whether we need file-management operations like copy/move/delete...
> those can get complicated pretty quickly, and I guess our I/O
> abstractions already handle most of those, anyway.)

At Xfce we have most of this implemented in the D-Bus interface of
the Thunar file manager. We mainly use it to link the file manager and
desktop application together (which are two different processes).

The signatures of our methods are very similar to what you suggested:

    <!--
      DisplayFolder (uri : STRING, display : STRING) : VOID

      uri        : either a file:-URI or an absolute path.
      display    : the screen on which to display the folder or ""
                   to use the default screen of the file manager.
      startup_id : the DESKTOP_STARTUP_ID environment variable for
      properly handling startup notification and focus stealing.
    -->
    <method name="DisplayFolder">
      <arg direction="in" name="uri" type="s" />
      <arg direction="in" name="display" type="s" />
      <arg direction="in" name="startup_id" type="s" />
    </method>

and

    <!--
      DisplayFolderAndSelect (uri : STRING, filename : STRING,
    display : STRING) : VOID

      uri        : either a file:-URI or an absolute path.
      filename   : the name of the file in the folder which should
                   be selected by the file manager after loading the
                   folder. The file manager will also scroll the view
                   to ensure that the file is visible. The filename
                   must be a name relative to the folder URI.
      display    : the screen on which to display the folder or ""
                   to use the default screen of the file manager.
      startup_id : the DESKTOP_STARTUP_ID environment variable for
      properly handling startup notification and focus stealing.

      Note to implementors: Not all file managers may be able to
      implement this method properly for whatever reasons. If you
      cannot implement it properly, handle this method like an
      invocation of DisplayFolder() and ignore the filename.
    -->
    <method name="DisplayFolderAndSelect">
      <arg direction="in" name="uri" type="s" />
      <arg direction="in" name="filename" type="s" />
      <arg direction="in" name="display" type="s" />
      <arg direction="in" name="startup_id" type="s" />
    </method>

As you can see we pass the display to operate on as well as a startup
id. For the latter we use the same format as proposed in the startup
notification spec. I think it typically only includes a timestamp but
can also hold information about a possible parent window. That's a bit
more flexible.

Note that if someone calls "Thunar file://bar/foo.txt", the file
"/bar/foo.txt" is opened in the user's favorite application rather than
opening its directory and selecting it. So in that sense, Thunar acts a
bit like xdg-open and exo-open (which forwards unknown URIs/types to
Thunar to let Thunar figure out the favorite application). Summary:
Thunar behaves a bit different by default but the same concepts are
applicable of course.

I'm all in favor of trying to standardize a more feature-rich D-Bus
interface for file managers that also includes opening, selecting and
launching files/dirs as well as copy, move, link, delete and trash
operations etc. Such an interface might be useful. I think for most
of those features, the Thunar D-Bus API could be used as an inspiration.

But as you say (and I agree), we can add method by method and
it's good to start with something simple. 

  - Jannis