Op 24-02-13 20:30, Phil Longstaff schreef:
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.
Phil,
That looks like a good start for refactoring our Preferences system. As
said in another mail, that's not my current scope. So I am interested in
your work, but I'd only include it after 2.6.
Geert
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
