GNOME Bugzilla – Bug 651240
Check for schemas before trying to load them
Last modified: 2011-11-19 17:04:34 UTC
currently when a schemas is loaded, the gsettings behaviour can make the entire gnome-shell goaway and the user as no choice but reboot. Here is a workaround. for every gnome-shell code that needs to load a schema we should check that it's present, and if not advertise the user. here a code sample for this : has_schema: function(schema){ let schemas = Gio.Settings.list_schemas(); for(let i=0;i<schemas.length;i++){ if(schemas[i]==schema){ return true; } } return false; } and before loading the schema do : //check for the schemas before loading if(!this.has_schema(YOUR_SETTINGS_SCHEMA)){ global.log('xml schemas not installed'); <here add code to advertise the user of a broken installation> return; }
*** Bug 651225 has been marked as a duplicate of this bug. ***
Created attachment 188747 [details] [review] main: Add safe wrapper function for g_settings_new() g_settings_new() aborts if the requested schema is not found, so extensions which rely on optional schemas crash the shell. Provide a convenience function which checks the existance of a schema before creating the GSettings object and throw an exception if it does not exist.
Created attachment 188753 [details] [review] use the previous patch to check for schemas Patch for gnome-shell-extensions use the previous patch to check for schemas before loading them.
Review of attachment 188747 [details] [review]: event if this is the way to go, this patch is broken, in operator is not working like that for arrays, cf https://developer.mozilla.org/en/JavaScript/Reference/Operators/Special/in
Created attachment 188761 [details] [review] main: Add safe wrapper function for g_settings_new() (In reply to comment #4) > in operator is not working like that for arrays, cf > https://developer.mozilla.org/en/JavaScript/Reference/Operators/Special/in Woops, my bad ...
Review of attachment 188761 [details] [review]: it's okay for me. Applied in my branch and working like a charm
(In reply to comment #5) > Created an attachment (id=188761) [details] [review] > main: Add safe wrapper function for g_settings_new() > > (In reply to comment #4) > > in operator is not working like that for arrays, cf > > https://developer.mozilla.org/en/JavaScript/Reference/Operators/Special/in > > Woops, my bad ... IMO, should be fixed at the GSettings and/or GJS level. Add something at the GSettings level that has a GError *, and use rename annotations or Javascript overrides to make new Gio.Settings() use that.
I know, but i proposed this type of workaround as i fear that glib core developpers are not willing to change their minds. I hope that other voices will make them reconsider this.
(In reply to comment #7) > (In reply to comment #5) > > Created an attachment (id=188761) [details] [review] [details] [review] > > main: Add safe wrapper function for g_settings_new() > > > > (In reply to comment #4) > > > in operator is not working like that for arrays, cf > > > https://developer.mozilla.org/en/JavaScript/Reference/Operators/Special/in > > > > Woops, my bad ... > > IMO, should be fixed at the GSettings and/or GJS level. Add something at the > GSettings level that has a GError *, and use rename annotations or Javascript > overrides to make new Gio.Settings() use that. yeah, this is just a workaround for bug 649717 and/or bug 645254
i submitted a patch for correcting glib just in case glib dev change their minds: https://bugzilla.gnome.org/show_bug.cgi?id=651366
(In reply to comment #10) > i submitted a patch for correcting glib just in case glib dev change their > minds: > https://bugzilla.gnome.org/show_bug.cgi?id=651366 This changes existing behaviour. I don't think this will be received well. How about adding g_settings_try_new... I think a patch implementing the solutions discussed on bug 649717 would be more likey accepted.
yes of course, i can implement such a patch. thanks for the suggestion.
Bug 649717 has landed, which obsoletes the patch; closing.