[Pharo-project] Behavior of Rectangle
Dear List, I spend quite some time in tracking down a bug in Mondrian. I found it. The source of it stems from the following behavior in Pharo: -=-=-=-=-=-= (0@0 corner: 10@10) containsPoint: 5@5. => true (10@10 corner: 0@0) containsPoint: 5@5. => false -=-=-=-=-=-= I find the latter a bit surprising. VW returns false as well. I would expect the second expression to return true. There is also "(10@0 corner: 0@10) containsPoint: 5@5. => false" I looked in the Pharo mailing list archive, and apparently this hasn't been discussed yet. The class Rectangle is central. Modifying it (either by making "(10@10 corner: 0@0) containsPoint: 5@5" returns true or not permitting a rectangle "(10@10 corner: 0@0)" to be valid) may have some serious impact. What do you think? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre, I can't tell why exactly, but this kind of discussion seems /déjà vu/ for me. . . I agree I cannot find the specific thread about it. OTOH, it brings an opportunity to solve the issue 'fixing' it where it belongs: containsPoint: aPoint "Answer whether aPoint is within the receiver." ^origin <= aPoint and: [aPoint < corner] The method in question is implemented using an overloading of the #<= on Point. I don't think points could be considered comparable. . . Anyway the operator is 'overloaded' and the method comment is clearly showing the intent of the implementation: <= aPoint "Answer whether the receiver is neither below nor to the right of aPoint." ^x <= aPoint x and: [y <= aPoint y] About the impacts you see, I didn't have time to do a thorough research. Why doing (No attempt to optimize, just to put the perspective): containsPoint: aPoint "Answer whether aPoint is within the receiver." ^(origin <= aPoint and: [aPoint < corner]) or: [corner <= aPoint and: [aPoint < origin]] Has impacts in present Pharo code? -- Cesar Rabak Em 22/04/2010 16:55, Alexandre Bergel < alexandre@bergel.eu > escreveu: Dear List, I spend quite some time in tracking down a bug in Mondrian. I found it. The source of it stems from the following behavior in Pharo: -=-=-=-=-=-= (0@0 corner: 10@10) containsPoint: 5@5. => true (10@10 corner: 0@0) containsPoint: 5@5. => false -=-=-=-=-=-= I find the latter a bit surprising. VW returns false as well. I would expect the second expression to return true. There is also "(10@0 corner: 0@10) containsPoint: 5@5. => false" I looked in the Pharo mailing list archive, and apparently this hasn't been discussed yet. The class Rectangle is central. Modifying it (either by making "(10@10 corner: 0@0) containsPoint: 5@5" returns true or not permitting a rectangle "(10@10 corner: 0@0)" to be valid) may have some serious impact. What do you think? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 22.04.2010 22:14, csrabak@bol.com.br wrote:
Alexandre,
I can't tell why exactly, but this kind of discussion seems /déjà vu/ for me. . . I agree I cannot find the specific thread about it. That's because it was on the vwnc-mailing list:
http://forum.world.st/vwnc-Rectangle-td1414824.html Cheers, Henry
Yes! There it is! Thanks, -- Cesar Rabak Em 22/04/2010 17:18, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no > escreveu: On 22.04.2010 22:14, csrabak@bol.com.br wrote:
Alexandre,
I can't tell why exactly, but this kind of discussion seems /déjà vu/ for me. . . I agree I cannot find the specific thread about it. That's because it was on the vwnc-mailing list:
http://forum.world.st/vwnc-Rectangle-td1414824.html Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Guys - in coming back to Smalltalk - the energy of Pharo and the improved look was something that really attracted me however as I keep finding moments to play with it, and I show other people what has been built - one of the big comments from newcomers is: "Whats with the ugly buttons in the browser"? - this is in reference to the browse|hierarchy|variables... buttons in OB. I just happened to try a new Squeak 4.1 image on the weekend, and I noticed that their buttons are much nicer - they are smaller and neater than in Pharo. I had a look to see where they are created in Pharo- I think its OBFixedButtonPanel but I am not familiar enough with these internals to know how to fix it. I do know if you set the individual buttons to a #rigid style they shrink (but are too small) - so its something to do with setting the height of the container. I also wonder if its time to stop stretching buttons across the width of the browser - on a 27" iMac it looks strange when you zoom a window and get huge buttons. Whats wrong with left aligning the buttons and maybe having them all the same size? I also notice the that browser title bars are much taller than normal mac application title bars (and again in Squeak 4.1 they are smaller and match the native windows). I know these are small things - but they detract from the good work that is happening - and I want to show newcomers something that they find cool too. If someone can point me to where to look for these things, I would gladly fix and test them - but I'm stumped (and I'm sure they could be fixed in 2 minutes by someone knowledgeable). Tim
Hi Tim,
"Whats with the ugly buttons in the browser"? - this is in reference to the browse|hierarchy|variables... buttons in OB.
Are you sure that you use the latest OB code, because I recently made the buttons smaller?
I do know if you set the individual buttons to a #rigid style they shrink (but are too small) - so its something to do with setting the height of the container.
Ok, I see. There are some hardcoded heights. I fixed this in OB-Morphic-lr.121. Depending on the theme you use this reduces the heights of the buttons a few pixels. Name: OB-Morphic-lr.121 Author: lr Time: 26 April 2010, 9:45:15 am UUID: 17704c53-3b7f-4605-9917-48ad4cecf448 Ancestors: OB-Morphic-lr.120 - let the theme decide the height of buttons Name: OB-Tests-Morphic-lr.27 Author: lr Time: 26 April 2010, 9:45:42 am UUID: dca1b619-088c-4e4c-85a1-f10a0b5e5f05 Ancestors: OB-Tests-Morphic-lr.26 - let the theme decide the height of buttons
I also wonder if its time to stop stretching buttons across the width of the browser - on a 27" iMac it looks strange when you zoom a window and get huge buttons. Whats wrong with left aligning the buttons and maybe having them all the same size?
I think that looks worse. You can disable the "optionalButtonPane" in the preferences. Lukas -- Lukas Renggli www.lukas-renggli.ch
I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports). I'm interested in your changes so that I can start to figure out how some of this stuff is done so that maybe one day I can contribute something helpful. Thanks for looking at this though - it does help. Tim On 26 Apr 2010, at 08:47, Lukas Renggli wrote:
Hi Tim,
"Whats with the ugly buttons in the browser"? - this is in reference to the browse|hierarchy|variables... buttons in OB.
Are you sure that you use the latest OB code, because I recently made the buttons smaller?
I do know if you set the individual buttons to a #rigid style they shrink (but are too small) - so its something to do with setting the height of the container.
Ok, I see. There are some hardcoded heights. I fixed this in OB-Morphic-lr.121. Depending on the theme you use this reduces the heights of the buttons a few pixels.
Name: OB-Morphic-lr.121 Author: lr Time: 26 April 2010, 9:45:15 am UUID: 17704c53-3b7f-4605-9917-48ad4cecf448 Ancestors: OB-Morphic-lr.120
- let the theme decide the height of buttons
Name: OB-Tests-Morphic-lr.27 Author: lr Time: 26 April 2010, 9:45:42 am UUID: dca1b619-088c-4e4c-85a1-f10a0b5e5f05 Ancestors: OB-Tests-Morphic-lr.26
- let the theme decide the height of buttons
I also wonder if its time to stop stretching buttons across the width of the browser - on a 27" iMac it looks strange when you zoom a window and get huge buttons. Whats wrong with left aligning the buttons and maybe having them all the same size?
I think that looks worse. You can disable the "optionalButtonPane" in the preferences.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports).
I am using (and fixing) OB in Pharo 1.0. OB will only be adopted to the upcoming Pharo when Pharo 1.1 reaches a stable state so that I can confidently adopt it for my daily work. I don't have the time to maintain two OB branches. Though OB should work in Pharo 1.1 just fine, if you disable the deprecated warnings. Lukas -- Lukas Renggli www.lukas-renggli.ch
Lukas by 15 of may we will code freeze 1.1. Stef On Apr 26, 2010, at 11:20 AM, Lukas Renggli wrote:
I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports).
I am using (and fixing) OB in Pharo 1.0. OB will only be adopted to the upcoming Pharo when Pharo 1.1 reaches a stable state so that I can confidently adopt it for my daily work. I don't have the time to maintain two OB branches.
Though OB should work in Pharo 1.1 just fine, if you disable the deprecated warnings.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I loaded it into my 1.0 image (I have to confess it took me a moment to find the right package in monticello - the name "* OB-Standard" - the leading * putting it at the top meant that I couldn't find it at first - does that * mean that I changed a method in that package when I was putting self halt in methods?). Anyway - that does look much better! Is there a similar fix to make the window title bars smaller as well? On my mac they are larger than other native OSX windows, that is the browser title bars are bigger than the actual "Pharo 1.0 Image" title bar of the whole VM. I noticed that in Squeak 4.1 the title bars of all browsers all seem to be native size. I am wondering if there is a similar fix? Although - just having smaller buttons in that bar makes me feel more comfortable - and we'll see what the skeptics in the office say tomorrow! Tim On 26 Apr 2010, at 10:20, Lukas Renggli wrote:
I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports).
I am using (and fixing) OB in Pharo 1.0. OB will only be adopted to the upcoming Pharo when Pharo 1.1 reaches a stable state so that I can confidently adopt it for my daily work. I don't have the time to maintain two OB branches.
Though OB should work in Pharo 1.1 just fine, if you disable the deprecated warnings.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Tim you can configure the MC browser to see the dirty in place or at the top. Bring the menu there is a radio button for that On Apr 27, 2010, at 12:11 AM, Tim Mackinnon wrote:
I loaded it into my 1.0 image (I have to confess it took me a moment to find the right package in monticello - the name "* OB-Standard" - the leading * putting it at the top meant that I couldn't find it at first - does that * mean that I changed a method in that package when I was putting self halt in methods?).
Anyway - that does look much better!
Is there a similar fix to make the window title bars smaller as well? On my mac they are larger than other native OSX windows, that is the browser title bars are bigger than the actual "Pharo 1.0 Image" title bar of the whole VM. I noticed that in Squeak 4.1 the title bars of all browsers all seem to be native size. I am wondering if there is a similar fix?
Although - just having smaller buttons in that bar makes me feel more comfortable - and we'll see what the skeptics in the office say tomorrow!
Tim
On 26 Apr 2010, at 10:20, Lukas Renggli wrote:
I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports).
I am using (and fixing) OB in Pharo 1.0. OB will only be adopted to the upcoming Pharo when Pharo 1.1 reaches a stable state so that I can confidently adopt it for my daily work. I don't have the time to maintain two OB branches.
Though OB should work in Pharo 1.1 just fine, if you disable the deprecated warnings.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Is there a similar fix to make the window title bars smaller as well? On my mac they are larger than other native OSX windows, that is the browser title bars are bigger than the actual "Pharo 1.0 Image" title bar of the whole VM. I noticed that in Squeak 4.1 the title bars of all browsers all seem to be native size. I am wondering if there is a similar fix?
I don't know, the size of the title bar either comes from the currently selected theme or your font choice. There is no such thing as "native size" in Squeak or Pharo. Lukas -- Lukas Renggli www.lukas-renggli.ch
I don't know, the size of the title bar either comes from the currently selected theme or your font choice. There is no such thing as "native size" in Squeak or Pharo.
I think my term native size was confusing - I meant compared to the size of windows outside of squeak/pharo (or indeed the OSX window of Pharo itself). Looking a bit closer - I have tried setting the System Font for Window Title - to be 10pt instead of 11 (and that looks a bit better to my mind). However - even when you do this, if you compare the title bar of a classes browser to the title bar of pharo (e.g. "Pharo 1.0 - Image") - you do notice that the classes browser has a few more pixels either side of the close/collapse/expand buttons as compared to the native pharo window. Still - its a minor thing and it doesn't bother me so much now you have fixed the buttons (awesome!). I did get a spurious walkback saying that a some button didn't understand #enabled: - however I haven't been able to reproduce that yet, so it could have been me playing with trying to set button heights? Thanks again. Tim
On Apr 27, 2010, at 2:42 10PM, Tim Mackinnon wrote:
Looking a bit closer - I have tried setting the System Font for Window Title - to be 10pt instead of 11 (and that looks a bit better to my mind). However - even when you do this, if you compare the title bar of a classes browser to the title bar of pharo (e.g. "Pharo 1.0 - Image") - you do notice that the classes browser has a few more pixels either side of the close/collapse/expand buttons as compared to the native pharo window.
Thanks again.
Tim
I agree, for windows the button spacing should be independent of title height derived from font height. At the moment, it just happens to be just about right with a pt10 size font :) Would be nice if the title height also took button size into account actually, with a small font-size the title becomes too narrow to display the full height of the button. Cheers, Henry
Ah - that explains it - thats a tip that I hadn't yet worked out. Thanks for pointing it out (I can see it could be useful when finding all dirty changes - but a bit disorienting when you are a new user trying to find a specific package). On 27 Apr 2010, at 06:47, Stéphane Ducasse wrote:
Tim you can configure the MC browser to see the dirty in place or at the top. Bring the menu there is a radio button for that
On Apr 27, 2010, at 12:11 AM, Tim Mackinnon wrote:
I loaded it into my 1.0 image (I have to confess it took me a moment to find the right package in monticello - the name "* OB-Standard" - the leading * putting it at the top meant that I couldn't find it at first - does that * mean that I changed a method in that package when I was putting self halt in methods?).
Anyway - that does look much better!
Is there a similar fix to make the window title bars smaller as well? On my mac they are larger than other native OSX windows, that is the browser title bars are bigger than the actual "Pharo 1.0 Image" title bar of the whole VM. I noticed that in Squeak 4.1 the title bars of all browsers all seem to be native size. I am wondering if there is a similar fix?
Although - just having smaller buttons in that bar makes me feel more comfortable - and we'll see what the skeptics in the office say tomorrow!
Tim
On 26 Apr 2010, at 10:20, Lukas Renggli wrote:
I'll check that out - do I need to use a 1.1 image? (given that I am only playing at the moment - it probably makes sense to use one now as this is where you are taking bug reports).
I am using (and fixing) OB in Pharo 1.0. OB will only be adopted to the upcoming Pharo when Pharo 1.1 reaches a stable state so that I can confidently adopt it for my daily work. I don't have the time to maintain two OB branches.
Though OB should work in Pharo 1.1 just fine, if you disable the deprecated warnings.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I noticed this too when developing a system whose coordinates are not laid out the same as a computer screen. My solution was to change my coordinate translation of the domain to conform to a computer-screen. :-( Another limitation of Rectangles that isn't obvious is that they are coded to assume their coordinates are all integral. I had been confounded by a bug that ended up being that, when I asked for the #center of a Rectangle with Float coordinates, i.e.: 50.1234@50.9876 corner: 41.1234@41.9876 you get a truncated answer that is completely outside the original rectangle! On Thu, Apr 22, 2010 at 2:55 PM, Alexandre Bergel <alexandre@bergel.eu> wrote:
Dear List,
I spend quite some time in tracking down a bug in Mondrian. I found it. The source of it stems from the following behavior in Pharo: -=-=-=-=-=-= (0@0 corner: 10@10) containsPoint: 5@5. Â => true (10@10 corner: 0@0) containsPoint: 5@5. Â => false -=-=-=-=-=-=
I find the latter a bit surprising. VW returns false as well. I would expect the second expression to return true. There is also "(10@0 corner: 0@10) containsPoint: 5@5. => false"
I looked in the Pharo mailing list archive, and apparently this hasn't been discussed yet.
The class Rectangle is central. Modifying it (either by making "(10@10 corner: 0@0) containsPoint: 5@5" returns true or not permitting a rectangle "(10@10 corner: 0@0)" to be valid) may have some serious impact.
What do you think?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Alexandre Bergel -
Chris Muller -
csrabak＠bol.com.br -
Henrik Johansen -
Henrik Sperre Johansen
-
Lukas Renggli -
Stéphane Ducasse -
Tim Mackinnon