[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Greg Chicares
Subject: Re: [lmi] User preferences in monthly end-user packages
Date: Mon, 22 Mar 2010 15:11:25 +0000
User-agent: Thunderbird (Windows/20090812)

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:

    if(class_version() == file_version)

    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....

reply via email to

[Prev in Thread] Current Thread [Next in Thread]