GNOME Bugzilla – Bug 350953
ekiga should ship with URL handler gconf schemas
Last modified: 2006-09-02 14:59:26 UTC
Ekiga should ship with URL handler GConf schemas for h323, sip and callto URIs. Currently, we ship callto and h323 URI handler schemas with GConf. Bug 335132 has an attachment which can be applied against GnomeVFS. Afterwards, you can copy and paste the resulting schemas to ekiga.
Ekiga currently executes this code the first time it is run : conf_url = gm_conf_get_string ("/desktop/gnome/url-handlers/sip/command"); if (!conf_url) { gm_conf_set_string ("/desktop/gnome/url-handlers/sip/command", "ekiga -c \"%s\""); gm_conf_set_bool ("/desktop/gnome/url-handlers/sip/needs_terminal", false); gm_conf_set_bool ("/desktop/gnome/url-handlers/sip/enabled", true); } g_free (conf_url); It is doing the same for h323 and callto. Is that what you want or do you mean something else? Thanks,
In principle this is what we want. Having a schema would be a better alternative, though. See http://www.gnome.org/learn/admin-guide/latest/gconf-24.html for a conceptual description.
Hrm but then again I'm not sure whether this is really an application preference, so maybe your solution is even better. It's really an edge case. CCing gconf-maint.
No concerns have been raised, I think your solution is perfectly OK :).
Nice.
Nope, that solution doesn't entirely work in light of bug 335132. Look at the code above. It only sets the schema if the schema isn't already set, if !conf_url. But since gnomemeeting or gnome-vfs will in general have already set the schemas incorrectly to say gnomemeeting instead of ekiga, due to bug 335132, ekiga never sets those schemas, even on its first run.
The gnomemeeting_conf_upgrade () function in /ekiga/src/gui/config.cpp is entirely pointless with respect to the schemas. It doesn't change the schemas if they already exist (since then conf_url will be true), which they will if a user is upgrading from gnomemeeting. The function is a total misnomer-- it does not work at all for a user upgrading from gnomemeeting.
Sigh. Let's reopen then. How do we know we should set the handlers, or whether the user set them already to her/his liking and we shouldn't go against it?
Well, besides removing it from gnome-vfs (bug 335132), the ugly hack that I'd suggest would be testing to see if the schema is set to "gnomemeeting -c %s" and changing it to "ekiga -c %s" if it is, and doing nothing otherwise. If the user has set the schema to something else besides the gnomemeeting/gnome-vfs default, then leave it alone. That should be enough to handle all the reasonable cases.
Ugly hack committed ;-) Thanks.