Preferences refactoring - important changes
Rev 20019 is a preferences refactoring mega-commit. Most of the changes are there in order to simplify adding a GConf backend soon (I'll get to this after cleaning up in the preferences.xml file and handling enum and color preferences sanely). Here are the most important changes from the developer perspective:
1. Preference path syntax has changed to use a single path and slashes instead of dots as separators. The old syntax was based on the fact that preferences are stored as attributes of XML nodes, which was the reason for separation of the two path parameters. The new syntax uses a familiar file system metaphor, and will simplify adding GConf and possibly other backends, like the Mac OS X settings files mentioned somewhere here (?).
2. Preferences are handled through the singleton object Inkscape::Preferences. Use its methods instead of the prefs-utils.h functions. They are mostly equivalent. Be sure to use the correct type.
3. There is no inkscape_get_repr() any more. To retrieve a CSS style from preferences, use the getStyle() or getInheritedStyle() methods.
4. You cannot add an XML observer to the prefs document. Instead, use the inner class Inkscape::Preferences::Observer. Additionally, you can't add the same observer to more than one preference path - you'll have to create multiple instances.
There are no changes to the preferences.xml format yet. There will be changes to it in the future, to remove things like /options/somerandomoption/value (which should be /options/some_random_option in GConf, or even better /options/some_appropriate_group/some_random_option) but I'll try to handle them transparently.
On Mon, Oct 20, 2008 at 12:38 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
There are no changes to the preferences.xml format yet. There will be changes to it in the future, to remove things like /options/somerandomoption/value (which should be /options/some_random_option in GConf, or even better /options/some_appropriate_group/some_random_option) but I'll try to handle them transparently.
Does "transparently" imply that the old prefs will be preserved for those who upgrade to the new version?
bulia byak wrote:
Does "transparently" imply that the old prefs will be preserved for those who upgrade to the new version?
Yes, this is what I meant. I intend to add a version attribute at the root of the pref file, with no attribute meaning lowest possible version, and store a mapping in the application (like: "/options/dragtolerance/value in version 0 corresponds to /options/selection/drag_tolerance in version 1"), then convert old files at first run.
To handle versions 2 and later, one only needs to store a mapping from version 0 to 1, and from version 1 to 2, then apply those iteratively if version 0 is encountered. This operation is rare so performance is not a concern.
Regards, Krzysztof Kosiński
On 10/20/2008 1:43 PM, Krzysztof Kosiński wrote:
bulia byak wrote:
Does "transparently" imply that the old prefs will be preserved for those who upgrade to the new version?
Yes, this is what I meant.
Good. I was wondering what would happen to users who could not use GConf.
bob
participants (3)
-
Bob Jamison
-
bulia byak
-
Krzysztof Kosiński