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 <[hidden email]> 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 <[hidden email]> 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. Thanks, Trey On Wed, Jun 21, 2017 at 6:00 AM, Peter Uhnak <[hidden email]> 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. |
On Wed, Jun 21, 2017 at 10:17 PM, Trey Tomes <[hidden email]> wrote:
@all, Would this be suitable for a QA rule? cheers -ben
|
In reply to this post by Trey Tomes
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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. ~Trey On Thu, Jun 22, 2017 at 12:20 AM, Stephane Ducasse <[hidden email]> wrote: Avoid fraction:offset: it is a bad interface. |
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 <[hidden email]> 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 <[hidden email]> > wrote: >> >> Avoid fraction:offset: it is a bad interface. >> >> >> >> On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse >> <[hidden email]> 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 <[hidden email]> >> > 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >> wrote: >>> >>> Avoid fraction:offset: it is a bad interface. >>> >>> >>> >>> On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse >>> <[hidden email]> 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 <[hidden email]> >>> > 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-fractions On Sat, Jun 24, 2017 at 9:42 PM, Stephane Ducasse <[hidden email]> 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 > <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >>> wrote: >>>> >>>> Avoid fraction:offset: it is a bad interface. >>>> >>>> >>>> >>>> On Thu, Jun 22, 2017 at 7:20 AM, Stephane Ducasse >>>> <[hidden email]> 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 <[hidden email]> >>>> > 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 >>>> >>> |
Free forum by Nabble | Edit this page |