Tried jumping to GNOME 2.5, with some broken local gconf changes. Lost
all my settings. Then GTK+ 2.3 rather than 2.2 breaks the GTK+ version
of Emacs somehow; the buffer and the toolbar end up with focus at the
same time. So every time you hit Enter while editing it activates one
of the toolbar buttons. This gets old fast.
It turns out there are a pile of outstanding gconf changes:
coalescing the XML backend hierarchy into fewer files,
moving change notifications into the backend, allowing custom
backend stacks, half of an LDAP backend. Since 2.5 is just getting
started and I have some time (relatively speaking), it’s probably time
to land all this kind of thing.
Changing gconf is risky; the smallest bug basically breaks the heck
out of your desktop and probably loses your launchers and email
account data and whatever else. But we have to do it sometime, so
buckle up beta testers.
My rough thinking is that in GNOME 2.6 we can do a solid chunk of
refactoring and cleaning up gconfd and the backends, then in
GNOME 2.8 we can address the client side with a new API and a D-BUS
access layer. The net result should be more robustness and fixing
problems such as these
(see also followup).
I’m keeping a page with gconf plans
that has some random subset of the ideas.
Another thing I want to do is fix up the test suite to be as nice as
the one for D-BUS; the gconf test suite is sort of a mess, making
refactoring a lot harder. Perhaps we can address the test suite issue
for each chunk of code as that chunk of code gets patched/reworked.
An open question; if we change the on-disk format for the XML backend,
do we keep the old backend as a read-only fallback at the end of the
user’s search path; or do we just move to a new directory alongside
~/.gconf and ignore the old settings; or what.
(This post was originally found at http://log.ometer.com/2003-10.html#2)