+2008-10-01 David Zeuthen <davidz@redhat.com>
+
+ * README.in: Add "Notes about glib 2.20" section detailing the
+ ramifications of the patch from bug #528670.
+
2008-09-30 Behdad Esfahbod <behdad@gnome.org>
Bug 554092 – glib doesn't return G_FILE_ERROR_NOENT et al on OS X
See the file 'INSTALL'
+Notes about GLib 2.20
+=====================
+
+^ The functions for launching applications (e.g. g_app_info_launch() +
+ friends) now passes a FUSE file:// URI if possible (requires gvfs
+ with the FUSE daemon to be running and operational). With gvfs 2.26,
+ FUSE file:// URIs will be mapped back to gio URIs in the GFile
+ constructors. The intent of this change is to better integrate
+ POSIX-only applications, see bug #528670 for the rationale. The
+ only user-visible change is when an application needs to examine an
+ URI passed to it (e.g. as a positional parameter). Instead of
+ looking at the given URI, the application will now need to look at
+ the result of g_file_get_uri() after having constructed a GFile
+ object with the given URI.
+
Notes about GLib 2.18
=====================
+2008-10-01 David Zeuthen <davidz@redhat.com>
+
+ * gdesktopappinfo.c (expand_macro): If possible, always pass FUSE
+ file:// URIs (such as '/home/davidz/.gvfs/sftp on foo/file.avi')
+ instead of the gio URI (such as sftp://foo/file.avi) when using
+ g_app_info_launch() and friends. With a sufficiently recent gvfs,
+ apps using gio+gvfs will map the FUSE file:// URI back to the gio
+ URI (and thus bypass the fuse daemon) thanks the patch from bug
+ #530654. Since Nautilus is an user of g_app_info_launch() it
+ means that non-gio POSIX apps, such as mplayer, will Just Work(tm)
+ when launced via the file manager. Win. Fixes bug #528670.
+
+ * gappinfo.c: Add some notes about the FUSE POSIX URI <-> GIO URI
+ mapping to the description of GAppInfo.
+
2008-09-30 Tor Lillqvist <tml@novell.com>
* tests/Makefile.am: Build desktop-app-info only on Unix.
* @include: gio/gio.h
*
* #GAppInfo and #GAppLaunchContext are used for describing and launching
- * applications installed on the system.
+ * applications installed on the system.
+ *
+ * As of GLib 2.20, URIs will always be converted to POSIX paths
+ * (using g_file_get_path()) when using g_app_info_launch() even if
+ * the application requested an URI and not a POSIX path. For example
+ * for an desktop-file based application with Exec key <literal>totem
+ * %%U</literal> and a single URI,
+ * <literal>sftp://foo/file.avi</literal>, then
+ * <literal>/home/user/.gvfs/sftp on foo/file.avi</literal> 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
+ * <literal>mailto:</literal>, 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 g_file_get_uri() or
+ * similar on #GFile. In other words, an application cannot assume
+ * that the URI passed to e.g. g_file_new_for_commandline_arg() is
+ * equal to the result of g_file_get_uri(). The following snippet
+ * illustrates this:
+ *
+ * <programlisting>
+ * 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);
+ * </programlisting>
+ *
+ * This code will work when both <literal>cdda://sr0/Track
+ * 1.wav</literal> and <literal>/home/user/.gvfs/cdda on sr0/Track
+ * 1.wav</literal> 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.
*
**/
{
GList *uris = *uri_list;
char *expanded;
-
+ gboolean force_file_uri;
+ char force_file_uri_macro;
+
g_return_if_fail (exec != NULL);
-
+
+ /* On %u and %U, pass POSIX file path pointing to the URI via
+ * the FUSE mount in ~/.gvfs. Note that if the FUSE daemon isn't
+ * running or the URI doesn't have a POSIX file path via FUSE
+ * we'll just pass the URI.
+ */
+ switch (macro)
+ {
+ case 'u':
+ force_file_uri_macro = 'f';
+ force_file_uri = TRUE;
+ break;
+ case 'U':
+ force_file_uri_macro = 'F';
+ force_file_uri = TRUE;
+ break;
+ default:
+ force_file_uri_macro = macro;
+ force_file_uri = FALSE;
+ break;
+ }
+
switch (macro)
{
case 'u':
case 'n':
if (uris)
{
- expanded = expand_macro_single (macro, uris->data);
+ if (!force_file_uri)
+ {
+ expanded = expand_macro_single (macro, uris->data);
+ }
+ else
+ {
+ expanded = expand_macro_single (force_file_uri_macro, uris->data);
+ if (expanded == NULL)
+ expanded = expand_macro_single (macro, uris->data);
+ }
+
if (expanded)
{
g_string_append (exec, expanded);
case 'N':
while (uris)
{
- expanded = expand_macro_single (macro, uris->data);
+ if (!force_file_uri)
+ {
+ expanded = expand_macro_single (macro, uris->data);
+ }
+ else
+ {
+ expanded = expand_macro_single (force_file_uri_macro, uris->data);
+ if (expanded == NULL)
+ expanded = expand_macro_single (macro, uris->data);
+ }
+
if (expanded)
{
g_string_append (exec, expanded);
projects / platform / upstream / glib.git / commitdiff