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 |
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. |
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 |
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 > > > > > > |
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 |
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 >> >> >> >> >> >> > |
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 >>> >>> >>> >>> >>> >>> >> > |
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 |
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 > > > > > > > > > > > |
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 |
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 |
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 |
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 |
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:
|
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
|
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 >> >> >> > > > > |
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 > |
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 http://www.preeminent.org/squeak/index.html +1 Edgar |
In reply to this post by Chris Muller-3
On Thu, Sep 12, 2013 at 4:13 AM, Chris Muller <[hidden email]> wrote:
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
> > 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 >> >> >> > > > > |
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 >>> >>> >>> >> >> >> >> > > > > > |
Free forum by Nabble | Edit this page |