February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] what is the goal of warpImage: aForm transform:aTransform

by Gary Chambers

This appears to haved been used by KedamaMorph in Squeak for scaling (rather than using an intermediate Form). Probably worth keeping though... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, February 10, 2011 6:49 AM Subject: Re: [Pharo-project] what is the goal of warpImage: aForm transform:aTransform strange because I can rotate windows and other and still me method has no sender... so this should be for something else. On Feb 9, 2011, at 7:54 PM, Igor Stasenko wrote: > i guess it is related to warpBlt engine, > which can zoom/rotate forms when blitting and do other distortions.. > > > On 9 February 2011 17:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: >> there are no sender in Pharo 1.3? >> SMx does not have them. >> >> Stef >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 11, 2011

Re: [Pharo-project] about fillRectangle: aRectangle fillStyle:aFillStyle

by Gary Chambers

The reason was that Squeak had (differing) implementations in each class before I introduced the double-dispatch. Since Polymorph was a loadable package, they needed to be overridden. In Pharo they can, of course, be removed to just leave the Canvas one. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, February 10, 2011 6:43 AM Subject: Re: [Pharo-project] about fillRectangle: aRectangle fillStyle:aFillStyle Igor I saw that this was a double dispatch but I imagine that this is not needed to duplicate the exact same code within the same hierarchy. Can you have a look? I will prepare a cs or a slice with all my changes and it would be great to have somebody else having a look. Stef > it seems duplicated in >> pluggableCanvas, canvas and balloonCanvas >> >> fillRectangle: aRectangle fillStyle: aFillStyle >> "Fill the given rectangle. Double-dispatched via the fill style." >> >> aFillStyle fillRectangle: aRectangle on: self >> >> >> do you confirm that? >> >> > > it is a bit tricky. The #fillRectange:fillStyle: is a double-dispatch > entry > actually one could use: > > aFillStyle fillRectangle: aRectangle on: self > > See a CompositeFillStyle how it works. > > The idea was to replace all uses of #doSomething: x color: y > or #doSomething:border:colorA:colorB: > > with #doSomething: x fillStyle: y... > > Actually all painting operations could take only two objects: shape > and fill style. > > So, in this respect, a color property of Morph should be a fill style, > since color can be described as 'solid fill with single color' fill > style, > a most simplest possible one. > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 11, 2011

Re: [Pharo-project] handlerForBlueButtonDown: anEvent

by Gary Chambers

The change I made (compared to Squeak) was to check the preferences for whether halos were enabled... not sure when the commented bit happened, for reference the Squeak version (with Polymorph) was: Preferences halosEnabled ifFalse: [^nil]. self wantsHaloFromClick ifFalse:[^nil]. anEvent handler ifNil:[^self]. anEvent handler isPlayfieldLike ifTrue:[^self]. "by default exclude playfields" (anEvent shiftPressed) ifFalse:[^nil] "let outer guy have it" ifTrue:[^self] "let me have it" So, the nil check was for when the handler was being checked for playfields (guess EToys). Perhaps the check for halos enabled should be reintroduced (via Settings) unless handled elsewhere, as the comment says, useful for deployed applications. Regards, Gary ----- Original Message ----- From: "stephane ducasse" <stephane.ducasse(a)free.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, February 09, 2011 5:07 PM Subject: [Pharo-project] handlerForBlueButtonDown: anEvent Gary I was wondering if "anEvent handler ifNil:[^self]." should not be uncommented in. Now if it works like that this is better since it means that are not hanging around with a nil. Stef handlerForBlueButtonDown: anEvent "Return the (prospective) handler for a mouse down event. The handler is temporarily installed and can be used for morphs further down the hierarchy to negotiate whether the inner or the outer morph should finally handle the event. Note: Halos handle blue button events themselves so we will only be asked if there is currently no halo on top of us. Check whtehr halods are enabled (for deployment)." self wantsHaloFromClick ifFalse:[^nil]. "anEvent handler ifNil:[^self]." (anEvent shiftPressed) ifFalse:[^nil] "let outer guy have it" ifTrue:[^self] "let me have it"

Feb. 11, 2011

Re: [Pharo-project] Issue 3546 in pharo: Have a look at SystemReporter

by pharo＠googlecode.com

Comment #3 on issue 3546 by l...(a)blobworks.com: Have a look at SystemReporter http://code.google.com/p/pharo/issues/detail?id=3546 So what should i use to check if it's working? 1.1.1, 1.2, 1.3 ??

Feb. 11, 2011

Re: [Pharo-project] A new GUI visual designer

by Tobias Pape

Hi all Am 2011-02-11 um 09:58 schrieb StÃ©phane Ducasse: > Hi geert > > The problem is not simply the license. The problem is: > - integrating widgets > - integrating extra libraries > > We cannot stack libraries. > So there is an engineering effort needed. > I do not understand that. Can you elaborate? So Long -Tobias

Feb. 11, 2011

Re: [Pharo-project] A tinyBenchmark

by Igor Stasenko

On 11 February 2011 02:52, Levente Uzonyi <leves(a)elte.hu> wrote: > On Fri, 11 Feb 2011, Igor Stasenko wrote: > >> so much noise for so insignificant smoke test. >> I'd rather prefer seeing Cog doing copy-down compiled method, at least >> for most simple cases - self sends :) > > Do you mean inlining? > > yes > Levente > >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 11, 2011

Re: [Pharo-project] A new GUI visual designer

by StÃ©phane Ducasse

Hi geert The problem is not simply the license. The problem is: - integrating widgets - integrating extra libraries We cannot stack libraries. So there is an engineering effort needed. Stef > > > StÃ©phane Ducasse wrote: >> >> @Tobias: Hi, what is the license because the wiki does not say it or I >> could not find it. >> > > I reckon the GUI designer would be a nice addition to Pharo? Did you end up > hearing from Tobias about the license? > -- > View this message in context: http://forum.world.st/A-new-GUI-visual-designer-tp3067111p3300892.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 11, 2011

Re: [Pharo-project] Issue 3546 in pharo: Have a look at SystemReporter

by pharo＠googlecode.com

Comment #2 on issue 3546 by l...(a)blobworks.com: Have a look at SystemReporter http://code.google.com/p/pharo/issues/detail?id=3546 The latest version will not work in pharo. I will see how to make it more pharo friendly.

Feb. 11, 2011

Re: [Pharo-project] SqueakSource down?

by Tudor Girba

It all looks fine now. Doru On 11 Feb 2011, at 08:59, Fabrizio Perin wrote: > No is the internet connection of university of bern that is down!!! > > Fabrizio > > > > 2011/2/11 Alexander LazareviÄ <laza(a)blobworks.com> > http://www.downforeveryoneorjustme.com/www.squeaksource.com > -- www.tudorgirba.com "Speaking louder won't make the point worthier."

Feb. 11, 2011

Re: [Pharo-project] [Hudson] updates

by Sven Van Caekenberghe

On 11 Feb 2011, at 08:09, StÃ©phane Ducasse wrote: > marcus we should add Zinc as project to be built :) Well, that would be nice indeed. Zn is already part of Lukas' CI server, http://hudson.lukas-renggli.ch/job/Zinc/ , but that's Pharo 1.1.x if I am not mistaken, so Pharo(Core) 1.2 and/or 1.3 builds would be good. Zn does not have any dependencies, it runs on core as well. It can be seen as a networking level test. Regards, Sven

Feb. 11, 2011