When using TransformationMorph the extent of the tranformation is not given back braking the illusion of scale and rotation. I would assume the right thing would be to return owner extent to a scaled morph ?
Karl
At Fri, 05 Dec 2008 21:54:05 +0100, karl wrote:
When using TransformationMorph the extent of the tranformation is not given back braking the illusion of scale and rotation. I would assume the right thing would be to return owner extent to a scaled morph ?
Can you elaborate the situation a bit?
-- Yoshiki
Yoshiki Ohshima wrote:
At Fri, 05 Dec 2008 21:54:05 +0100, karl wrote:
When using TransformationMorph the extent of the tranformation is not given back braking the illusion of scale and rotation. I would assume the right thing would be to return owner extent to a scaled morph ?
Can you elaborate the situation a bit?
I was trying to get the right dimensions reflected when the painting full screen preference is turned on. The PaintBoxMorph is scaled up on the OLPC and is slightly offscreen because of this. But to get its bounds after scaling is not straight forward because of the transformation. Try this morph := Morph new openInWorld. morph extent => 50@40 morph scaleFactor: 2 (There is also a bug in scaleFactor: if the morph owner is nil ) morph extent => 50@40
This is complicates general code a bit as one must do all kind of contortions to get the right extent.
Karl
At Sat, 06 Dec 2008 14:29:21 +0100, Karl Ramberg wrote:
Yoshiki Ohshima wrote:
At Fri, 05 Dec 2008 21:54:05 +0100, karl wrote:
When using TransformationMorph the extent of the tranformation is not given back braking the illusion of scale and rotation. I would assume the right thing would be to return owner extent to a scaled morph ?
Can you elaborate the situation a bit?
I was trying to get the right dimensions reflected when the painting full screen preference is turned on. The PaintBoxMorph is scaled up on the OLPC and is slightly offscreen because of this. But to get its bounds after scaling is not straight forward because of the transformation. Try this morph := Morph new openInWorld. morph extent => 50@40 morph scaleFactor: 2 (There is also a bug in scaleFactor: if the morph owner is nil ) morph extent => 50@40
This is complicates general code a bit as one must do all kind of contortions to get the right extent.
Ah, right. So for this case, you might have to say "morph isFlexed" and check owner's extent if it is true?
-- Yoshiki
Yoshiki Ohshima wrote:
At Sat, 06 Dec 2008 14:29:21 +0100, Karl Ramberg wrote:
Yoshiki Ohshima wrote:
At Fri, 05 Dec 2008 21:54:05 +0100, karl wrote:
When using TransformationMorph the extent of the tranformation is not given back braking the illusion of scale and rotation. I would assume the right thing would be to return owner extent to a scaled morph ?
Can you elaborate the situation a bit?
I was trying to get the right dimensions reflected when the painting full screen preference is turned on. The PaintBoxMorph is scaled up on the OLPC and is slightly offscreen because of this. But to get its bounds after scaling is not straight forward because of the transformation. Try this morph := Morph new openInWorld. morph extent => 50@40 morph scaleFactor: 2 (There is also a bug in scaleFactor: if the morph owner is nil ) morph extent => 50@40
This is complicates general code a bit as one must do all kind of contortions to get the right extent.
Ah, right. So for this case, you might have to say "morph isFlexed" and check owner's extent if it is true?
No, because a morph without owner can't be flexed. Morph>>addFlexShell http://dev.laptop.org/ticket/9084
For PaintBoxMorph one can check the preference for big paint palette,
Karl
At Mon, 08 Dec 2008 18:01:47 +0100, Karl Ramberg wrote:
No, because a morph without owner can't be flexed. Morph>>addFlexShell http://dev.laptop.org/ticket/9084
For PaintBoxMorph one can check the preference for big paint palette,
Hmm, but the PaintBoxMorph>>beSupersized is alwaysw called with non-nil owner, right? I don't know the original intent of:
self position: self position / scaleFactor.
line, but something like the following is ugly but seems to work.
beSupersized | scaleFactor w m | scaleFactor := 1.5. self isFlexed ifFalse: [self scaleFactor: scaleFactor. m := self isFlexed ifTrue: [owner] ifFalse: [self]. w := m width. m position: Display width - w @ 0. self changed]
I'm not sure if addFlexShell failing nil owner is a real bug in the current system... There are other stuff that requires the onwer.
-- Yoshiki
Yoshiki Ohshima wrote:
At Mon, 08 Dec 2008 18:01:47 +0100, Karl Ramberg wrote:
No, because a morph without owner can't be flexed. Morph>>addFlexShell http://dev.laptop.org/ticket/9084
For PaintBoxMorph one can check the preference for big paint palette,
Hmm, but the PaintBoxMorph>>beSupersized is alwaysw called with non-nil owner, right? I don't know the original intent of:
self position: self position / scaleFactor.
line, but something like the following is ugly but seems to work.
beSupersized | scaleFactor w m | scaleFactor := 1.5. self isFlexed ifFalse: [self scaleFactor: scaleFactor. m := self isFlexed ifTrue: [owner] ifFalse: [self]. w := m width. m position: Display width - w @ 0. self changed]
I have not tested yet but this a lot simpler than what I tried :-)
I'm not sure if addFlexShell failing nil owner is a real bug in the current system... There are other stuff that requires the onwer.
So I'll suggest a method comment mentioning that as a "fix"(clarification) to the bug report I made.
Karl
At Tue, 09 Dec 2008 19:28:41 +0100, Karl Ramberg wrote:
I have not tested yet but this a lot simpler than what I tried :-)
There probably should be another case for non-unlimitedPaintingArea and the cases when repainted object's position is at various locations...
I'm not sure if addFlexShell failing nil owner is a real bug in the current system... There are other stuff that requires the onwer.
So I'll suggest a method comment mentioning that as a "fix"(clarification) to the bug report I made.
Comm... what comment?
Yes, there are other kinds of constraints that a sound Morph graph should satisfy. Method by method comments as well as some outline of these constraints would be really nice.
-- Yoshiki
On Monday 08 Dec 2008 10:31:47 pm Karl Ramberg wrote:
No, because a morph without owner can't be flexed. Morph>>addFlexShell http://dev.laptop.org/ticket/9084
Morphic transformations are really weird. They break the model of World as a hierarchy of visual elements that can be directly manipulated. Dan Ingalls writes about this hack in his "Back to the Future Once More" article (see section 2).
A TransformationMorph is a just a "warp-thingy" op that wraps a target morph only during scaling/rotation. What one manipulates on the screen is then no longer the target morph but its flex shell wrapper. Translations are handled by a morph directly but Scale and Rotate ops are handled by the flex shell. So you can't scale or rotate a new morph before it is "opened" :-)
Does anyone know if this has been fixed in Lively?
Subbu
At Tue, 9 Dec 2008 11:30:46 +0530, K. K. Subramaniam wrote:
On Monday 08 Dec 2008 10:31:47 pm Karl Ramberg wrote:
No, because a morph without owner can't be flexed. Morph>>addFlexShell http://dev.laptop.org/ticket/9084
Morphic transformations are really weird.
They are. Ask Scott how weird they are^^;
A TransformationMorph is a just a "warp-thingy" op that wraps a target morph only during scaling/rotation. What one manipulates on the screen is then no longer the target morph but its flex shell wrapper. Translations are handled by a morph directly but Scale and Rotate ops are handled by the flex shell. So you can't scale or rotate a new morph before it is "opened" :-)
Does anyone know if this has been fixed in Lively?
I think so.
-- Yoshiki
etoys-dev@lists.squeakfoundation.org