When I was looking at replacing GConf, I envisioned wrapping it as GncPrefs. I took some ideas from Java (java.util.prefs) such as: - hierarchy of prefs nodes. A prefs node can have values, but can also have prefs nodes as children. - GncPrefs would be base class, with GncPrefsGconf and GncPrefsBook (using the QofBook KVP) as subclasses for global and per-book prefs - hierarchy idea matched pretty well with GConf "directory" struct and with KVP frame struct - hierarchy idea matches pretty well with GSettings hierarchy idea - top level GncPrefs nodes for global and per-book. Could also have global per-user and per-book-per-user top level nodes. - could use GObject, but would much prefer C++ for creating subclasses - Would add GncPrefsGSettings to maintain independence of gnucash code from specific implementation technology
I ended up prototyping GncPrefs and GncPrefsGconf, and then renaming a number of GNC_GCONF_XXX #defines and gnc_gconf_xxx() functions to be GNC_GLOBAL_PREFS_XXX and gnc_global_prefs_xxx() for high-level directories and APIs. This code is on an old computer, but I could probably resurrect it if we want to use it as the basis. To isolate all traces of gconf to the GncPrefsGconf() would probably take a month or so. Knowledge is spread throughout the UI. This doesn't even take into account any behind-the-scenes cases of widgets storing values in gconf. ________________________________ From: Geert Janssens <janssens-ge...@telenet.be> To: gnucash-devel@gnucash.org Sent: Sunday, February 24, 2013 5:08:14 AM Subject: GSettings again GnuCash generally has long release cycles. 2.0.0 to 2.2.0 was roughly 3 years. 2.2.0 to 2.4.0 about 4 years and before 2.6.0 will be release another 3 years will have passed. This got me thinking about GConf/GSettings again. Currently the migration is not planned for 2.6. Which means it will make it's appearance at best in 2.8. And that would mean we'd have to carry GConf around for at least another 3 years. It is worse actually. To maintain a good user experience we will have to make all efforts to migrate all user settings from GConf to GSettings the first time they run GnuCash with GSettings support. GConf (as of 2.31) luckily comes with a tool that can do this migration. Using that tool also means we still require GConf to be around as long as we expect users to want to migrate. As our policy is that we support migration from one major release series to the first next major series (from 2.2.x to 2.4.x, from 2.4.x to 2.6.x) that would mean we will need to keep GConf around at least one major release cycle next to GSettings. So if we only introduce GSettings in 2.8, we will only be able to drop GConf in 3.0/2.10. That means at least 6 more years looking at bugs like [1] that are inherently tied to GConf's internals. I'm not looking forward to that. Which inspired me to instead look at what would be required to migrate to GSettings already in 2.6. Most part is pretty simple: - Make sure there is a complete schema for all settings keys used. We were missing a couple, but I have already added those in my local repo. - Convert the schema from GConf format to GSettings format. There is a tool for that. The end result probably needs a little tweaking, but most of the work is done automatically - Use the GSettings api instead of the GConf one in code. This is pretty much straight-forward find and replace stuff. With that GnuCash is GSettings ready. The trickier part is converting the existing preferences from GConf to GSettings. Again there is infrastructure to help us. There is a tool (part of GConf) that can do the migration for us. This tool needs a config file as input to know which keys from the old system match the keys in the new one. Again this config file will be fairly easy to write and is well documented. On linux systems, that's where our job would end. The conversion tool is supposed to be run automatically by the desktop environment each time a user logs in. I haven't verified if this works, but it does look like it. I have updated my linux system several times since GSettings was introduced and I never had the feeling I lost any preferences in those migrations. Several programs did migrate to GSettings in this time frame. On to Windows and OS X. On those two platforms we don't have the support of the environment to take care of this for us. So we'll have to run the conversion tool ourselves at application launch time. The documentation states explicitly that it doesn't harm to run the tool more than once even. It keeps track by itself whether or not the conversion has happened In principle, again not that much work. On to the caveats: - To use the migration tool, GConf must be 2.31 or more recent. That in itself does raise a few issues. - The first being this is not available on current Debian stable (squeeze). It is on Debian testing. If they continue their trend of the last couple of releases the new stable (wheezy) should be around the corner while GnuCash 2.6 is only planned for November this year. So I don't expect Debian squeeze to backport GnuCash 2.6. But even if they do, it should either also backport GConf 2.31 or more recent or worst case the user's preferences won't be migrated. This would be inconvenient but not dramatical. - Our Windows build currently ships GConf 2.22, the last version available in binary format on the gnome's ftp server. So we'd have to build a more recent version ourselves (which I'm currently working on). Other than these, I don't see any issues that would prevent this from being implemented rather sooner than later. So why do I bring all this up ? Mainly to discuss timing. We more or less aimed around this weekend to release our first 2.5 series development snapshot. I don't think I can finish the GSettings work this weekend. So we have three options: 1. postpone 2.5.0 a little more 2. release 2.5.0 without GSettings and include it in 2.5.1 (which means an exception on the feature freeze) 3. don't do GSettings at all in the 2.5/2.6 cycle (not my preference at all) Can I hear your opinions on this please ? Thanks, Geert [1] https://bugzilla.gnome.org/show_bug.cgi?id=681620 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
