[cp-patches] RFC: GConf preference api backend

Mario Torre neugens at limasoftware.net
Fri Jun 16 17:47:52 UTC 2006


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.

Mario
-----
Here is the Changelog:


2006-0-12  Mario torre  <neugens at limasoftware.net>

        * gnu/java/util/prefs/GConfBasedPreferences.java: new class.
        * gnu/java/util/prefs/GConfBasedFactory.java: new class.
        * gnu/java/util/prefs/gconf/GConfNativePeer.java: new class.
        * gnu_java_util_prefs_gconf_GConfNativePeer.h: generated
        header file.
        * classpath/native/jni/gconf-peer/GConfNativePeer.c: new C file.
        * configure.ac: update to introduce new files. Added options
        to build gconf native peer used by the GConf preference backend.
        * include/Makefile.am: update to introduce new files.
        * native/jni/Makefile.am update to introduce new files.
        * scripts/check_jni_methods.sh: added three new ignored file
        from check.
        * native/jni/gconf-peer/Makefile.am: new Makefile needed to
        build gconf-peer shared library.


-- 
Lima Software, SO.PR.IND. s.r.l.
http://www.limasoftware.net/
pgp key: http://subkeys.pgp.net/

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GConf_preference_backend.patch.tar.gz
Type: application/x-compressed-tar
Size: 9971 bytes
Desc: not available
Url : http://developer.classpath.org/pipermail/classpath-patches/attachments/20060616/d6899b77/GConf_preference_backend.patch.tar.bin


More information about the Classpath-patches mailing list