Guy Harris wrote:
Graeme Lunt wrote:
Well it creates a "file://" URL and then just tries to open this, so
appearing in Firefox is not unexpected - it is probably not your
configuration.
Maybe we need to put something more specific in for directories on Linux.
s/Linux/UN*X+X11/
At least if you hve the Portland Project program xdg-open:
http://portland.freedesktop.org/xdg-utils-1.0/xdg-open.html
installed, passing that program a pathname rather than a URL will, I
suspect, cause it to open the directory in the appropriate file viewer.
I've checked in a change to add a filemanager_open_directory() routine,
which takes a pathname of a directory as an argument and:
does the same thing as browser_open_url() on Windows;
takes a pathname handed to it, uses Core Foundation routines to
generate a (presumably file://) URL from it, and hands that to
LSOpenCFURLRef() on OS X;
runs xdg-open with the pathname on systems that are neither Windows nor
OS X and that have xdg-open.
That does the right thing on OS X and Ubuntu 7.10 (which has xdg-open) -
on Ubuntu, it opens the directory in Nautilus, *not* a browser - and
presumably does the right thing on Windows.
There might be other APIs available if xdg-open isn't available. GNOME
has gnome_url_show() for opening the appropriate viewer for a URL; I
don't know whether you're supposed to open a local file with a file: URL
or not. However, there's no GTK+-only API for that, as far as I know.
BTW, if we have xdg-open, should we just use that for opening URLs,
rather than offering a "specify your browser" preference?
