Yes, BibleCS uses this mechanism.
Any configuration information it wishes to store about a module,
recognized by SWORD or not, or anything it wishes to override in a
module (e.g., Font, CipherKey) are stored in a one file: userprefs.conf
In our subclass of SWMgr, we override the virtual Load (sorry for not
camelCase; SWMgr hasn't gone through the standardization process yet):
signed char BibleCSMGR::Load() {
signed char retval = SWMgr::Load();
userPrefs = new
SWConfig(TForm1::getDataRootPath()+"/BibleCS/userprefs.conf");
config->augment(*userPrefs);
}
This is the line which does the trick:
config->augment(*userPrefs);
SWMgr::config is SWMgr's loaded and compiled SWConfig object of all modules.
SWConfig::augment(...) augments all config settings that are also
present in userPrefs. Values present in config which are also present in
userPrefs will be overridden with the values from userPrefs; all
settings which are not yet present in config are copied to config from
userPrefs.
On 12/17/2014 09:38 AM, DM Smith wrote:
One of the things that we’ve tossed about for a while is keeping the
conf of the module pristine and storing the cipher key in another
file. That other file would hold all the frontend edits for the confs.
It would have the form:
[NASB]
CipherKey=asdf
[KJV]
Font=yadayadayada
…
I was going to roll my own in JSword, but Troy said that this
mechanism already exists in SWORD. It would be nice to standardize the
location and naming of such.
— DM
On Dec 17, 2014, at 9:45 AM, Karl Kleinpaste <k...@kleinpaste.org
<mailto:k...@kleinpaste.org>> wrote:
A suggestion for all apps: When updating a locked module, keep/re-use
the old CipherKey.
This was a suggestion from Greg during rapid updates in his NASB
testing cycle. Having to re-paste or re-type the key is a pain and
should be unnecessary. If the user has had the module a long time,
he may no longer have the key otherwise. Generally speaking, I think
we can expect that a module's updates will continue to have the same key.
I did this for Xiphos, and then forwarded the thought to Nic who has
already added it to PS as well. It seems to me that this is a good
universal behavior for Sword apps.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
<mailto:sword-devel@crosswire.org>
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
