[cp-patches] RFC: GConf preference api backend
fitzsim at redhat.com
Fri Jun 16 17:56:13 UTC 2006
Mario Torre wrote:
> All the paperwork is signed, so this can be committed as is (if
> Fixed from the last (not committed) release is the fact that I'm
> currently turning the native implementation to reuse libraries in
> Classpath, most notably, now the native peer uses "jcl.h". The idea is
> to integrate the library into classpath, following the gtk peer example.
> Know issues:
> The backend works, but there are few problems when using some kinds of
> keys, most notably, keys with white spaces and other "special"
> characters (ie. "<" and ">").
> There are a couple of workaround to this, but they all require to change
> the keys inside the gconf database (an example, to use the schema to
> store the real key name, while storing the key with underscores instead
> of spaces). This seems to me not acceptable, so I decided to leave
> things as they are.
> This problem is gconf related, and there is at least one bug entry in
> the gnome bugzilla:
> I'll file a RFE to see if we can have a little support from the gconf
> team about this.
> The GConf module default node is located under:
> user root: /apps/java
> system root: /system
> These prefix are added to the node names, but are not exposed to users.
> This means that, whichever backend is used, a root node of "/my/app" is
> exposed always as "/my/app", even though the gconf backend uses
> "/apps/java/my/app" as real node.
> These prefixes can be changed using the following two system properties:
> Finally, the backend is chosen setting this property:
> java.util.prefs.PreferencesFactory =
> Though I worked a bit on it, there are surely some other caveats I am
> missing, but until now, all tests done passed. I also have a mauve test
> for the preference api, the test does not assume to use the gconf
> backend, and infact, was used to compare results of the gconf and the
> default file based preference implementation.
> The default backend is still the file based one, I suggest to enable the
> gconf one after a bit more of testing.
Thanks for this contribution! (FWIW, I wouldn't object if you wanted to make
this the default backend now). Please commit,
More information about the Classpath-patches