On Sun, 12 Jun 2005, Jeremy Sanders wrote:
I've taken the opportunity to do some code clean ups. There didn't seem any
point having two objects. settingdb['foo'] is now used instead of
settingdb.database['foo']. I've gone round and changed all the references.
Excellent. I probably should have just made the changes...
I also read the settings into a dict at startup, and write them out on exit
(removing those removed). The QSettings docs give warnings about not writing
from two apps at once, so I think this change helps. There are still
potential corruption issues here - goodness why Qt can't do locking - maybe
this is fixed in Qt 4.
Without looking at the code, you don't actually need the dict because, by
default, QSettings will only call .sync() when the object is destroyed
but the internal state will be kept up to date. So if you remove sync()
from writeSetting and ensure it is called on shutdown (python makes no
promises that __del__ will ever be called...), it should have the same
effect.
OTOH I rather prefer the idea of writing as the app runs. Can we not
implement some form of manual locking?
I think I remember why I used my own code the first time around. I could
implement having settings which overrode master settings (in /etc). The new
code writes out all the settings to the user's dot file, and so you can't
later change the default setting in /etc if the user has run the program.
I can't see any way around this using QSettings (unless I manually read in
each file, if the system is unix). It's probably not that important as I
doubt sysadmins want to change default settings.
Presumably that's a problem facing all Qt applications. I don't think it
really matters.
