On Sat, May 21, 2011 at 12:12 AM, Federico Mena Quintero <[email protected]> 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 > > _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
