Smalltalk › Squeak › Squeak - Dev

Something in the update process damages the background

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

38 messages Options

Frank Shearar-3

Something in the update process damages the background

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

timrowledge

Re: Something in the update process damages the background

On 11-09-2013, at 10:35 AM, Frank Shearar <[hidden email]> 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?

I noticed that too. Presumably an update made the change explicitly. What did mildly annoy me was that loading my preferences (mostly things like swapping back to proper mouse button use instead of the completely improper right-button-is-middle-button nonsense and getting scrollbars on the left as they should be) actually reset the background. It would be nice if only deliberate change caused the new choice to be written out; no idea where the code is that does that right now.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
APATHY ERROR: Don't bother striking any key.

Bob Arning-2

Re: Something in the update process damages the background

In reply to this post by Frank Shearar-3

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

Frank Shearar-3

Re: Something in the update process damages the background

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 <[hidden email]> 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
>
>
>
>
>
>

Bob Arning-2

Re: Something in the update process damages the background

In reply to this post by Frank Shearar-3

loading

Morphic-dtl.668

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

Chris Muller-3

Re: Something in the update process damages the background

In reply to this post by Frank Shearar-3

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 <[hidden email]> 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 <[hidden email]> 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
>>
>>
>>
>>
>>
>>
>

Frank Shearar-3

Re: Something in the update process damages the background

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Bob Arning-2

Re: Something in the update process damages the background

In reply to this post by Frank Shearar-3

The problem is that MorphicProject class>>initialize was modified and when that happens, it is automatically run after loading. This method does:

    Project current isMorphic ifTrue:[
        "Set the default background in the current world"
        Project current world color: self defaultFill.
    ].

and that's where it happened. My guess is you just want to eliminate that code.

Cheers,
Bob

On 9/11/13 2:14 PM, Frank Shearar 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 [hidden email] 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

Frank Shearar-3

Re: Something in the update process damages the background

Yes, that's exactly the diagnosis that I'd reached.

I don't know that I want to eliminate that code, particularly. I just
want to not have my nice background disappear because MorphicProject
>> #initialize changed. I'm stating the user story, if you like,
without suggesting a particular solution (because I know very little
about this code).

frank

On 11 September 2013 19:31, Bob Arning <[hidden email]> wrote:

> The problem is that MorphicProject class>>initialize was modified and when
> that happens, it is automatically run after loading. This method does:
>
> Project current isMorphic ifTrue:[
> "Set the default background in the current world"
> Project current world color: self defaultFill.
> ].
>
> and that's where it happened. My guess is you just want to eliminate that
> code.
>
> Cheers,
> Bob
>
>
> On 9/11/13 2:14 PM, Frank Shearar 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 <[hidden email]> 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
>
>
>
>
>
>
>
>
>
>
>

Bob Arning-2

Re: Something in the update process damages the background

Well, since the whole point of this snippet is to change your project's background, I'd say you simply want to delete it. Then you can rely on whatever you do in release building to set the background for the standard image and everybody else keeps their background as-is.

Cheers,
Bob

On 9/11/13 2:38 PM, Frank Shearar wrote:

Yes, that's exactly the diagnosis that I'd reached.

I don't know that I want to eliminate that code, particularly. I just
want to not have my nice background disappear because MorphicProject

#initialize changed. I'm stating the user story, if you like,

without suggesting a particular solution (because I know very little
about this code).

frank

On 11 September 2013 19:31, Bob Arning [hidden email] wrote:

The problem is that MorphicProject class>>initialize was modified and when
that happens, it is automatically run after loading. This method does:

    Project current isMorphic ifTrue:[
        "Set the default background in the current world"
        Project current world color: self defaultFill.
    ].

and that's where it happened. My guess is you just want to eliminate that
code.

Cheers,
Bob


On 9/11/13 2:14 PM, Frank Shearar 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 [hidden email] 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

timrowledge

Re: Something in the update process damages the background

On 11-09-2013, at 11:58 AM, Bob Arning <[hidden email]> wrote:

> Well, since the whole point of this snippet is to change your project's background, I'd say you simply want to delete it. Then you can rely on whatever you do in release building to set the background for the standard image and everybody else keeps their background as-is.

It seems to me that the pattern ought to be along the lines of
if user has set a specific preference, leave things alone
if not, reset the default
if that requires a redisplay/explosion/descent-down-the-rabbit-hole, do it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DNPG: Do Not Pass Go

Edgar De Cleene

Re: Something in the update process damages the background

In reply to this post by Chris Muller-3

El 9/11/13 3:16 PM, "Chris Muller" <[hidden email]> escribió:

>No, let's not hack around it like that. I think setting the
>background should be part of ReleaseBuilder process, not loading
>Morphic.
>
>+1
We have this in 3.10 and was

createBackgroundColor
|gf |
gf := GradientFillStyle ramp: {0.0->(Color r: 0.97 g: 0.98 b: 1.0) .
1.0->(Color r: 0.0 g: 0.658 b: 0.474)}.
gf origin: 0 @ 0;
direction: 0@400;
normal: 640@0;
radial: false.
World fillStyle: gf.

Edgar

Bob Arning-2

Re: Something in the update process damages the background

In reply to this post by timrowledge

One problem here is that there are at least kinds of things in #initialize methods:

- things that must be set/reset for the system to work, like a new class var or an old one with new meaning
- things that the user might like to reset to get back to some pristine starting point

This update contained one example of the former:
"update the uiProcess instance variable in all Morphic projects"
self allSubInstances do: [:p | p uiProcess].

mingled in with various examples of the latter and all got done together. It has been convenient to rely on the auto-running of a changed class initialization method to accomplish necessary state changes, but, as we see, that includes unpleasant side-effects. If you want the class #initialize method to be the place the user goes for a clean reset, then the solution might be to

- disable auto-running class #initialize methods simply because they changed
- add a new class method #autoInitialize which *will* be run if changed
- make your changes solely to #initialize if it's simply something to be available if the user ever needs it
- add your code to both methods if you want it to run as soon as it's loaded and be available for later
- whenever you update #autoInitialize, remove older stuff that does not need to be run a second time

Cheers,
Bob

On 9/11/13 3:04 PM, tim Rowledge wrote:

On 11-09-2013, at 11:58 AM, Bob Arning [hidden email] wrote:

Well, since the whole point of this snippet is to change your project's background, I'd say you simply want to delete it. Then you can rely on whatever you do in release building to set the background for the standard image and everybody else keeps their background as-is.

It seems to me that the pattern ought to be along the lines of
if user has set a specific preference, leave things alone
if not, reset the default 
if that requires a redisplay/explosion/descent-down-the-rabbit-hole, do it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DNPG: Do Not Pass Go

Karl Ramberg

Re: Something in the update process damages the background

In reply to this post by timrowledge

I agree with this. Look for a user set background, if nil do default fill,

Karl

On Wed, Sep 11, 2013 at 9:04 PM, tim Rowledge <[hidden email]> wrote:

On 11-09-2013, at 11:58 AM, Bob Arning <[hidden email]> wrote:

> Well, since the whole point of this snippet is to change your project's background, I'd say you simply want to delete it. Then you can rely on whatever you do in release building to set the background for the standard image and everybody else keeps their background as-is.

It seems to me that the pattern ought to be along the lines of
if user has set a specific preference, leave things alone
if not, reset the default
if that requires a redisplay/explosion/descent-down-the-rabbit-hole, do it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim

Strange OpCodes: DNPG: Do Not Pass Go

tty

Re: Something in the update process damages the background

In reply to this post by Bob Arning-2

Not directly addressing the release issue, but Steve Wessel's Desktop Backtground Loader could be a nice addition to any release, then put in the default workspaces on a new release a blurb explaining how to use it.

http://www.preeminent.org/squeak/index.html

t

---- On Wed, 11 Sep 2013 11:58:14 -0700 Bob Arning<[hidden email]> wrote ----

On 9/11/13 2:38 PM, Frank Shearar wrote:

[hidden email]" type="cite">

Yes, that's exactly the diagnosis that I'd reached. I don't know that I want to eliminate that code, particularly. I just want to not have my nice background disappear because MorphicProject

#initialize changed. I'm stating the user story, if you like,

without suggesting a particular solution (because I know very little about this code). frank On 11 September 2013 19:31, Bob Arning [hidden email] wrote:

The problem is that MorphicProject class>>initialize was modified and when that happens, it is automatically run after loading. This method does:     Project current isMorphic ifTrue:[         "Set the default background in the current world"         Project current world color: self defaultFill.     ]. and that's where it happened. My guess is you just want to eliminate that code. Cheers, Bob On 9/11/13 2:14 PM, Frank Shearar 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 [hidden email] 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

Chris Muller-3

Re: Something in the update process damages the background

In reply to this post by Karl Ramberg

On Wed, Sep 11, 2013 at 2:52 PM, karl ramberg <[hidden email]> wrote:
> I agree with this. Look for a user set background, if nil do default fill,

I don't understand your proposal. The background just _is_ whatever
it is. We set it during the release process. When someone downloads
a release image, they either "set the background" to a color,
gradient, pattern, or bitmap of their choice or, they don't. How are
you going to "look for a user set background?" When would such a
thing be done? Upon loading Morphic? Why? Why not just leave it as
is?

>
> Karl
>
>
>
> On Wed, Sep 11, 2013 at 9:04 PM, tim Rowledge <[hidden email]> wrote:
>>
>>
>> On 11-09-2013, at 11:58 AM, Bob Arning <[hidden email]> wrote:
>>
>> > Well, since the whole point of this snippet is to change your project's
>> > background, I'd say you simply want to delete it. Then you can rely on
>> > whatever you do in release building to set the background for the standard
>> > image and everybody else keeps their background as-is.
>>
>> It seems to me that the pattern ought to be along the lines of
>> if user has set a specific preference, leave things alone
>> if not, reset the default
>> if that requires a redisplay/explosion/descent-down-the-rabbit-hole, do
>> it.
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Strange OpCodes: DNPG: Do Not Pass Go
>>
>>
>>
>
>
>
>

Tobias Pape

Re: Something in the update process damages the background

Am 12.09.2013 um 04:13 schrieb Chris Muller <[hidden email]>:

> On Wed, Sep 11, 2013 at 2:52 PM, karl ramberg <[hidden email]> wrote:
>> I agree with this. Look for a user set background, if nil do default fill,
>
> I don't understand your proposal. The background just _is_ whatever
> it is. We set it during the release process. When someone downloads
> a release image, they either "set the background" to a color,
> gradient, pattern, or bitmap of their choice or, they don't. How are
> you going to "look for a user set background?" When would such a
> thing be done? Upon loading Morphic? Why? Why not just leave it as
> is?

Long story short, background setting does not belong into
MorphicProject»initialize but ReleaseBuilder»makeMeANiceBackground
…

>
>>
>> Karl
>>
>>
>>
>> On Wed, Sep 11, 2013 at 9:04 PM, tim Rowledge <[hidden email]> wrote:
>>>
>>>
>>> On 11-09-2013, at 11:58 AM, Bob Arning <[hidden email]> wrote:
>>>
>>>> Well, since the whole point of this snippet is to change your project's
>>>> background, I'd say you simply want to delete it. Then you can rely on
>>>> whatever you do in release building to set the background for the standard
>>>> image and everybody else keeps their background as-is.
>>>
>>> It seems to me that the pattern ought to be along the lines of
>>> if user has set a specific preference, leave things alone
>>> if not, reset the default
>>> if that requires a redisplay/explosion/descent-down-the-rabbit-hole, do
>>> it.
>>>
>>> tim
>>> --
>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>> Strange OpCodes: DNPG: Do Not Pass Go
>

Edgar De Cleene

Re: Something in the update process damages the background

In reply to this post by tty

De: gettimothy <[hidden email]>
Responder a: The general-purpose Squeak developers list <[hidden email]>
Fecha: Wed, 11 Sep 2013 14:35:08 -0700
Para: The general-purpose Squeak developers list <[hidden email]>
Asunto: Re: [squeak-dev] Something in the update process damages the background

Edgar

Karl Ramberg

Re: Something in the update process damages the background

In reply to this post by Chris Muller-3

On Thu, Sep 12, 2013 at 4:13 AM, Chris Muller <[hidden email]> wrote:

On Wed, Sep 11, 2013 at 2:52 PM, karl ramberg <[hidden email]> wrote:
> I agree with this. Look for a user set background, if nil do default fill,

I don't understand your proposal. The background just _is_ whatever
it is. We set it during the release process. When someone downloads
a release image, they either "set the background" to a color,
gradient, pattern, or bitmap of their choice or, they don't. How are
you going to "look for a user set background?" When would such a
thing be done? Upon loading Morphic? Why? Why not just leave it as
is ?

I'm not able to check right now but isn't the background held in a instance variable ?

If the current background instance is lost or corrupt, the defaultBackground should be used.

It would be nice to have all setting like this as part of a theme setting one could file out and import into other images.

I don't think this should be a ReleaseBuilder setting.

Karl

Frank Shearar-3

Re: Something in the update process damages the background

On 12 September 2013 11:31, karl ramberg <[hidden email]> wrote:

>
>
> On Thu, Sep 12, 2013 at 4:13 AM, Chris Muller <[hidden email]> wrote:
>>
>> On Wed, Sep 11, 2013 at 2:52 PM, karl ramberg <[hidden email]>
>> wrote:
>> > I agree with this. Look for a user set background, if nil do default
>> > fill,
>>
>> I don't understand your proposal. The background just _is_ whatever
>> it is. We set it during the release process. When someone downloads
>> a release image, they either "set the background" to a color,
>> gradient, pattern, or bitmap of their choice or, they don't. How are
>> you going to "look for a user set background?" When would such a
>> thing be done? Upon loading Morphic? Why? Why not just leave it as
>> is ?
>
>
> I'm not able to check right now but isn't the background held in a instance
> variable ?
> If the current background instance is lost or corrupt, the defaultBackground
> should be used.

It is held in an instvar (Project's 'color' (!) instvar), and the
problem is that the #defaultBackground is unilaterally used.
(MorphicProject defaultBackground contains a base64-encoded image in a
string.)

I put a possible fix in the Inbox (Morphic-fbs.682).

frank

> It would be nice to have all setting like this as part of a theme setting
> one could file out and import into other images.
> I don't think this should be a ReleaseBuilder setting.
>
> Karl
>
>>
>> Karl
>>
>>
>>
>> On Wed, Sep 11, 2013 at 9:04 PM, tim Rowledge <[hidden email]> wrote:
>>>
>>>
>>> On 11-09-2013, at 11:58 AM, Bob Arning <[hidden email]> wrote:
>>>
>>> > Well, since the whole point of this snippet is to change your project's
>>> > background, I'd say you simply want to delete it. Then you can rely on
>>> > whatever you do in release building to set the background for the
>>> > standard
>>> > image and everybody else keeps their background as-is.
>>>
>>> It seems to me that the pattern ought to be along the lines of
>>> if user has set a specific preference, leave things alone
>>> if not, reset the default
>>> if that requires a redisplay/explosion/descent-down-the-rabbit-hole, do
>>> it.
>>>
>>> tim
>>> --
>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>> Strange OpCodes: DNPG: Do Not Pass Go
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
>