New User and the Rectangle class.
Hello! I'm new to this list, so I apologize if this topic has already been considered. I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo. The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g. LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@-4)). This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container. In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left. In order to get things to render correctly in my system, I had to change these messages to look like this: setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom). setPoint: pt1 point: pt2 origin := pt1. corner := pt2. In place of this: setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom). setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y). I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed? Thanks, Trey
Hi Trey, I can't find the rational written down why Rectangle was changed (although it WAS written down). If I remember right, the rational was roughly "Rectangles represent areas of the screen. As such, they should be 'well formed'- positive width and height only". In any case, going back through the archives, I found this bit of advice: " You need to use a different API: for example: frame := (0 @ 0 corner: 1.0 @ 1.0) asLayoutFrame topLeftOffset: 0 @ 50; bottomRightOffset: 0@50 negated. " Thanks, -cbc On Tue, Jun 20, 2017 at 3:10 PM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@ -4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom). setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom). setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
iirc there was proposal to rename Rectangle to DisplayRectangle (or something like that), because you are certainly not the first one to run into such trouble. P On Tue, Jun 20, 2017 at 04:03:48PM -0700, Chris Cunningham wrote:
Hi Trey, I can't find the rational written down why Rectangle was changed (although it WAS written down). If I remember right, the rational was roughly "Rectangles represent areas of the screen. As such, they should be 'well formed'- positive width and height only". In any case, going back through the archives, I found this bit of advice:
" You need to use a different API: for example:
frame := (0 @ 0 corner: 1.0 @ 1.0) asLayoutFrame topLeftOffset: 0 @ 50; bottomRightOffset: 0@50 negated. "
Thanks, -cbc
On Tue, Jun 20, 2017 at 3:10 PM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@ -4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom). setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom). setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
Chris/Peter: Thank you for taking the time to respond. It's good to know that I'm not the only one to encounter this problem. Chris: Thank you for the reference to the topLeftOffset:bottomRightOffset: API, that resolved my problem really well. I'm glad to have a solution that doesn't have me modifying base classes every time I open a fresh image. Thanks, Trey On Wed, Jun 21, 2017 at 6:00 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
iirc there was proposal to rename Rectangle to DisplayRectangle (or something like that), because you are certainly not the first one to run into such trouble.
P
On Tue, Jun 20, 2017 at 04:03:48PM -0700, Chris Cunningham wrote:
Hi Trey, I can't find the rational written down why Rectangle was changed (although it WAS written down). If I remember right, the rational was roughly "Rectangles represent areas of the screen. As such, they should be 'well formed'- positive width and height only". In any case, going back through the archives, I found this bit of advice:
" You need to use a different API: for example:
frame := (0 @ 0 corner: 1.0 @ 1.0) asLayoutFrame topLeftOffset: 0 @ 50; bottomRightOffset: 0@50 negated. "
Thanks, -cbc
On Tue, Jun 20, 2017 at 3:10 PM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@ -4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom). setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom). setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
On Wed, Jun 21, 2017 at 10:17 PM, Trey Tomes <trey.tomes@gmail.com> wrote:
Chris: Thank you for the reference to the topLeftOffset:bottomRightOffset: API, that resolved my problem really well.
@all, Would this be suitable for a QA rule? cheers -ben
I'm glad to have a solution that doesn't have me modifying base classes every time I open a fresh image.
Thanks, Trey
On Wed, Jun 21, 2017 at 6:00 AM, Peter Uhnak <i.uhnak@gmail.com> wrote:
iirc there was proposal to rename Rectangle to DisplayRectangle (or something like that), because you are certainly not the first one to run into such trouble.
P
On Tue, Jun 20, 2017 at 04:03:48PM -0700, Chris Cunningham wrote:
Hi Trey, I can't find the rational written down why Rectangle was changed (although it WAS written down). If I remember right, the rational was roughly "Rectangles represent areas of the screen. As such, they should be 'well formed'- positive width and height only". In any case, going back through the archives, I found this bit of advice:
" You need to use a different API: for example:
frame := (0 @ 0 corner: 1.0 @ 1.0) asLayoutFrame topLeftOffset: 0 @ 50; bottomRightOffset: 0@50 negated. "
Thanks, -cbc
On Tue, Jun 20, 2017 at 3:10 PM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@ -4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom). setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom). setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
Welcome Trey This is nice. Did you see that we started long time ago to have a version of the original tutorial on github to port it to Pharo. Feel free to send pull requests. About this API. the old API was not good because it forced you to create a bogus rectangle often for nothing and also points for nothing. It is better to use the accessors to set the value since a layoutFrame is initialized first. Have a look at the users of LayoutFrame or asLayoutFrame. There is no raison to create a point 0@200 if you can just use the correct accessors to set 200. stef On Wed, Jun 21, 2017 at 12:10 AM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@-4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom).
setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom).
setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
Avoid fraction:offset: it is a bad interface. On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Welcome Trey
This is nice. Did you see that we started long time ago to have a version of the original tutorial on github to port it to Pharo. Feel free to send pull requests.
About this API. the old API was not good because it forced you to create a bogus rectangle often for nothing and also points for nothing. It is better to use the accessors to set the value since a layoutFrame is initialized first. Have a look at the users of LayoutFrame or asLayoutFrame. There is no raison to create a point 0@200 if you can just use the correct accessors to set 200.
stef
On Wed, Jun 21, 2017 at 12:10 AM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@-4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom).
setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom).
setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
I did not know about the GitHub tutorial. I'll take a look for it. Will fraction:offset: be deprecated then you think? ~Trey On Thu, Jun 22, 2017 at 12:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Avoid fraction:offset: it is a bad interface.
On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Welcome Trey
This is nice. Did you see that we started long time ago to have a version of the original tutorial on github to port it to Pharo. Feel free to send pull requests.
About this API. the old API was not good because it forced you to create a bogus rectangle often for nothing and also points for nothing. It is better to use the accessors to set the value since a layoutFrame is initialized first. Have a look at the users of LayoutFrame or asLayoutFrame. There is no raison to create a point 0@200 if you can just use the correct accessors to set 200.
stef
On Wed, Jun 21, 2017 at 12:10 AM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@ -4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom).
setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom).
setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
Yes I thought that they were because they are a BAD design. No need to create dummy rectangle when you have a fully nice api. On Thu, Jun 22, 2017 at 3:48 PM, Trey Tomes <trey.tomes@gmail.com> wrote:
I did not know about the GitHub tutorial. I'll take a look for it.
Will fraction:offset: be deprecated then you think?
~Trey
On Thu, Jun 22, 2017 at 12:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Avoid fraction:offset: it is a bad interface.
On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Welcome Trey
This is nice. Did you see that we started long time ago to have a version of the original tutorial on github to port it to Pharo. Feel free to send pull requests.
About this API. the old API was not good because it forced you to create a bogus rectangle often for nothing and also points for nothing. It is better to use the accessors to set the value since a layoutFrame is initialized first. Have a look at the users of LayoutFrame or asLayoutFrame. There is no raison to create a point 0@200 if you can just use the correct accessors to set 200.
stef
On Wed, Jun 21, 2017 at 12:10 AM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@-4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom).
setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom).
setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
Here is the comment fractions: fractionsOrNil "Do not use this API if you do not have already have the rectangles that should be passed as argument. If you are creating the rectangles representing the numbers you need, better use the accessors: (LayoutFrame identity topOffset: topHeight; bottomFraction: 0; bottomOffset: self buttonsBarHeight; leftOffset: -1; rightOffset: 1) In particular do not use (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) but favor LayoutFrame identity which is faster and more readable. " ^ self fractions: fractionsOrNil offsets: nil On Sat, Jun 24, 2017 at 9:38 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Yes I thought that they were because they are a BAD design. No need to create dummy rectangle when you have a fully nice api.
On Thu, Jun 22, 2017 at 3:48 PM, Trey Tomes <trey.tomes@gmail.com> wrote:
I did not know about the GitHub tutorial. I'll take a look for it.
Will fraction:offset: be deprecated then you think?
~Trey
On Thu, Jun 22, 2017 at 12:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Avoid fraction:offset: it is a bad interface.
On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Welcome Trey
This is nice. Did you see that we started long time ago to have a version of the original tutorial on github to port it to Pharo. Feel free to send pull requests.
About this API. the old API was not good because it forced you to create a bogus rectangle often for nothing and also points for nothing. It is better to use the accessors to set the value since a layoutFrame is initialized first. Have a look at the users of LayoutFrame or asLayoutFrame. There is no raison to create a point 0@200 if you can just use the correct accessors to set 200.
stef
On Wed, Jun 21, 2017 at 12:10 AM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@-4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom).
setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom).
setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
We spent several days fixing the complete system to avoid this crappy broken rectangle. Now it is time to deprecated this bad api. https://pharo.fogbugz.com/f/cases/20180/Deprecate-fractions-offsets-and-frac... On Sat, Jun 24, 2017 at 9:42 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Here is the comment
fractions: fractionsOrNil "Do not use this API if you do not have already have the rectangles that should be passed as argument. If you are creating the rectangles representing the numbers you need, better use the accessors: (LayoutFrame identity topOffset: topHeight; bottomFraction: 0; bottomOffset: self buttonsBarHeight; leftOffset: -1; rightOffset: 1) In particular do not use (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) but favor LayoutFrame identity which is faster and more readable. " ^ self fractions: fractionsOrNil offsets: nil
On Sat, Jun 24, 2017 at 9:38 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Yes I thought that they were because they are a BAD design. No need to create dummy rectangle when you have a fully nice api.
On Thu, Jun 22, 2017 at 3:48 PM, Trey Tomes <trey.tomes@gmail.com> wrote:
I did not know about the GitHub tutorial. I'll take a look for it.
Will fraction:offset: be deprecated then you think?
~Trey
On Thu, Jun 22, 2017 at 12:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Avoid fraction:offset: it is a bad interface.
On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Welcome Trey
This is nice. Did you see that we started long time ago to have a version of the original tutorial on github to port it to Pharo. Feel free to send pull requests.
About this API. the old API was not good because it forced you to create a bogus rectangle often for nothing and also points for nothing. It is better to use the accessors to set the value since a layoutFrame is initialized first. Have a look at the users of LayoutFrame or asLayoutFrame. There is no raison to create a point 0@200 if you can just use the correct accessors to set 200.
stef
On Wed, Jun 21, 2017 at 12:10 AM, Trey Tomes <trey.tomes@gmail.com> wrote:
Hello!
I'm new to this list, so I apologize if this topic has already been considered.
I have been re-creating the Laser Game tutorial in Pharo 6, and have encountered something that may be an error within Pharo.
The LayoutFrame has the ability to use negative values for the bottom and right sides of the rectangle assigned to the offsets, e.g.
LayoutFrame fraction: ((0@0 corner: (1@1)) offsets: ((4@4 corner: (-4@-4)).
This is useful, as it allows the system to automatically calculate the margins inset from the bottom and right sides of the container.
In Pharo 6, this does not work. The setLeft:right:top:bottom: and setPoint:point: messages both use the min: and max: messages to rearrange the Rectangle so that the smallest numbers get pushed to the top and left.
In order to get things to render correctly in my system, I had to change these messages to look like this:
setLeft: left right: right top: top bottom: bottom self setPoint: (left@top) point: (right@bottom).
setPoint: pt1 point: pt2 origin := pt1. corner := pt2.
In place of this:
setLeft: left right: right top: top bottom: bottom origin := (left min: right) @ (top min: bottom). corner := (left max: right) @ (top max: bottom).
setPoint: pt1 point: pt2 origin := (pt1 x min: pt2 x) @ (pt1 y min: pt2 y). corner := (pt1 x max: pt2 x) @ (pt1 y max: pt2 y).
I haven't found any bad side-effects to changing this yet, but is there a reason the Rectangle class was changed?
Thanks, Trey
participants (5)
-
Ben Coman -
Chris Cunningham -
Peter Uhnak -
Stephane Ducasse -
Trey Tomes