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