Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001035 [Squeak] Morphic minor always 04-02-05 15:28 04-18-10 22:05
Reporter kosik View Status public  
Assigned To andreas
Priority normal Resolution fixed  
Status closed   Product Version 3.9
Summary 0001035: Strange behavior polygon morph added to a rectangle morph with proportional layout
Description When I do this:

  submorph := (PolygonMorph vertices: {0@0. 100@0. 0@100} color: Color red borderWidth: 0 borderColor: Color transparent) color: Color red.
  submorph openInWorld.

  morph := Morph new
  color: Color blue;
  layoutPolicy: ProportionalLayout new;
  addMorph: submorph
    fullFrame: (LayoutFrame fractions: (0.1 @ 0.1 corner: 0.9 @ 0.9));
    openInWorld.

  morph position: 100@100. />
So far everything works as one would expect. However, when I do this:

  morph extent:
100@100. />
Strage things happen. The (polygon) submorph is misplaced relatively to its supermorph.

Strangely, when I resize the supermorph with the yellow halo, the submorph becomes positioned correctly.

When we use something else (e.g. RectangleMorph) instead of the PolygonMorph, this problem will not occur.
Additional Information
Attached Files  PolygonMorph-extent-Test-M1035-kosik-nice.1.cs [^] (1,871 bytes) 02-16-08 01:33
 PolygonMorph-extent-Patch-M1035-nice.1.cs [^] (835 bytes) 02-16-08 01:34

- Relationships
child of 0006511new  Mother of all Morphic Graphical off-by-one/fencepost -error reports. 

- Notes
(0003427 - 1036 - 1150 - 1210 - 1210 - 1210 - 1210)
wiz
01-05-06 05:16
edited on: 01-05-06 05:23

More Clues:

I followed the implementers for the growth handle actions and discovered that the growth hanlde eventually just calls morph extent: anExtent. so in theory there should be no difference.

Of course in practice there is. Initial setting the extent displays the morphs triangle submorph in the wrong place. But after I did it a few times the odd behavior stopped. To see what I mean:

Move the morph, then resize the morph w/ growth handle then using a workspace perform a doit on:

morph position: 100@100 .
morph extent: 100@100 .

The strange behaviour disappears and the triangle appears positioned inside the morph where it should be.

It also looked to me that the triangle was being set to the correct size but merely positioned wrong when the strange behavior was occuring. So this would suggest that something was not getting initialized properly in LayoutFrame until...?

Thank you kosik for a good reproducible report. Hope these observations help.

Yours in service -- (wiz) Jerome Peace

 
(0011814 - 2027 - 3051 - 3382 - 3382 - 3382 - 3382)
nicolas cellier
02-16-08 01:03

Hard to debug code while World is stepping.
But you can play the bug without any interaction, don't openInWorld:

  submorph := (PolygonMorph
    vertices: {0@0. 100@0. 0@100}
    color: Color red borderWidth: 0 borderColor: Color transparent)
       color: Color red.

  submorph bounds. "0@0 corner: 100@100"

  morph := Morph new
    color: Color blue;
    layoutPolicy: ProportionalLayout new;
    addMorph: submorph
      fullFrame: (LayoutFrame fractions: (0.1 @ 0.1 corner: 0.9 @ 0.9)).

  submorph bounds. "0@0 corner: 100@100 NOT YET UPDATED"
  morph fullBounds. "0@0 corner: 50@40. CORRECT"
  submorph bounds. "5@4 corner: 45@36 NOW UPDATED OK"

  morph extent: 100@100. />   submorph bounds. "5@4 corner: 45@36 NOT YET UPDATED"
  morph fullBounds. "-10@-14 corner: 100@100 WRONG"
  submorph bounds. "-10@-14 corner: 70@66 NOW WRONG POSITION (BUT RIGHT EXTENT)"

  self assert: (submorph bounds = (10@10 corner: 90@90)) "would fail..."

Then you happily debugIt and find the guilty:

Morph>>#bounds: newBounds
    | oldExtent newExtent |
    oldExtent _ self extent.
    newExtent _ newBounds extent.
    (oldExtent dotProduct: oldExtent) <= (newExtent dotProduct: newExtent) ifTrue:[
        "We're growing. First move then resize."
        self position: newBounds topLeft; extent: newExtent.
    ] ifFalse:[
        "We're shrinking. First resize then move."
        self extent: newExtent; position: newBounds topLeft.
    ].

First fullBounds call triggered a shrinking submorph extent: that worked, while second triggered a growing extent: that failed...

Well, these two operations are not commutative because PolygonMorph is resized with its center being invariant. So when you change its extent, you also change its origin. So it should always adjust the position afterwards...

I guess PolygonMorph>>#extent: is not behaving correctly.

Here two choices:
- either correct PolygonMorph>>#extent: (will this imply other bugs?)
- or implement bounds: in PolygonMorph as a workaround for this bug

Jerome?
 
(0011815 - 107 - 125 - 125 - 125 - 125 - 125)
nicolas cellier
02-16-08 01:35
edited on: 02-16-08 01:35

Cowardly chosed option # 2, implement PolygonMorph>>#bounds: in PolygonMorph-extent-Patch-M1035-nice.1.cs

 
(0011819 - 2433 - 2625 - 2625 - 2625 - 2625 - 2625)
wiz
02-16-08 20:08
edited on: 02-27-08 04:14

Hmm,


At one point I looked into the differences between morphs with submorphs (and no layout policy).

The submorphs of polygons acted differently than the submorphs of rectangles (and ellipses) when extent was changed. That was because rectangles use the origin (topLeft) as the invarient point and the submorphs will keep an invarient distance from the origin. So stretching a rectange appears to have no effect on its submorphs size or position. And of course when rectangles are rotated the transformMorph will make the submorphs appear to rotate and scale with the rectangle.

Polygons using the same policy (submorphs an invarient distance from the topLeft of bounds). Behave differently because the topLeft of bounds is not the invarient. And polygons do not use transformMorphs for rotation or scaling.

My desired repair was to collect the reference points of a polygons submorphs and treat them to the same transformation (stretching and/or reflection, scaling and/or rotation) as the polygon.

The polygon could then ask the submorphs politely if they would like to internally transform as well.

This had some pleasing results but also some implications for what rectangles submorphs would have to do to be consistent with that.
I thought of tackling that but wondered if I could sell it to anyone.

Then, I realized all I was doing would have to be integrated with layout policy . And put it on a back burner until I knew enough about layout to know what was feasable.

I have no great conclusion. I still don't know how layout is to be properly done. Left to my own devices I would think that scaling the submorph and then laying out its owner to fit would work better than scaling the polygon first and then pretending the rectangular bounds was good for the layout.

I worked hard to make polygons able to mimic either rectangle or ellipses.
The principle I would like to see carried out in layout policy would be that polygons act enough like rectangles and ellipses that the mimicry is undetectable. But I don't know how to do that. And I am aware that there will be changes that have to happen on the rectangle side as well as the polygon side for things to work right.

I've been reading John Maloney's code for scratch blocks. The part where he does relayout on scratch blocks was insightful.


I'll look at the patch.

Hth,

Yours in curiosity and service, --Jerome Peace

 
(0012755 - 195 - 249 - 249 - 249 - 249 - 249)
nicolas cellier
10-26-08 21:13

"fix begin"
Installer mantis bug: 1035 fix: 'PolygonMorph-extent-Patch-M1035-nice.1.cs'.
"fix test"
Installer mantis bug: 1035 fix: 'PolygonMorph-extent-Test-M1035-kosik-nice.1.cs'.
"fix end"
 
(0013321 - 395 - 455 - 767 - 767 - 767 - 767)
nicolas cellier
09-25-09 19:52

Fixed in
http://source.squeak.org/trunk/Morphic-nice.191.mcz [^]
http://source.squeak.org/trunk/MorphicTests-nice.12.mcz [^]

16x more code editions than tests editions ?
I guess SUnit test coverage is poor !

Unless we need 16 source code attempts for correcting one bug ?
This would be a serious alert about quality of code ;)

I prefer explanation 1, but fear explanation 2 is a bit true...
 

- Issue History
Date Modified Username Field Change
04-02-05 15:28 kosik New Issue
08-24-05 01:03 kosik Issue Monitored: kosik
01-05-06 05:16 wiz Note Added: 0003427
01-05-06 05:19 wiz Note Edited: 0003427
01-05-06 05:23 wiz Note Edited: 0003427
10-09-07 03:21 matthewf Relationship added child of 0006511
02-16-08 01:03 nicolas cellier Note Added: 0011814
02-16-08 01:33 nicolas cellier File Added: PolygonMorph-extent-Test-M1035-kosik-nice.1.cs
02-16-08 01:34 nicolas cellier File Added: PolygonMorph-extent-Patch-M1035-nice.1.cs
02-16-08 01:35 nicolas cellier Note Added: 0011815
02-16-08 01:35 nicolas cellier Note Edited: 0011815
02-16-08 20:08 wiz Note Added: 0011819
02-27-08 04:14 wiz Note Edited: 0011819
10-26-08 21:13 nicolas cellier Note Added: 0012755
01-09-09 23:46 Keith_Hodges Assigned To  => Keith_Hodges
01-09-09 23:46 Keith_Hodges Status new => pending
01-10-09 03:26 Keith_Hodges Status pending => testing
01-10-09 03:39 Keith_Hodges Status testing => resolved
01-10-09 03:39 Keith_Hodges Fixed in Version  => 3.11
01-10-09 03:39 Keith_Hodges Resolution open => fixed
01-10-09 03:41 Keith_Hodges Status resolved => testing
09-25-09 19:52 nicolas cellier Note Added: 0013321
10-03-09 19:33 Keith_Hodges Status testing => assigned
10-03-09 19:33 Keith_Hodges Assigned To Keith_Hodges => andreas
10-03-09 20:17 nicolas cellier Status assigned => resolved
10-03-09 20:17 nicolas cellier Fixed in Version 3.11 => trunk
04-18-10 22:05 andreas Status resolved => closed


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
91 total queries executed.
47 unique queries executed.
Powered by Mantis Bugtracker