After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 623723 - use gsettings instead of gconf
use gsettings instead of gconf
Status: RESOLVED FIXED
Product: gvfs
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks: 622558
 
 
Reported: 2010-07-07 05:18 UTC by Matthias Clasen
Modified: 2010-11-12 17:49 UTC
See Also:
GNOME target: 3.0
GNOME version: ---


Attachments
patch (11.44 KB, patch)
2010-07-07 05:18 UTC, Matthias Clasen
none Details | Review
move to gio (16.65 KB, patch)
2010-07-08 04:18 UTC, Matthias Clasen
reviewed Details | Review

Description Matthias Clasen 2010-07-07 05:18:44 UTC
Created attachment 165395 [details] [review]
patch

Here is an untested port of the gconf app-lookup module to gsettings.

This uses api that will appear in glib 2.25.11, and the gsettings-desktop-schemas.
Comment 1 David Zeuthen (not reading bugmail) 2010-07-07 11:07:55 UTC
+void
+g_app_lookup_gsettings_register (GIOModule *module)
+{
+  g_app_lookup_gsettings_register_type (G_TYPE_MODULE (module));
+  g_io_extension_point_implement (G_DESKTOP_APP_INFO_LOOKUP_EXTENSION_POINT_NAME,
+                                  G_TYPE_APP_LOOKUP_GSETTINGS,
+                                  "gsettings",
+                                  10);

According to http://git.gnome.org/browse/gvfs/tree/gconf/gapplookupgconf.c#n170 the gconf backend is already using priority 10. We should probably pick something higher.

Also, XFCE's libfm is related, from http://www.google.com/codesearch/p?hl=en#tXWpX8nb6_k/libfm-0.1.12/src/gio/fm-app-lookup.c&q=libfm G_DESKTOP_APP_INFO_LOOKUP_EXTENSION_POINT_NAME&d=3&l=84

> void fm_app_lookup_register(GIOModule *module)
> {
>     gint priority;
>     fm_app_lookup_register_type(G_TYPE_MODULE (module));
>     /* check if we're in gnome, if true, use lower priority.
>      * otherwise, use a high priority to override gvfs gconf module.
>      * priority of the gconf module of gvfs is 10. */
>     if(G_UNLIKELY(g_getenv("GNOME_DESKTOP_SESSION_ID"))) /* we're in Gnome */
>         priority = 9;
>     else /* we're in other desktop envionments */
>         priority = 90;
> 
>     g_io_extension_point_implement(G_DESKTOP_APP_INFO_LOOKUP_EXTENSION_POINT_NAME,
>                                          FM_TYPE_APP_LOOKUP, "libfm-applookup", priority);
> 
>     /* TODO: implement our own G_NATIVE_VOLUME_MONITOR_EXTENSION_POINT_NAME */
> }

Awesome isn't it? Talk about these guys just missing the point entirely.

Actually, in light of this, I think we should just stop using the G_DESKTOP_APP_INFO_LOOKUP_EXTENSION_POINT_NAME completely (and I wouldn't consider it an ABI break) and instead do either

 1. Hard-code the implementation in GIO directly (it's fine - GSettings live in GIO now); or

 2. Use an approach as suggested in bug 606960 comment 13

(We should probably do the same other extension points too - for example, now that we have GDBus we can move the remote-volume-monitor feature in GIO proper. But that's unrelated to this.)
Comment 2 Matthias Clasen 2010-07-07 14:22:12 UTC
I'm considering moving this into GIO itself, foregoing the extension point.
Comment 3 Alexander Larsson 2010-07-07 21:43:44 UTC
Yes, please drop the extension point. That was just a lame way to be able to implement this.
Comment 4 Matthias Clasen 2010-07-08 04:18:17 UTC
Created attachment 165452 [details] [review]
move to gio

This patch moves the gsettings implementation to gappinfo.c. The extension point had some api associated with it (GDesktopAppInfoLookup), which I've left around deprecated, to avoid breaking the build of implementors of the extension point.

This is untested, and I'd appreciate feedback on this, as well as on the naming choices for the schema (org.gtk.url-handlers, /org/gtk/url-handlers). The schema is a bit funny, with defaults like gaim and gnomemeeting...
Comment 5 Allison Karlitskaya (desrt) 2010-07-08 13:31:45 UTC
Review of attachment 165452 [details] [review]:

overall i'm not sure i understand this patch...

what will happen on windows?  shouldn't we defer to their native stuff?

::: configure.in
@@ +3660,3 @@
 
+GLIB_GSETTINGS
+GLIB_COMPILE_SCHEMAS=./glib-compile-schemas

this seems like it's really going to cause a lot of problems....

if we want to do something like this we should either add proper support to the m4 or just forget the m4 and do it manually...

::: gio/gappinfo.c
@@ +849,3 @@
+  child = NULL;
+
+  /* FIXME: this should be a settings list, to be extensible */

note: that may be problematic

in theory you have no control over the 'id' of a child item in a GSettingsList -- you merely get to give a hint.

two ways that this could be handled:

  1) encode the type of the url into the hint

  2) add a "uri type" field to each item and check that

@@ +868,3 @@
+
+  command = g_settings_get_string (child, "command");
+  if (command)

this sort of crap is pointless with GSettings.

the schema says "string".  trust me... you'll get a string.


checking the length of that string might be meaningful, however...

::: gio/org.gtk.url-handlers.gschema.xml
@@ +11,3 @@
+    <child name="callto" schema="org.gtk.url-handlers.callto"/>
+    <child name="h323" schema="org.gtk.url-handlers.h323"/>
+  </schema>

with these schemas having so much in common it might make sense to have a base implementation ('org.gtk.url-handler') and have the various specific implementations subclass it.  the schema compiler should be capable of handling that at this point.  After declaring the base schema, just do:

<schema id='org.gtk.url-handlers.trash'
        path='/org/gtk/url-handlers/trash/'
        extends='org.gtk.url-handlers'>
  <override name='command'>nautilus "%s"'</override>
</schema>

@@ +12,3 @@
+    <child name="h323" schema="org.gtk.url-handlers.h323"/>
+  </schema>
+  <schema id="org.gtk.url-handlers.trash" path="/org/gtk/url-handlers/trash/">

about the path: please go on d-d-l and fight about this. :)

i don't care one way or the other -- i just care that people don't agree on what to do and they are doing different things.
Comment 6 Matthias Clasen 2010-07-08 14:33:09 UTC
(In reply to comment #5)
> Review of attachment 165452 [details] [review]:
> 
> overall i'm not sure i understand this patch...
> 
> what will happen on windows?  shouldn't we defer to their native stuff?

Maybe, but as things currently stand in gwin32appinfo.c:

GAppInfo *
g_app_info_get_default_for_uri_scheme (const char *uri_scheme)
{
  /* TODO: Implement */
  return NULL;
}

That being said, we can easily move this down into gdesktopappinfo.c and continue to let win32 have a NULL implementation.


> ::: configure.in
> @@ +3660,3 @@
> 
> +GLIB_GSETTINGS
> +GLIB_COMPILE_SCHEMAS=./glib-compile-schemas
> 
> this seems like it's really going to cause a lot of problems....
> 
> if we want to do something like this we should either add proper support to the
> m4 or just forget the m4 and do it manually...

It was too late at night, and I was too lazy to copy all the stuff to do it manually. But I agree


> ::: gio/gappinfo.c
> @@ +849,3 @@
> +  child = NULL;
> +
> +  /* FIXME: this should be a settings list, to be extensible */
> 
> note: that may be problematic
> 
> in theory you have no control over the 'id' of a child item in a GSettingsList
> -- you merely get to give a hint.
> 
> two ways that this could be handled:
> 
>   1) encode the type of the url into the hint
> 
>   2) add a "uri type" field to each item and check that

Hmm. If we move the uri-scheme into the item, we loose uniqueness, I fear.
Can't we just decree that if you want to install a default handler for a uri scheme, you must choose id == scheme ? Or are you saying that whoever adds to the list has no control over the id either ?!


> @@ +868,3 @@
> +
> +  command = g_settings_get_string (child, "command");
> +  if (command)
> 
> this sort of crap is pointless with GSettings.
> 
> the schema says "string".  trust me... you'll get a string.

Right. I just blindly copied that. Will be removed

> 
> checking the length of that string might be meaningful, however...
> 
> ::: gio/org.gtk.url-handlers.gschema.xml
> @@ +11,3 @@
> +    <child name="callto" schema="org.gtk.url-handlers.callto"/>
> +    <child name="h323" schema="org.gtk.url-handlers.h323"/>
> +  </schema>
> 
> with these schemas having so much in common it might make sense to have a base
> implementation ('org.gtk.url-handler') and have the various specific
> implementations subclass it.  the schema compiler should be capable of handling
> that at this point.  After declaring the base schema, just do:
> 
> <schema id='org.gtk.url-handlers.trash'
>         path='/org/gtk/url-handlers/trash/'
>         extends='org.gtk.url-handlers'>
>   <override name='command'>nautilus "%s"'</override>
> </schema>

If we go for a list, there will only be a single schema anyway, right ?
Comment 7 Dan Winship 2010-07-08 19:39:51 UTC
(In reply to comment #4)
> This is untested, and I'd appreciate feedback on this, as well as on the naming
> choices for the schema (org.gtk.url-handlers, /org/gtk/url-handlers).

Maybe rename this to "uri-handlers" instead of "url-handlers"? The platform has been moving in that direction for years, and glib is 99% consistent about using "URI" rather than "URL".
Comment 8 Allison Karlitskaya (desrt) 2010-07-09 14:47:24 UTC
We decided on IRC that this approach is not the way forward.

We want to do something more robust, based on desktop files, rather than any kind of settings database.
Comment 9 Tomas Bzatek 2010-09-08 16:29:29 UTC
FYI, daemons port (a separate thing) to GSettings is bug 629085.
Comment 10 Tomas Bzatek 2010-11-12 17:49:41 UTC
Okay, daemons have been ported and g_app_lookup removed. Closing.