[sword-devel] CipherKey preservation on update

[Troy A. Griffitts]

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 <karl at kleinpaste.org 
>> <mailto:karl at 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 at crosswire.org 
>> <mailto:sword-devel at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20141217/c69bcc80/attachment-0001.html>