GNOME Bugzilla – Bug 625894
Migrate from GConf to GSettings
Last modified: 2020-03-17 08:57:08 UTC
http://live.gnome.org/GnomeGoals/GSettingsMigration
Depends on GTK#3 first.
Created attachment 232010 [details] wip patch Made good progress in the gtk#3 branch: there's now a GSettingsSchemaExtractor[1] equivalent to the old GConfSchemaExtractor and some tests [2]. Quite a few challenges still ahead though: a) SchemaEntry elements which cannot be inspected statically: it can be solved, like I did for PersistentWindowController here [3], but there are more cases to solve. b) SchemaEntry elements for things which cannot be really dependent on an installed schema, because its prefix would be runtime-generated, example DAP sources, which have a UniqueID as part of their schema id. My guess for (b) is that we'll have to stick with XML configuration for those. If anyone wants to keep working where I left off, here's my WIP patch to replace GConf. I'll probably carry on after I relax my mind with other different task! [1] http://git.gnome.org/browse/banshee/tree/build/GSettingsSchemaExtractor.cs?h=gtk3 [2] http://git.gnome.org/browse/banshee/tree/build/GSettingsSchemaExtractorTests.cs?h=gtk3 [3] http://git.gnome.org/browse/banshee/commit/?h=gtk3&id=de6cf60f3b924ca77aee8e9fe647c551cb245172
Created attachment 232011 [details] [review] wip patch v2 Oops, missed a file in previous patch.
Created attachment 240448 [details] [review] wip patch v3 This is the first patch that uses relocatable schemas, which means that the (b) part I talked about in comment#2 is solved. Then the remaining parts are: 1) More cases to convert of type a) (I've actually been already committing this in gtk3 branch) 2) More cases to convert of type b). In the patch only 2 are converted, I plan to attack more soon. 3) Implement the Set() APIs (write to gsettings). 4) Clean up the autotools stuff (there are some MONO_PATH things to remove, and the install target should depend on the gschemas target).
That last patch seems corrupted: $ patch -p1 < gsettings.diff patching file Makefile.am Hunk #2 FAILED at 66. Hunk #3 succeeded at 117 with fuzz 1 (offset 4 lines). 1 out of 3 hunks FAILED -- saving rejects to file Makefile.am.rej patching file build/GSettingsSchemaExtractor.cs patch: **** malformed patch at line 91: @@ -212,6 +214,8 @@ public class GSettingsSchemaExtractorProgram
For the record, I did some work on this back in October, it's available on the "gsettings" branch on git.gnome.org: https://git.gnome.org/browse/banshee/log/?h=gsettings Still some work to do, anyone is welcome to jump in.
Hey Bertrand. I'm deeply sorry for not having followed-up on this before. (In reply to Bertrand Lorentz from comment #6) > Still some work to do, anyone is welcome to jump in. Do you mind explaining what did you think was missing? BTW, in regards to your patches, seems like the decision about making all schemas relocatable makes the implementation much simpler than my last patch that I posted here, I like it. However, why do you think we need to strictly remove the GSettingsSchemaExtractor like you did here? https://git.gnome.org/browse/banshee/commit/?id=3ef4ecd5f5e0c9c67ad070425a17ff11d91cd8bc I mean, couldn't we still run it as part of the build, just a sanity-check so that nobody forgets to add a new SchemaEntry without placing the correct entry in the XML?
Created attachment 308710 [details] [review] Experiments, WIP (In reply to Andrés G. Aragoneses (IRC: knocte) from comment #7) > Hey Bertrand. I'm deeply sorry for not having followed-up on this before. > > (In reply to Bertrand Lorentz from comment #6) > > Still some work to do, anyone is welcome to jump in. > > Do you mind explaining what did you think was missing? Replying to myself: Set() methods are still throwing NIEs, and more.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.