looks like it was known at the time

[squeak-dev] Re: raised & inset borders

Levente Uzonyi leves at caesar.elte.hu 
Thu Nov 3 22:22:26 UTC 2016 
Hi Hans-Martin,

My intention was to always initialize baseColor, because nil was used as a 
substitute of Color transparent back and forth for seemingly no reason.
I must have overlooked those #trackColorFrom: methods, and I think 
replacing ifNil: with isTransparent ifTrue: in them is the right fix.
If you have a better solution in mind, let me know. Or I'll push the above 
fix this week to the Trunk.

Levente

On Tue, 1 Nov 2016, Hans-Martin Mosner wrote:

> Looks like there is a regression with raised and inset borders. The method #initialize in SimpleBorder sets baseColor to
> "Color transparent", which prevents #trackColorFrom: in its subclasses to work correctly.
>
> Since it is unclear to me whether it would have unintended side effects if the initialization of baseColor was removed,
> I've added a check for transparent baseColor in all three trackColorFrom: methods, but that looks a bit ugly.
>
> Levente, the method is from April 2016 and carries your initials - do you remember what the motivation for this change was?
>
>
> Cheers,
>
> Hans-Martin
>
>
>
More information about the Squeak-dev mailing list


On 4/23/18 3:50 AM, Marcel Taeumel wrote:
Oh, hmmm... Well, what was the intention behind the change? I can see the stamp:

ul 11/2/2016 09:46

Best,
Marcel

Am 20.04.2018 15:05:24 schrieb Bob Arning <arning315@comcast.net>:

it used to be that baseColor would be nil and

RaisedBorder>>trackColorFrom: aMorph
    baseColor ifNil:[self color: aMorph raisedColor].

would set the appropriate color, but now baseColor is set to Color transparent in the #initialize method and setting the raised color never happens.

On 4/20/18 8:25 AM, David T. Lewis wrote:
Thanks, I see it now.

The problem is also present in my "V3 trunk image", exactly as in the
trunk image. So it is not related to any differences in the coversion
to Spur in Squeak 5. It must be some other problem that was introduced
between Squeak 4.5 and 5.1.

I checked Squeak5.0-15113, and the problem is not happening there.

So ... it looks like something that was introduced between 5.0 and 5.1.

Dave


On Fri, Apr 20, 2018 at 06:59:49AM +0200, karl ramberg wrote:

Hi,
This should show a thick border on the morph, with a simple raised
"ilusion".
Should be same border width as second rectangle with a red border.

RectangleMorph new borderColor: #raised; borderWidth: 10; openInWorld
RectangleMorph new borderColor: Color red; borderWidth: 10; openInWorld

Best,
Karl


On Fri, Apr 20, 2018 at 2:57 AM, David T. Lewis <lewis@mail.msen.com> wrote:


Hi Karl,

Can you explain how I can see the problem with #raised and #inset borders?
I have a trunk level V3 image for comparison, so I can check if it might be
something related to the image conversion.

Dave


On Thu, Apr 19, 2018 at 10:04:32PM +0200, karl ramberg wrote:

Hm,
Actually broken in 5.0
Image conversion issue ??
Best,
Karl

On Thu, Apr 19, 2018 at 9:56 PM, karl ramberg <karlramberg@gmail.com>

wrote:

Well,
These border styles have been broken for some time.
I checked some old images and it worked in the 4.6 image but not in

5.1 so

something changed between there :-)

Best,
Karl

On Thu, Apr 19, 2018 at 11:44 AM, Marcel Taeumel <

marcel.taeumel@hpi.de>

wrote:


Well, they kind of work if you set the #baseColor in the respective
border style. Otherwise, yes, I noticed that, too. At least the Mines

game

draws the fields on its own. So, there might be a bug hidden in

drawing

those border styles.

Best,
Marcel

Am 18.04.2018 20:31:31 schrieb karl ramberg <karlramberg@gmail.com>:
Hi,

#inset and #raised does not work either with or without Marcels

changeset.

Best,
Karl


On Tue, Apr 17, 2018 at 6:50 PM, karl ramberg <karlramberg@gmail.com>
wrote:


Hi,
Slightly off topic:
I have been looking at border stuff in latest Trunk image and I can't
get border #inset and #raised to work.

The complex borders work.

Best,
Karl


On Sun, Apr 15, 2018 at 9:34 AM, Marcel Taeumel <

marcel.taeumel@hpi.de>

wrote:


Thanks Karl and Dave. Chris, does it work in your image(s)?

Best,
Marcel

Am 14.04.2018 21:00:55 schrieb David T. Lewis <lewis@mail.msen.com

:

On Thu, Apr 12, 2018 at 11:23:42PM -0700, marcel.taeumel wrote:

Anybody? Just file it in your work image and tell me what happens.


Sorry I overlook this. I filed the changes in earlier today. All is
well with browsers and such, but when I open an Elipse from the

Objects

tab, then rotate it with the halo handle, things go wrong. It looks
like the 'closed' instance variable in the PolygonMorph is nil.

I think you may have already addressed this from Karl's report.

Dave