Re: [lmi] User preferences in monthly end-user packages

[Greg Chicares]

On 2010-03-22 14:02Z, Murphy, Kimberly wrote:
> Currently end-user packages include all skins, regardless of 
> the default 'skin_filename'. During the install of the monthly 
> distribution, an existing user's 'configurable_settings' is not 
> overlaid as they may have personalized their file. For this 
> reason, the interfaces are renamed from 'skin_*.xrc' to 
> 'xml_notebook_*.xrc' before packaging. 
> 
> The 'configurable_settings' file can be modified to use the new 
> file names. However, copies of the new files under the old names 
> (xml_notebook*) would need to remain in the distribution since 
> we don't overlay any existing files. Is there a way to alter this 
> one preference while preserving the user's other preferences?

Yes, and I think it'd be best to use the technique recently abstracted
into 'xml_serializable.?pp'--here's a sketch of the main idea:

configurable_settings::redintegrate_ex_post()
{
    if(class_version() == file_version)
        {
        return;
        }

    if(0 == file_version) // Or if it had no explicit version...
        {
        // Old and new names are in ChangeLog for 20080218T1743Z
        if skin_filename() is an old name
            then change it to the new name
            and rename the old file accordingly
        }
}

I'm trying to do the same thing right now for product files, which I'm
eager to finish first, so I can't undertake 'configurable_settings.?pp'
myself right now. But if anyone else wants to, I'll integrate a patch
quickly because it's closely related to what I'm working on; and it'd
probably be a good idea to get a critique of 'xml_serializable.?pp'
anyway. For example, this redintegration might be handled ex ante rather
than ex post; it's pretty clear which to use for mc_enum types in class
Input, but for string types we should devise and document a strategy
that can be applied consistently. (redintegrate_ad_terminum() might also
work, but I added that for kludges that couldn't fit anywhere else; and
if an "old" name is encountered in a file version that should only have
"new" names, then I'd prefer *not* to fix that up silently.)

The more I ponder it, the more I think this actually is an "ex ante"
situation, because the old and new names really are enumerative. They
correspond to file names in svn; thus, perhaps 'skin_filename_' should be
of some new mc_enum type. That would mean that 'my_experimental_skin.xrc'
would be forbidden, which I think is okay. But I have to stop pondering
this myself and get back to product files....