|Anonymous | Login||07-04-2020 06:53 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0003445||[Squeak] Tools||minor||always||04-08-06 06:22||10-18-06 14:00|
|Summary||0003445: In 3.9-7021 SMPackageLoader is initialized with a transparent gradient. This causes unexpected color changes.|
For this one from
a systemwindow comes up with the loader in it.
next grab something (say an ellipse) and move it over the title line.
drop and pick up the ellipse. A stamp of the ellipse is left on the title.
The package loader is initialized with a color gradient with a ramp from Color white to color transparent. (See mantis 0002296 )
So most of the ramp contains a translucent color. And that is absorbing colors from what goes over it.
Asking for the recolor halo handle sets the color back to a solid fill and removes the problem. Still the gradient fill should not be used.
I stumbled accross this in trying to used the packageloader. It is probably something other system window users do also. I have not yet tracked back to were the gradient is being set. (And what sigh preferences may be causing it. )
The gradient should be avoided for now or the underlying problem with transparent blending should be fixed. The latter is much harder that the former.
SMLoader-paneColor.st [^] (323 bytes) 09-26-06 02:57
SMLoader-paneColor.2.st [^] (518 bytes) 09-26-06 04:04
SMLoader-paneColor.3.st [^] (525 bytes) 09-26-06 04:49
PackageLoader-color-mantis3445.1.cs [^] (1,625 bytes) 10-17-06 03:50
(0007351 - 1812 - 2009 - 2009 - 2009 - 2009 - 2009)
SMLoader is a Subclass of SystemWindow instead of a model inside a system window. And therein lies the start of troubles.
The colors it register never get accessed because its model is nil.
In the process of opening SMLoader ,SystemWindow>>#paneColor tries to find a color.
when it encounters a nil model if asks for the color of the first pane.
This is a Pluggable text morph which dutifully returns color from the method Morph>>#color.
which says the color ivar is set from fillstyle asColor.
The PTM that is actually looked at does not have a fillstyle property so it returns self defaultColor.
In this case the default color is that of the morphic model and that is
So this bug comes under the catagory of too much delegation.
And too tricky a decision tree to be even followed easily.
The direction of the cure would be to set SMLoader up as a model ratther than a window. I don't right now know what that would entail.
And a rethink of system window and SMLoader probably. The code I looked at is ripe for simplification.
The other cure would be to overide paneColor in SMLoader to return a reasonable color if superPaneColor is transparent. ) or translucent.
The person who wrote this was not aware of the proper way to do it and tried to have the best of both worlds without understanding the language of System Windows. Quite frankly, I can see why. Unless the uses and expected protocalls for system window are documented for all to see things are just going to get messier as time goes on.
And all the "improvements of registries and such are giving the illusion of order but masking a lot of bugs with their added complexity. How do we simplify this???
All right analysis today, jam tomorrow.
Yours in service, --Jerome Peace
(0007376 - 1265 - 1407 - 1407 - 1407 - 1407 - 1407)
edited on: 09-26-06 04:55
SMLoader-paneColor.st . (simple fix but SMLoader must be initialize to get correct prefered color)
SMLoader-paneColor.2.st (oops forgott one minor detail) .
SMLoader-paneColor.3.st (That got it right. assures a nonWhite background color).
The simple fix short circuits the color search described above and solves the basic problem.
With this loaded the background basic color shows up solid.
If the class SMLoader is initialized then the background color is based on a yellow color.
For some reason when you get a fresh image the class initialzation is not run so the background color is based on Color white.
I wonder what is needed to prompt the class to initialize itself?
Anyway I copied the initialization logic into the 3rd version of the goodie.
That works and gets the background to the right color. The 2nd version had a mistake I fail to adjust copied code to work on the instance side. That was fixed on the third try.
[editorial comment: I always considered the panes in the windows what you looked thru and the borders between the panes something else. So I find the term "paneColor" to be misleading and confusing which is why I use background color as I describe it here.]
Yours in service, -- Jerome Peace
(0007585 - 1340 - 1418 - 1418 - 1418 - 1418 - 1418)
Tested on my OSX machine with a 7061 image; as a work around it is ok.
BUT the proper answer is surely to correct the improper subclassing.
I'm also reasonably sure that the image did not have the StandardToolSet class > initialize method run since the colour set for the package loader was 'white' which appears to be a signal that it was not setup. Running
seemed to fix that part of the problem.
The SystemWindow>paneColor method is just disgusting. It has magic numbers used for the display depth. It is so badly formatted that it disguises part of the functionality. It does magic things if the background colour is yellow or white! If the model is nil - or the model exists but is not in memory right now - it tries to use the colour of the first pane morph without any check for that being a sensible object.
Why that latter case? Why isn't using the default background colour enough in such a fallback case? Come to that, why is a pluggable text morph set to transparent?
What is supposed to happen if the Display depth is 1 - the fallback then os to use the default background colour and I see no methods that appear to do anything different for a monochrome display.
There are so many thing wrong here I can't even see a sensible replacement method I can propose without a lot of input.
(0007586 - 193 - 205 - 205 - 205 - 205 - 205)
Goran claims that the infelicity of inheritance in SMLoader has been fixed which should 'solve' the proximare problem.
However, that doesn't solve the problem of a crufty #paneColor method.
(0007596 - 821 - 911 - 911 - 911 - 911 - 911)
Thanks for noticing.
I was surprised by the amount of delegation I had to track down to figure out how #panecolor worked.
Squeak tends to accumulate clutter in an effort to add abilities and flexibilities. It seems to me an inevitable result of the distributed process of development and the difficulty of communication and coordination amoung developers. I18n will only make this more so.
The metafix starts with identifing the bad smells in the current code and making decisions from that knowledge of what to fix.
Squeak is overdue for a refactoring and repair pass. (And it may take several passes to catch up with all thats been taken in but not digested.)
Yours in service, --Jerome Peace
P.S. Goran I would love to see what you proposed for a fix posted to this report.
(0007677 - 181 - 187 - 187 - 187 - 187 - 187)
May be I should load the latest version of SM but I do not know where is it.
and now I want to stop fiddling with that system. We should really think about throw away a lot of junk
(0007679 - 591 - 625 - 625 - 625 - 625 - 625)
The latest version of SMLoader is in SqueakMap as "SqueakMap2 Loader" version 1.07. I loaded that version into Squeak 3.9 (7061) and the transparency problem has been fixed. (The SM Loader window is no longer transparent.)
So, this issue should be set to Resolved or Closed. The more general problem with transparent gradients behaving strangely should be tracked as a separate issue from this one (0002296, I guess). And the nastiness in #paneColor should probably be tracked separately too.
Also, SM2 Loader v1.07 should be included in the next batch of 3.9 (3.9.1?) updates. :-)
(0007680 - 282 - 294 - 294 - 294 - 294 - 294)
Double checked Dave's assertion about 1.07 of SMLoader fixing this and I concur. By setting the model it uses an approperiate paneColor methd and the colours are as expected.
I'd strongly recommend installing this version in the next possible build as an incremental improvement.
(0007681 - 68 - 68 - 68 - 68 - 68 - 68)
|I suggest that loading SMLoader 1.07 the problem is adequately fixed|
(0007693 - 331 - 379 - 379 - 379 - 379 - 379)
In 7064 the color for the package loader is no longer transparent.
It is white. This makes it look like a workspace pane.
It is supposed to be light yellow.
If you want it to be light yellow you can add the patch here to the one already made.
SMLoader-paneColor.3.st redefines #paneColor to always do the right thing.
(0007703 - 1367 - 1433 - 1433 - 1433 - 1433 - 1433)
No, SMLoader-paneColor.3.st is most definitely not the correct fix. Loading the SMLoader 1.07 fixes the problem with the incorrect model class.
Unfortunately the remaining problem is that the WindowColorRegistry simply doesn't have a colour specification for the model class. If we look into how this is set up we can see the problem:
- the registry is built by finding al lthe classes that implement #windowColorSpecification
- the #paneColor method ask the model for the #defaultBackgroundColor
- the model when we open a package loader is an SMSqueakMap.
- SMSqueakMap does not implement #windowColorSpecification
- therefore it devolves to the baseline default of white.
Even more unfortuately this involves the obscene #paneColor method. Since a not-found model produces a default color of white, this feeds into the awful code and results in a dull gray. Later code checks for the color being nil and would, if it were nil, eventually find the window default colour which is - ta-da! - correct for SMLoader, matching the value set in the window colour tool. But it never gets to find this out because of the nastiness of #paneColor.
The more correct workaround for now is to implement the #windowColorSpecification method in SMSqueakMap class and re-initialize the WindowColorRegistry class. See attached 'PackageLoader -color-mantis3445.1.cs'
(0007718 - 483 - 543 - 543 - 543 - 543 - 543)
edited on: 10-18-06 00:50
You are now the one looking at this most carefully. So I am happy to defer to your insight and wisdom.
I did look at your fix code and I notice that it relies on mostly doit's. So while it works as a changeset squeak is no longer updating with update streams. How does this work when it is incorperated in an MC package?
I loaded the cs into 7064 and the color is still a gray rather than a yellow.
Does this mean 7064 is based on some package before 1.07?
(0007719 - 303 - 315 - 315 - 315 - 315 - 315)
A fair question and one that I don't know an answer to.
In this particular case the doit in question is merely to run the WindowColorRegistry class initialize, so MC could be satisfied by simply touching the meothd so as to casue it to be include and run as part of loading. I think. Maybe. Perhaps.
(0007720 - 94 - 94 - 94 - 94 - 94 - 94)
|I believe the attached changeset solves the problem reasonably. See last comment wrt MC issue.|
(0007724 - 6 - 6 - 6 - 6 - 6 - 6)
(0007725 - 70 - 70 - 70 - 70 - 70 - 70)
|in RC2 may be we should have a look at the paneColor refactoring after|
|04-08-06 06:22||wiz||New Issue|
|09-25-06 07:48||wiz||Note Added: 0007351|
|09-26-06 02:57||wiz||File Added: SMLoader-paneColor.st|
|09-26-06 04:03||wiz||Note Added: 0007376|
|09-26-06 04:04||wiz||File Added: SMLoader-paneColor.2.st|
|09-26-06 04:49||wiz||File Added: SMLoader-paneColor.3.st|
|09-26-06 04:55||wiz||Note Edited: 0007376|
|10-05-06 09:07||tim||Note Added: 0007585|
|10-05-06 09:16||tim||Note Added: 0007586|
|10-05-06 09:16||tim||Status||new => assigned|
|10-05-06 09:16||tim||Assigned To||=> tim|
|10-06-06 05:19||wiz||Note Added: 0007596|
|10-14-06 13:33||ducasse||Note Added: 0007677|
|10-15-06 06:35||dway||Note Added: 0007679|
|10-15-06 08:25||tim||Relationship added||related to 0002296|
|10-15-06 08:28||tim||Summary||In 7021 SMPackageLoader is initialized with a transparent gradient. This causes unexpected color changes. => In 3.9-7021 SMPackageLoader is initialized with a transparent gradient. This causes unexpected color changes.|
|10-15-06 08:29||tim||Relationship added||related to 0005243|
|10-15-06 08:52||tim||Note Added: 0007680|
|10-15-06 08:53||tim||Status||assigned => resolved|
|10-15-06 08:53||tim||Fixed in Version||=> 3.9|
|10-15-06 08:53||tim||Resolution||open => fixed|
|10-15-06 08:53||tim||Note Added: 0007681|
|10-16-06 07:19||wiz||Status||resolved => feedback|
|10-16-06 07:19||wiz||Resolution||fixed => reopened|
|10-16-06 07:19||wiz||Note Added: 0007693|
|10-17-06 03:49||tim||Note Added: 0007703|
|10-17-06 03:50||tim||File Added: PackageLoader-color-mantis3445.1.cs|
|10-18-06 00:44||wiz||Note Added: 0007718|
|10-18-06 00:50||wiz||Note Edited: 0007718|
|10-18-06 09:19||tim||Note Added: 0007719|
|10-18-06 09:20||tim||Status||feedback => resolved|
|10-18-06 09:20||tim||Resolution||reopened => fixed|
|10-18-06 09:20||tim||Note Added: 0007720|
|10-18-06 14:00||ducasse||Status||resolved => closed|
|10-18-06 14:00||ducasse||Note Added: 0007724|
|10-18-06 14:00||ducasse||Note Added: 0007725|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
129 total queries executed.|
69 unique queries executed.