Preferred Applications Framework

[Benedikt Meurer]

Jannis Pohlmann wrote:
> That's true, of course. Being able to pass any file/URL over to exo-open
> is great, so there's no need for another option in the application
> framework. I can understand that URLs/eMails require a separate
> configuration, because they can't be mapped to a MIME type in a file
> manager.

Which brings us back to the org.xfce.FileManager discussion... Attached
is the latest version of the interface. IMHO it covers atleast the very
basic services that a file manager should provide to other applications
and it isn't too specific that it could cause trouble for any file
manager to implement.

The basic idea of the interface is to allow applications to talk to the
Xfce file manager (i.e. launch files, display folders, display
preferences, display file properties), without having to limit
themselves to a specific file manager (or to a list of file managers).
This way, the user can choose every file manager and it'll integrate
nicely into Xfce, as long as it implements this simple interface (and
provides the org.xfce.FileManager name -> AcquireName() method).

Edscott (and others), can you please have a look at the interface, and
tell if there's something important missing from the interface, or if
any of the methods causes trouble for xffm to implement. You'll find a
simple client implementation attached to this method, which can be used
to test the service. To generate a stub for the service implementation,
you can use the dbus-binding-tool:

dbus-binding-tool --prefix=xffm_dbus_service --mode=glib-server <
org.xfce.FileManager.xml > xffm_dbus_service_info.h

This will generate a xffm_dbus_service_info.h file, which includes the
required marshallers and D-BUS GObject info. Afterwards, write a
XffmDBusService class (or whatever other name) and in the class_init()
method, register the object info for the GType using
dbus_g_object_type_install_info(). In the init() method, you can then
register your object with the session bus and acquire the
org.xfce.FileManager name (I'd say we should agree to use
DBUS_NAME_FLAG_REPLACE_EXISTING, so the last file manager started by the
user will always have the org.xfce.FileManager name, i.e. starting Xffm
after Thunar, Thunar will loose the org.xfce.FileManager name and Xffm
will take over ownership, and vice versa). You'll also need to register
your object instance as /org/xfce/FileManager.

Afterwards, just implement the four methods required by the interface:

static gboolean
xffm_dbus_service_display_folder (XffmDBusService *dbus_service,
                                  const gchar     *uri,
                                  const gchar     *display,
                                  GError         **error)
{
   // do whatever is required to popup a new window for uri
}

etc.

You can have a look at the ThunarDBusService class, available from
http://svn.xfce.org/svn/xfce/thunar/trunk/thunar/thunar-dbus-service.c
to get an idea of how this works (it's really pretty easy with the new
GLib bindings).

The Makefile.am may help you to setup dbus-binding-tool to autogenerate
the stubs.

You may wonder about the DisplayPreferencesDialog() method in the
interface. The idea here is that we only need one "File Manager" icon in
the xfce-mcs-manager dialog. It's pretty confusing to have two icons
named "File Manager" in the MCS dialog. Therefore I think we should only
include a simple plugin for this (can be in xfce-mcs-plugin), which
invokes the DisplayPreferencesDialog() on the preferred file manager
(IIRC you weren't using MCS either as well, so that shouldn't be a
problem for Xffm).

All in all, this will allow smooth integration of whatever file manager
the user prefers into Xfce without hardcoding anything (i.e. it should
be fairly easy to write an implementation of the interface for ROX,
could be even a simple bridge that invokes ROX methods through SOAP).

Brian also asked about some more methods in here, most important,
methods to transfer files. How difficult would it be for Xffm to
implement the following methods (with proper user feedback, etc.)?

 CopyFiles (source-paths : ARRAY OF STRING,
            target-paths : ARRAY OF STRING,
            display : STRING) : VOID

 MoveFiles (source-paths : ARRAY OF STRING,
            target-paths : ARRAY OF STRING,
            display : STRING) : VOID

This could be useful to applications that want to copy/move around files
without having to care about user feedback themselves.

> - Jannis

Benedikt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org.xfce.FileManager.xml
Type: text/xml
Size: 2788 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20060208/f762d8ca/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xfce-file-manager-testtool.tar.gz
Type: application/x-gzip
Size: 1322 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20060208/f762d8ca/attachment.bin>