Well, I agree with the "let's not hack it" part.

It's not a ReleaseBuilder issue or problem though. The release process
does set the background, but the problem here is that some random (*)
change in code triggers a... regrettable change in my image. Updating
the image is a distinct process from creating a release. I've always
treated the update process as having a "thou shalt not monkey around
with the updater's settings" principle. This changing of background
violates that principle. It's not in a serious way - my background
disappears - but other updates _could_ do potentially bad things,
because a class' #initialize tries to format my hard disk or something

I guess I'm saying that a code change shouldn't result in a state change?

frank

(*) no disrespect intended!

On 11 September 2013 19:16, Chris Muller <asqueaker at gmail.com> wrote:
> No, let's not hack around it like that.  I think setting the
> background should be part of ReleaseBuilder process, not loading
> Morphic.
>
> On Wed, Sep 11, 2013 at 1:14 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> Right, so that'll be any MorphicProject update, so Morphic-dtl.668
>> would cause it.
>>
>> Sigh. That kind've means that someone wanting to be kind would need to
>> specifically preserve the background through a preamble/postscript
>> pair, wouldn't it?
>>
>> frank
>>
>> On 11 September 2013 19:09, Bob Arning <arning315 at comcast.net> wrote:
>>> PasteUpMorph(Morph)>>color:
>>> MorphicProject class>>initialize
>>> MCMethodDefinition>>postload
>>> MCMethodDefinition(MCDefinition)>>postloadOver:
>>> [] in [] in [] in [] in MCPackageLoader>>basicLoad
>>>
>>> Cheers,
>>> Bob
>>>
>>> On 9/11/13 1:35 PM, Frank Shearar wrote:
>>>
>>> I just updated an image from 12641, and the blurry Ulam Spiral
>>> background disappeared, replaced by the old brushed metal background.
>>> What did that? Why?
>>>
>>> frank
>>>
>>>
>>>
>>>
>>>
>>>
>>
>