Op 24-02-13 16:01, John Ralls schreef:
On Feb 24, 2013, at 2:08 AM, Geert Janssens <janssens-ge...@telenet.be> wrote:
GnuCash generally has long release cycles. 2.0.0 to 2.2.0 was roughly 3 years.
2.2.0 to 2.4.0 about 4 years and before 2.6.0 will be release another 3 years
will have passed.
This got me thinking about GConf/GSettings again. Currently the migration is
not planned for 2.6. Which means it will make it's appearance at best in 2.8.
And that would mean we'd have to carry GConf around for at least another 3
years.
It is worse actually. To maintain a good user experience we will have to make
all efforts to migrate all user settings from GConf to GSettings the first time
they run GnuCash with GSettings support. GConf (as of 2.31) luckily comes with
a tool that can do this migration. Using that tool also means we still require
GConf to be around as long as we expect users to want to migrate. As our policy
is that we support migration from one major release series to the first next
major series (from 2.2.x to 2.4.x, from 2.4.x to 2.6.x) that would mean we will
need to keep GConf around at least one major release cycle next to GSettings.
So if we only introduce GSettings in 2.8, we will only be able to drop GConf in
3.0/2.10. That means at least 6 more years looking at bugs like [1] that are
inherently tied to GConf's internals.
I'm not looking forward to that. Which inspired me to instead look at what
would be required to migrate to GSettings already in 2.6.
Most part is pretty simple:
- Make sure there is a complete schema for all settings keys used. We were
missing a couple, but I have already added those in my local repo.
- Convert the schema from GConf format to GSettings format. There is a tool for
that. The end result probably needs a little tweaking, but most of the work is
done automatically
- Use the GSettings api instead of the GConf one in code. This is pretty much
straight-forward find and replace stuff.
With that GnuCash is GSettings ready. The trickier part is converting the
existing preferences from GConf to GSettings. Again there is infrastructure to
help us. There is a tool (part of GConf) that can do the migration for us.
This tool needs a config file as input to know which keys from the old system
match the keys in the new one.
Again this config file will be fairly easy to write and is well documented.
On linux systems, that's where our job would end. The conversion tool is
supposed to be run automatically by the desktop environment each time a user
logs in. I haven't verified if this works, but it does look like it. I have
updated my linux system several times since GSettings was introduced and I
never had the feeling I lost any preferences in those migrations. Several
programs did migrate to GSettings in this time frame.
On to Windows and OS X. On those two platforms we don't have the support of the
environment to take care of this for us. So we'll have to run the conversion
tool ourselves at application launch time. The documentation states explicitly
that it doesn't harm to run the tool more than once even. It keeps track by
itself whether or not the conversion has happened In principle, again not that
much work.
On to the caveats:
- To use the migration tool, GConf must be 2.31 or more recent. That in itself
does raise a few issues.
- The first being this is not available on current Debian stable (squeeze). It
is on Debian testing. If they continue their trend of the last couple of
releases the new stable (wheezy) should be around the corner while GnuCash 2.6
is only planned for November this year. So I don't expect Debian squeeze to
backport GnuCash 2.6. But even if they do, it should either also backport GConf
2.31 or more recent or worst case the user's preferences won't be migrated.
This would be inconvenient but not dramatical.
- Our Windows build currently ships GConf 2.22, the last version available in
binary format on the gnome's ftp server. So we'd have to build a more recent
version ourselves (which I'm currently working on).
Other than these, I don't see any issues that would prevent this from being
implemented rather sooner than later.
So why do I bring all this up ? Mainly to discuss timing. We more or less aimed
around this weekend to release our first 2.5 series development snapshot. I
don't think I can finish the GSettings work this weekend. So we have three
options:
1. postpone 2.5.0 a little more
2. release 2.5.0 without GSettings and include it in 2.5.1 (which means an
exception on the feature freeze)
3. don't do GSettings at all in the 2.5/2.6 cycle (not my preference at all)
Can I hear your opinions on this please ?
There's a problem with GConf > 2.28 on OSX: It won't talk to dbus. I think
that's due to the change from dbus-glib to
gdbus and a bug in the latter, but I haven't been able to figure it out.
On Windows for some reason GConf doesn't use dbus at all. I'd like to make OSX
do that too, which would mean that I could use a more recent GConf for the
transition.
Well, a little further in my experiment I have learned that the Windows
build is in a similar situation. It used 2.22 until now. Attempting to
build 2.31 will pull in a dbus dependency. I don't feel like going that
route just to be able to migrate from GConf to GSettings. So for now I
skipped this part and am considering writing a simple script that does
the same migration. Unlike on linux, GnuCash is the only user of the
gconf db. So it won't harm to read the gconf files directly and feeding
the contents to gsettings.
But in line with reducing our dependency upon GLib, how about getting rid of
both and using a plain ini file? Or if you think our schema is too deep for
that, a single xml preferences file? Do that many Linux users change their
Gnucash prefs from outside of Gnucash?
I see some benefit in sticking with a GLib based preferences solution
for now.
- At some point the whole preferences system will need some careful
attention. We have preferences littered in GConf, a meta resource file,
in the data file,... And for some preferences not too much thought has
gone into where they should be stored. But this is a large work. Not
something to start a couple of days before feature freeze.
- On the other hand GConf is a nuisance in the GnuCash code. I think you
will agree from your experience in the Quarz build.
- GSettings is very close to a drop in replacement for GConf. So it can
be done in a short time frame.
- It has one major compelling advantage over GConf: it uses native
backends on all platforms we care about. On linux that is dbus, on
Windows that's the registry. On OS X I don't know exactly, but it's
mentioned explicitly that there is a native backend on OS X as well. So
no more orbit/dbus related misery on OS X and Windows.
- Further on, as a GLib component, it integrates well with Gtk and
friends (direct binding of GSettings keys to GObject properties). I
realize we talked about GLib reduction, but at the end of the discussion
that was currently only aimed for at the engine level. The GUI will
certainly stay Gtk for a while, so for me it makes sense to take
advantage of the tool that go well with it.
In the future this may change if we effectively choose to move to
another GUI toolkit or someone really takes on refactoring the
preferences system. That is definitely not short-term though.
As a side note: our gconf logic is currently stored in core-utils, which
at some point may have made some sense. If we want to get the engine
GLib free, that should change. There is only one consumer of GConf data
in GnuCash that's *not* in the GUI code: the xml backend. This can
probably easily be factored out though. When that's done, the gconf code
that's currently in core-utils can move to for example app-utils, which
is our support library for all GUI modules.
Geert
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
