0007276: shadowForm computes bounds inconsistantly. - Mantis

Mantis Bugtracker

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

ID

Category

Severity

Reproducibility

Date Submitted

Last Update

0007276

[Squeak] Morphic

minor

always

02-02-09 21:54

02-04-09 05:33

Reporter

wiz

View Status

public

Assigned To

Priority

normal

Resolution

open

Status

new

Product Version

Summary

0007276: shadowForm computes bounds inconsistantly.

Description

See 0003333 for earlier battles with this problem.
The problem symptoms are most notable when a
morph has a rollover border (e.g. when a mouse up action has been added.)
To see the symptoms:

From the object bin get two morphs (I used a star and an ellipse.)

Have the star show its handles.
Embed the ellipse in the star.
Get the halo handles over the ellipse.
Using the halos on the star choose the red menu.
From the menu select >extras...>add mouse up action.
in the fillin blank type:

self shadowForm asMorph openInHand

Pressing on the star or its ellipse will put a shadowForm of the morph
in your hand.

Use the brown handle to move the ellipse around in its owner.
Try moving it as far left as possible.
Then as far right.
The far right will produce the shadow you expect.
The far left will produce a shadow w/o most of the ellipse.

The rollover border for the star will allow you to see the effects on the
shadowForm bug magnified into a off center rollover.

Additional Information

I think I have found three bugs here and counting.

The current shadowForm has the problem of using the
owners bounds to determine topLeft.
But it uses the full bounds to determine extent.
This clips the shadows of submorphs to the left of their owner.

Submorophs will often show up above or left of the owning morph.
So this lead to the shadowForm ignoring some submorphs.
Using the fullBounds consistently cures this.

Fixing this still does not solve the rollover shadow problem.
To center the rollover shadow the centers of the fullbounds and
the center of the rollover wish to be aligned.

even that is not a sufficient cure.

outerBounds get calculated strangely.

'ar 11/12/2000 22:06 Morph outerBounds {geometry}'

    "Return the 'outer' bounds of the receiver, e.g., the bounds that need to be invalidated when the receiver changes."
    | box |
    box _ self bounds.
    self hasDropShadow ifTrue: [box _ self expandFullBoundsForDropShadow: box].
    self hasRolloverBorder ifTrue:[box _ self expandFullBoundsForRolloverBorder: box].
    ^box

please note the assignment of bounds to box at the start of the method. This wants to be fullbounds but using that would cause infinte recursion. Or something similar I couldn't really find out after I tried it. I had to quit the image.

    So it misleads by allowing you to think it is expanding fullBounds when it is not.
    ----======----

To find out the clipping area for the rollover it
relies on the owners bounds (not fullbounds).
Unfortunately calculating fullbounds within the outerBounds method
will crash (via infinite loop I believe) the system. At least when I patched
it that way I had to quit and restart squeak.
It was possible to use fullbounds when the value has already been calculated. (i.e. fullbounds ifNil: [ self bounds ] ) carefully avoiding the recursion. With that patch in place and the other two repairs the roll over shadow would show up in its proper place.

Unfortunately this pointed to another bug. When the mouse rolled off the button The outer part of the rollover shadow would remain. The invalid rectangle was not being set large enough to erase it.

This represents the and counting part of the report.
The code review shows that 'self changes' is called before and after
most of the drawing events. Somehow this timing is not sufficient to get the change. I'm thinking that there are several timing problems with layout policies in general and I am probably seeing the tip of another problem.

Morph-shadowForm.st [^] (655 bytes) 02-02-09 21:54

Relationships

parent of	0003333	closed		SimpleButtonMorph bug
child of	0006511	new		Mother of all Morphic Graphical off-by-one/fencepost -error reports.

Notes
(0012942 - 1074 - 1212 - 1212 - 1284 - 1284 - 1284) wiz 02-04-09 05:33	Historical notes. Earlier versions of shadowForm used self bounds rather than self fullbounds to get the extent.. Then it was patched by JW to calulate extent according to fullbounds. I think when I first came across this in 0003333 I pointed that out and suggested a reversion. Strangely we now have a method stamp 'ar' but with the same JW patches. The original behavior would clip any submorphs at the owning morphs boundry. So what is the user think? What user story needs to be implemented here? I am also beginning to realize that for a drop shadow the shape of the shadow means less to the user than that there is one. I.E. all that is needed is some visual indication that the morph has been grabbed by the hand. The same is true to a lesser extent with rollover shadows. Not having a symmetrically concentric rollover is disappointing. Leaving large gribbles on the screen is also unappealing. The question is what is the user story on the shadows? What is acceptable and what isn't? Yours in curiosity and service, --Jerome Peace

Issue History
Date Modified	Username	Field	Change
02-02-09 21:54	wiz	New Issue
02-02-09 21:54	wiz	File Added: Morph-shadowForm.st
02-02-09 22:02	wiz	Relationship added	parent of 0003333
02-02-09 22:04	wiz	Relationship added	child of 0006511
02-04-09 05:33	wiz	Note Added: 0012942

Mantis 1.0.8[^]

Copyright © 2000 - 2007 Mantis Group

42 total queries executed.
30 unique queries executed.