| Anonymous | Login | 01-20-2021 10:34 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 | |||||||
| 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. |
|||||||||||
| Attached Files |
 Morph-shadowForm.st [^] (655 bytes) 02-02-09 21:54 |
|||||||||||
|
|
||||||||||||
 Relationships |
|||||||||||
|
|||||||||||
|
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. |  |
