Mario Torre wrote:
Hi!

All the paperwork is signed, so this can be committed as is (if
accepted).

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:

http://bugzilla.gnome.org/show_bug.cgi?id=161209

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:

gnu.java.util.prefs.gconf.system_root
gnu.java.util.prefs.gconf.user_root

Finally, the backend is chosen setting this property:

java.util.prefs.PreferencesFactory =
gnu.java.util.prefs.GConfBasedFactory

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,

Thanks,
Tom


Reply via email to