GSettings again
Geert Janssens
janssens-geert at telenet.be
Thu Feb 28 09:40:36 EST 2013
Op 25-02-13 17:22, Derek Atkins schreef:
> Christian Stimming <christian at 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
More information about the gnucash-devel
mailing list