GAppInfo and GAppLaunchContext are used for describing and launching
applications installed on the system. As of GLib 2.20, URIs will always be converted to POSIX paths
(using gFileGetPath) when using gAppInfoLaunch even if
the application requested an URI and not a POSIX path. For example
for an desktop-file based application with Exec key totem
% U and a single URI,
sftp://foo/file.avi, then
/home/user/.gvfs/sftp on foo/file.avi will be
passed. This will only work if a set of suitable GIO extensions
(such as gvfs 2.26 compiled with FUSE support), is available and
operational; if this is not the case, the URI will be passed
unmodified to the application. Some URIs, such as
mailto:, of course cannot be mapped to a POSIX
path (in gvfs there's no FUSE mount for it); such URIs will be
passed unmodified to the application. Specifically for gvfs 2.26 and later, the POSIX URI will be mapped
back to the GIO URI in the GFile constructors (since gvfs
implements the GVfs extension point). As such, if the application
needs to examine the URI, it needs to use gFileGetUri or
similar on GFile. In other words, an application cannot assume
that the URI passed to e.g. gFileNewForCommandlineArg is
equal to the result of gFileGetUri. The following snippet
illustrates this:
GFile *f;
char *uri; file = g_file_new_for_commandline_arg (uri_from_commandline); uri = g_file_get_uri (file);
strcmp (uri, uri_from_commandline) == 0; // FALSE
g_free (uri); if (g_file_has_uri_scheme (file, "cdda"))
{
// do something special with uri
}
g_object_unref (file);
This code will work when both cdda://sr0/Track
1.wav and /home/user/.gvfs/cdda on sr0/Track
1.wav is passed to the application. It should be noted
that it's generally not safe for applications to rely on the format
of a particular URIs. Different launcher applications (e.g. file
managers) may have different ideas of what a given URI means.