Phillip J. Eby wrote:
The reason for #2 is to support upgrading; when a new version of a
parcel is loaded, all the values set in installParcel() will override
any existing values, thus wiping out the preferences. And, since
initialValue settings are only applied when an item is created, an
upgrade that adds new preferences will find the preference data
missing from the preferences item.
+1 to this idea, I think I must have glossed over that in your last post.
(This is actually how we did it in mozilla as well - the default value
was stored internally as a part of the app, and only used as backing for
when the user's preference wasn't already set - that's why some
preferences are bold in about:config - those are the ones that have a
'local' or user-set value)
Alec
By contrast, a preference attribute's 'defaultValue' will always be
seen if no value has been specifically assigned to the attribute.
This also means that when an upgrade occurs, we can change the default
setting for a preference, and it will apply as long as the user has
never changed the original setting. For example, if we have a "theme"
preference, and the user never changes it, then when we change the
default theme in an upgrade, the new default theme will automatically
be selected.
Anyway, this is probably more detailed than what you wanted to get
into right now, but I thought I should mention it for future
reference. That is, we need to include consideration of what happens
to preferences during upgrading, even if we decide on a different
policy than what I'm describing here.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
