Op 25-02-13 17:22, Derek Atkins schreef:
Christian Stimming <christ...@cstimming.de> writes:
Am Sonntag, 24. Februar 2013, 11:08:14 schrieb Geert Janssens:
Other than these, I don't see any issues that would prevent this from
being implemented rather sooner than later.
Very good. If GSettings is gtk's replacement for GConf, we should use
it. I would not recommend starting our own wrapper or replacement of
such a preference function. I would also not recommend going for ini
files because in that case we have to deal with locking and multi-app
access issues on our own as well, which are always painful to deal
with.
I'm not sure why multi-app access would be an issue for GnuCash
preference files. I wouldn't expect other applications to access the
gnucash prefs. As for locking, I think it would only be an issue for
the per-data-file prefs, but in that case we already have to lock the
data file so not an issue. Are you worried about someone running
multiple instances of gnucash simultaneously?
I actually do this regularly. I often have private and business account
file open at the same time, for example to match up transactions between
my private accounts and business accounts. And no, I don't want to keep
those both in the same book. Due to how Belgian accounting law works
that could create a grey area open for lots of discussion with the tax
office. Not something I look forward to. So yes, global preferences
should be protected from multi-instance simultaneous write access.
However, it is certainly the case that GnuCash stores data in the system
preferences for 'hidden' preferences, like the register column widths.
That data can currently be accessed and reset via gconf-settings, so I
think it might remain important to provide some out-of-gnucash access to
the saved prefs. Having said that, however, I think an ini-file format
is probably just as accessible as a GUI; XML, not so much -- there would
need to be some tool to help editing the XML out-of-band.
IMHO.
-derek
An ini file is clearly as accessible yes, but not protected from
multi-instance simultaneous write access.
Having said all that, it may be that we are storing way too much in the
system-global preferences system (be it GConf or GSettings,..). Much of
the hidden information is actually book dependent, and could be migrated
to some form of ini file as you suggest. We already have our per-book
metadata file in .gnucash/books. This could be extended for that purpose
if we like.
However, that's not at all in the scope of my current goal, which is to
get rid of GConf as fast as possible with as little effort as possible
and yet not loose functionality. GSettings looks like the best match at
this point.
All the other preferences refactoring is also very welcome and needed.
But not before 2.6.
As for my GSettings work, I currently have a GSettings based replacement
ready for the GConf wrapper we have in GnuCash. The next part of the
work is actually using this new wrapper instead of the old one. 80% of
the work is find and replace. The other 20% will be manual work due to
slight and subtle differences between the GConf and GSettings interface.
Then I would still have to make sure we have a clean migration path for
our users, so they don't lose their preferences while migrating. At
least not the important ones.
Geert
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
