GNOME Bugzilla – Bug 623723
use gsettings instead of gconf
Last modified: 2010-11-12 17:49:41 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.
+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.)
I'm considering moving this into GIO itself, foregoing the extension point.
Yes, please drop the extension point. That was just a lame way to be able to implement this.
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...
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.
(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 ?
(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".
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.
FYI, daemons port (a separate thing) to GSettings is bug 629085.
Okay, daemons have been ported and g_app_lookup removed. Closing.