February 2015 - Pharo-users

Re: [Pharo-users] RadarMorph (was Re: Canvas Transform Goes Haywire if Scaled)

by Sean P. DeNigris

nacho wrote > question, the UI was made completely in Morphic? or did you use Spec? Both. The standard parts (e.g. window, toolbars) were Spec, and everything inside the World window is pretty much straight Morphic. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Canvas-Transform-Goes-Haywire-if-Scaled-tp4803830p480… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 5, 2015

Re: [Pharo-users] RadarMorph (was Re: Canvas Transform Goes Haywire if Scaled)

by Ignacio Sniechowski

awesome! question, the UI was made completely in Morphic? or did you use Spec? thanks *Lic. Ignacio Sniechowski, MBA* *Prosavic SRL* *Tel: (011) 4542-6714* On Thu, Feb 5, 2015 at 3:06 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Nicolai Hess wrote > > What do you want to achieve? > > I've created an infinite desktop a la Self. To make things manageable, I'm > currently writing a RadarView (also just like Self) to show a map of all > the > objects on the desktop, and the position of the current viewport. It's > working now thanks to your help! > > There is now only 1 major bug, and 3 little glitches: > 1. (BUG): Every once in a while (can't figure out how to reproduce), it > displays the Red X of Death like so: > > <http://forum.world.st/file/n4804025/Screenshot_2015-02-05_11.png> > > 2. When the container window is moved, the contents temporarily jump out of > the radar screen > 3. when the radar is dragged over another morph in the Self World, the > clipping gets very weird > 4. One side of the blue highlight rectangle sometimes disappears on resize > > #2, #3, and #4 can be seen in this screencast: https://vimeo.com/118826521 > > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Canvas-Transform-Goes-Haywire-if-Scaled-tp4803830p480… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Feb. 5, 2015

RadarMorph (was Re: Canvas Transform Goes Haywire if Scaled)

by Sean P. DeNigris

Nicolai Hess wrote > What do you want to achieve? I've created an infinite desktop a la Self. To make things manageable, I'm currently writing a RadarView (also just like Self) to show a map of all the objects on the desktop, and the position of the current viewport. It's working now thanks to your help! There is now only 1 major bug, and 3 little glitches: 1. (BUG): Every once in a while (can't figure out how to reproduce), it displays the Red X of Death like so: <http://forum.world.st/file/n4804025/Screenshot_2015-02-05_11.png> 2. When the container window is moved, the contents temporarily jump out of the radar screen 3. when the radar is dragged over another morph in the Self World, the clipping gets very weird 4. One side of the blue highlight rectangle sometimes disappears on resize #2, #3, and #4 can be seen in this screencast: https://vimeo.com/118826521 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Canvas-Transform-Goes-Haywire-if-Scaled-tp4803830p480… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 5, 2015

Re: [Pharo-users] Question on Morphic drawOn: method.

by nacho

Yes! Point me to those documents and I will love to read them!!! thanks in advance *Lic. Ignacio Sniechowski, MBA* *Prosavic SRL* *Tel: (011) 4542-6714* On Thu, Feb 5, 2015 at 1:02 PM, Trygve Reenskaug [via Smalltalk] < ml-node+s1294792n4804005h48(a)n4.nabble.com> wrote: > > Because your drawOn: method doesn't draw anything and needs help from > super. > It seems to me that you need to read more documentation :-) > > On 05.02.2015 15:53, nacho wrote: > > That work perfectly. What a silly mistake!!! > Of course it should have been position := aPoint. > Now, is it possible write the drawOn: method without calling super drawOn: > a Canvas? > I don't completely get it why I should call super drawOn: aCanvas > thanks > nacho > > > *Lic. Ignacio Sniechowski, MBA* > *Prosavic SRL* > > *Tel: (011) 4542-6714* > > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 5, 2015 at 11:28 AM, Trygve Reenskaug [via Smalltalk] <[hidden > email] <http:///user/SendEmail.jtp?type=node&node=4803979&i=0>> wrote: > >> I've tested your code in Squeak and found another bug (I should have been >> more careful when I read your code. Shame on me.) >> >> In class Ball you have the methods >> >> position: aPoint >> super position: aPoint. >> This does not set a value to your position variable in class Ball, but actually sets the upper-left corner of the bounds. >> You should have said position := aPoint. >> -------------------------------- >> The following now works in mySqueak image: >> EllipseMorph subclass: #Ball >> instanceVariableNames: 'position' >> classVariableNames: '' >> poolDictionaries: '' "this part is needed in Squeak" >> category: 'ZZZtesting' >> >> drawOn: aCanvas >> self borderWidth:10; borderColor: Color green. >> super drawOn: aCanvas. >> >> position >> ^ position. >> >> position: aPoint >> position := aPoint. >> >> >> I then execute the following in a workspace >> | aBall | >> aBall := Ball new. >> aBall position: ( 10@10 ). >> aBall openInWorld. >> >> and it seems to work. But closer scrutiny shows that it ignores your >> instance variable (position). when I move the ball around. >> The reason is that EllipseMorph is a superclass of your Ball and cannot >> possibly know about an instance variable (position) that is defined in the >> subclass (Ball). >> >> I ignored Ball>position since the EllipseMorph doesn't use it: >> >> EllipseMorph subclass: #Ball >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'ZZZtesting' >> >> position >> ^ super position. >> >> position: aPoint >> super position: aPoint. >> This looks better. >> I you really want to replace the EllipseMorph>position you must go deeper >> into how the EllipseMorph handles its position and bounds . This will not >> be trivial. Much easier to invent a new instance variable and use it in the >> drawOn: method. >> >> Good luck with your apprenticeship >> >> >> >> >> >> >> >> >> >> On 05.02.2015 11:56, nacho wrote: >> >> @Trygve >> I've checked and it doesn't work. I can't even bring the halo on to delete >> the morph. The debugger keeps popping. >> Thanks anyway to all >> Nacho >> >> >> >> >> ----- >> Nacho >> Smalltalker apprentice. >> Buenos Aires, Argentina. >> -- >> View this message in context: http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803895.h… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> >> >> >> -- >> >> *The essence of object orientation is that objects collaborate to >> achieve a goal. * >> Trygve Reenskaug [hidden email] >> <http:///user/SendEmail.jtp?type=node&node=4803964&i=0> >> Morgedalsvn. 5A http://folk.uio.no/trygver/ >> N-0378 Oslo http://fullOO.info >> Norway Tel: (+47) 22 49 57 27 >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803964.h… >> To unsubscribe from Question on Morphic drawOn: method., click here. >> NAML >> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> >> > > Nacho Smalltalker apprentice. Buenos Aires, Argentina. > > ------------------------------ > View this message in context: Re: Question on Morphic drawOn: method. > <http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803979.h…> > Sent from the Pharo Smalltalk Users mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com. > > > -- > > *The essence of object orientation is that objects collaborate to achieve > a goal. * > Trygve Reenskaug [hidden email] > <http:///user/SendEmail.jtp?type=node&node=4804005&i=0> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 22 49 57 27 > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4804005.h… > To unsubscribe from Question on Morphic drawOn: method., click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4804006.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 5, 2015

Re: [Pharo-users] Question on Morphic drawOn: method.

by Trygve Reenskaug

Because your drawOn: method doesn't draw anything and needs help from super. It seems to me that you need to read more documentation :-) On 05.02.2015 15:53, nacho wrote: > That work perfectly. What a silly mistake!!! > Of course it should have been position := aPoint. > Now, is it possible write the drawOn: method without calling super > drawOn: a Canvas? > I don't completely get it why I should call super drawOn: aCanvas > thanks > nacho > > > *Lic. Ignacio Sniechowski, MBA** > * > *Prosavic SRL* > * > * > *Tel: (011) 4542-6714* > * > * > * > * > * > * > > * > * > * > * > * > * > * > * > * > * > * > * > > * > * > * > * > * > * > * > > ** > ** > * > > > > > On Thu, Feb 5, 2015 at 11:28 AM, Trygve Reenskaug [via Smalltalk] > <[hidden email] </user/SendEmail.jtp?type=node&node=4803979&i=0>> wrote: > > I've tested your code in Squeak and found another bug (I should > have been more careful when I read your code. Shame on me.) > > In class Ball you have the methods > > position: aPoint > super position: aPoint. > This does not set a value to your position variable in class Ball, but actually sets the upper-left corner of the bounds. > You should have said position := aPoint. > -------------------------------- > The following now works in mySqueak image: > EllipseMorph subclass: #Ball > instanceVariableNames: 'position' > classVariableNames: '' > poolDictionaries: '' "this part is needed in Squeak" > category: 'ZZZtesting' > > drawOn: aCanvas > self borderWidth:10; borderColor: Color green. > super drawOn: aCanvas. > > position > ^ position. > > position: aPoint > position := aPoint. > > I then execute the following in a workspace > | aBall | > aBall := Ball new. > aBall position: ( 10@10 ). > aBall openInWorld. > > and it seems to work. But closer scrutiny shows that it ignores > your instance variable (position). when I move the ball around. > The reason is that EllipseMorph is a superclass of your Ball and > cannot possibly know about an instance variable (position) that is > defined in the subclass (Ball). > > I ignored Ball>position since the EllipseMorph doesn't use it: > > EllipseMorph subclass: #Ball > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'ZZZtesting' > > position > ^ super position. > > position: aPoint > super position: aPoint. > This looks better. > I you really want to replace the EllipseMorph>position you must go > deeper into how the EllipseMorph handles its position and bounds . > This will not be trivial. Much easier to invent a new instance > variable and use it in the drawOn: method. > > Good luck with your apprenticeship > > > > > > > > > > On 05.02.2015 11:56, nacho wrote: >> @Trygve >> I've checked and it doesn't work. I can't even bring the halo on to delete >> the morph. The debugger keeps popping. >> Thanks anyway to all >> Nacho >> >> >> >> >> ----- >> Nacho >> Smalltalker apprentice. >> Buenos Aires, Argentina. >> -- >> View this message in context:http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803895.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> > > -- > > /The essence of object orientation is that objects collaborateto > achieve a goal. / > Trygve Reenskaug [hidden email] > <http:///user/SendEmail.jtp?type=node&node=4803964&i=0> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 22 49 57 27 > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803964.h… > > To unsubscribe from Question on Morphic drawOn: method., click here. > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > > > > Nacho Smalltalker apprentice. Buenos Aires, Argentina. > > ------------------------------------------------------------------------ > View this message in context: Re: Question on Morphic drawOn: method. > <http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803979.h…> > Sent from the Pharo Smalltalk Users mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com. -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27

Feb. 5, 2015

Re: [Pharo-users] Canvas Transform Goes Haywire if Scaled

by Werner Kassens

On 02/05/2015 03:27 PM, Sean P. DeNigris wrote: > This seems so complicated. I would naively think that the API should do much > of this for you. For example, why doesn't it know that when there's an > offset AND a scale, the transform's offset should be adjusted by the scale? Hi Sean, i guess i wouldnt agree; if you look at MorphicTransform>>transform: it very much looks to me like the natural way of first doing a translation and then a scaling. for me they are independent transformations and mixing them up only complicates things if you are doing more involved things. werner

Feb. 5, 2015

Re: [Pharo-users] Question on Morphic drawOn: method.

by nacho

That work perfectly. What a silly mistake!!! Of course it should have been position := aPoint. Now, is it possible write the drawOn: method without calling super drawOn: a Canvas? I don't completely get it why I should call super drawOn: aCanvas thanks nacho *Lic. Ignacio Sniechowski, MBA* *Prosavic SRL* *Tel: (011) 4542-6714* On Thu, Feb 5, 2015 at 11:28 AM, Trygve Reenskaug [via Smalltalk] < ml-node+s1294792n4803964h77(a)n4.nabble.com> wrote: > I've tested your code in Squeak and found another bug (I should have been > more careful when I read your code. Shame on me.) > > In class Ball you have the methods > > position: aPoint > super position: aPoint. > This does not set a value to your position variable in class Ball, but actually sets the upper-left corner of the bounds. > You should have said position := aPoint. > -------------------------------- > The following now works in mySqueak image: > EllipseMorph subclass: #Ball > instanceVariableNames: 'position' > classVariableNames: '' > poolDictionaries: '' "this part is needed in Squeak" > category: 'ZZZtesting' > > drawOn: aCanvas > self borderWidth:10; borderColor: Color green. > super drawOn: aCanvas. > > position > ^ position. > > position: aPoint > position := aPoint. > > > I then execute the following in a workspace > | aBall | > aBall := Ball new. > aBall position: ( 10@10 ). > aBall openInWorld. > > and it seems to work. But closer scrutiny shows that it ignores your > instance variable (position). when I move the ball around. > The reason is that EllipseMorph is a superclass of your Ball and cannot > possibly know about an instance variable (position) that is defined in the > subclass (Ball). > > I ignored Ball>position since the EllipseMorph doesn't use it: > > EllipseMorph subclass: #Ball > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'ZZZtesting' > > position > ^ super position. > > position: aPoint > super position: aPoint. > This looks better. > I you really want to replace the EllipseMorph>position you must go deeper > into how the EllipseMorph handles its position and bounds . This will not > be trivial. Much easier to invent a new instance variable and use it in the > drawOn: method. > > Good luck with your apprenticeship > > > > > > > > > > On 05.02.2015 11:56, nacho wrote: > > @Trygve > I've checked and it doesn't work. I can't even bring the halo on to delete > the morph. The debugger keeps popping. > Thanks anyway to all > Nacho > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803895.h… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > -- > > *The essence of object orientation is that objects collaborate to achieve > a goal. * > Trygve Reenskaug [hidden email] > <http:///user/SendEmail.jtp?type=node&node=4803964&i=0> > Morgedalsvn. 5A http://folk.uio.no/trygver/ > N-0378 Oslo http://fullOO.info > Norway Tel: (+47) 22 49 57 27 > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803964.h… > To unsubscribe from Question on Morphic drawOn: method., click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803979.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 5, 2015

Re: [Pharo-users] Question on Morphic drawOn: method.

by Trygve Reenskaug

I've tested your code in Squeak and found another bug (I should have been more careful when I read your code. Shame on me.) In class Ball you have the methods position: aPoint super position: aPoint. This does not set a value to your position variable in class Ball, but actually sets the upper-left corner of the bounds. You should have said position := aPoint. -------------------------------- The following now works in mySqueak image: EllipseMorph subclass: #Ball instanceVariableNames: 'position' classVariableNames: '' poolDictionaries: '' "this part is needed in Squeak" category: 'ZZZtesting' drawOn: aCanvas self borderWidth:10; borderColor: Color green. super drawOn: aCanvas. position ^ position. position: aPoint position := aPoint. I then execute the following in a workspace | aBall | aBall := Ball new. aBall position: ( 10@10 ). aBall openInWorld. and it seems to work. But closer scrutiny shows that it ignores your instance variable (position). when I move the ball around. The reason is that EllipseMorph is a superclass of your Ball and cannot possibly know about an instance variable (position) that is defined in the subclass (Ball). I ignored Ball>position since the EllipseMorph doesn't use it: EllipseMorph subclass: #Ball instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'ZZZtesting' position ^ super position. position: aPoint super position: aPoint. This looks better. I you really want to replace the EllipseMorph>position you must go deeper into how the EllipseMorph handles its position and bounds . This will not be trivial. Much easier to invent a new instance variable and use it in the drawOn: method. Good luck with your apprenticeship On 05.02.2015 11:56, nacho wrote: > @Trygve > I've checked and it doesn't work. I can't even bring the halo on to delete > the morph. The debugger keeps popping. > Thanks anyway to all > Nacho > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/Question-on-Morphic-drawOn-method-tp4803695p4803895.h… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > -- /The essence of object orientation is that objects collaborateto achieve a goal. / Trygve Reenskaug mailto: trygver(a)ifi.uio.no <mailto:%20trygver@ifi.uio.no> Morgedalsvn. 5A http://folk.uio.no/trygver/ N-0378 Oslo http://fullOO.info Norway Tel: (+47) 22 49 57 27

Feb. 5, 2015

Re: [Pharo-users] Canvas Transform Goes Haywire if Scaled

by Sean P. DeNigris

Thank you Werner and Nicolai! You were both right :) The transform offset needed to be scaled and the clipping needed to be both translated and scaled, too. The final code was: morph := Morph new topLeft: 200@400; openInWorld. outputRect := morph fullBounds. scale := 0.2. canvas := Display defaultCanvasClass extent: outputRect extent * scale depth: Display depth. t := MorphicTransform offset: outputRect topLeft * scale angle: 0 scale: scale. "*** must scale offset" clipRect := (outputRect translateBy: outputRect topLeft negated) scaleBy: scale. "*** must translate and scale clip rect" canvas transformBy: t clippingTo: clipRect during: [ :aCanvas | aCanvas fullDrawMorph: morph ]. This seems so complicated. I would naively think that the API should do much of this for you. For example, why doesn't it know that when there's an offset AND a scale, the transform's offset should be adjusted by the scale? canvas form asMorph openInWindow. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Canvas-Transform-Goes-Haywire-if-Scaled-tp4803830p480… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 5, 2015

Re: [Pharo-users] Spotter: How to see more beyond #/##

by Tudor Girba

Hi, Yes. As Alex said, we want all actions to have a visual representation. This is on our todo list. As for configurability, there is no grand plan at the moment. We could indeed expose shortcuts as settings. Cheers, Doru On Thu, Feb 5, 2015 at 1:32 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > kilon.alios wrote > > because right controls the search input box cursor > > > > On Thu, Feb 5, 2015 at 12:00 PM, Guillermo Polito < > > > guillermopolito@ > > > > wrote: > >> Maybe I'm not getting it but, Why not just using "Right"? > > Ha ha ha, I was thinking the same thing! But it seems obvious now. I think > discoverability + "mouse click on the 5/26 line" (with maybe some kind of > icon inviting a click) would help a lot. > > Regarding shortcuts in general, what is the status of the dream we had when > we starting investigating keymapping and friends years ago - "let users > totally customize shortcuts"? While it's good to have a reasonable default, > no hardcoded solution will make everyone happy... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Spotter-How-to-see-more-beyond-tp4803696p4803921.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 5, 2015