Showing a file in the file manager

[PCMan]

On Sat, May 21, 2011 at 12:12 AM, Federico Mena Quintero
<federico at ximian.com> wrote:
> On Fri, 2011-05-20 at 12:06 +0800, PCMan wrote:
>
>> UI operations:
>>  select file in window
>>  open folder (this can be better than using mime-type handlers for folders IMO)
>>  show properties of selected files
>>
>> Is it possible to standardize these common operations?
>
> We can certainly standardize on the UI operations.  What should we use
> for the name - org.freedesktop.FileManager1 ?  (numbered for further
> additions)
>
> 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>

Do we need to specify where to show the file?
Last active file manager window
New window
New tab (fallback to new window if tabbed-browsing is not supported)

>    <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>

ShowInFolder, ShowItem, or SelectItem might be more appropreate than
ShowFile IMHO. Sometimes you might want to select something that's not
a file in the folder view.
Most of the time when you show a dir, you want to show its content in
folder view, but sometimes you may want to show its parent dir and
have it selected in it.

> 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.

Some use cases:
You can have "Show file properties" in image viewer, cd burner, file
chooser dialog like GtkFileChooser, or even GUI IDE like KDevelop or
Anjuta. Where apps want to show some files in the UI and want to
present more information about the files to the user, this API can be
quite useful.

> (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.)

I think these APIs are required and are not very hard to implement.
I/O abstraction only provides basic operations. The file manager API
here tries to provide something like copying directories with a nice
progress dialog and a "cancel" button to the users. For applications
which need to do some file operations inside them, this can be very
useful. We can have consistent UI for these file operations in various
apps.
Windows has similar shell API for moving or copying files since Windows 95.

>  Federico
>
>