April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] how to completely ignore mouse wheel events?

by pharo4Stef＠free.fr

> I have modified the following methods > HandMorph>>generateKeyboardEvent: evtBuf > ScrollPane>>scrollByKeyboard: event > > The effect is now milder. > > Esteban, would it make sense to remove the event generation bu the VM? This works only for the old-style mouse with an actual wheel. Mighty mouse does not work at all with Pharo. > > We have to get this right. Emulation of events is a bad idea. yes but we have to have time and money for that :) If fernando would not have left like a thief it was on his roadmap. Stef > > Alexandre > >

April 17, 2014

Re: [Pharo-dev] 13204 Hard to see Morph halo label

by pharo4Stef＠free.fr

why do we need a special class for that? Why not just a StringMorph with correct background? On 17/4/14 16:20, Ben Coman wrote: > Build 30507 integrated slice 11492 "Kill UpdatingStringMorph, > UpdatingMenu, and NameInHaloMorph" > that removed class UpdatingStringMorph its subclass NameInHaloMorph. > As a consequence the halo "morph label" > became hard to read. Compare the red circled areas in the snapshots > from build. > > > > Technically its pretty easy fix. Restoring just the #drawOn: part of > NameStringInHalo (now subclassed from StringMorph) solves the problem > as follows... > Adding... > StringMorph subclass: #NameStringInHalo > instanceVariableNames: '' > classVariableNames: '' > category: 'Morphic-Base-Widgets' > > NameStringInHalo>>drawOn: aCanvas > aCanvas fillRectangle: self bounds color: Color white. > super drawOn: aCanvas. > > and modify the following line in HaloMorph>>addNameBeneath:string: ... > nameMorph := StringMorph contents: aString font: StandardFonts > haloFont. > to.. > nameMorph := NameStringInHalo contents: aString font: > StandardFonts haloFont. > > However I'm seeking a broader picture to understand if that is the > right way to proceed... > 1. Was NameStringInHalo particularly undesired or was it more a > consequence of UpdatingStringMorph being removed ? > > 2. Should the same class name "NameStringInHalo" be used having a > different superclass than before. Actually as I write that I am > thinking this creates an unnecessary clash with Squeak and derivatives > that still have NameStringInHalo, and so... > > 3. Any suggestions for another more generic class name? > SolidStringMorph, OpaqueStringMorph, etc > > 4. Any suggestions for another way for a StringMorph to have a solid > background? > > cheers -ben

April 17, 2014

Re: [Pharo-dev] [Seaside] Question about Oauth

by Sven Van Caekenberghe

There is a Seaside example (look in the repository) and even a live demo: http://sso.doit.st On 17 Apr 2014, at 21:37, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi, > > Sorry for the multiple list mail. > > I am analyzing the possibility to implement a API that requires OAuth. I have been reading this link from Sven: https://github.com/svenvc/docs/blob/master/zinc/zinc-sso-paper.md and I have a few questions: > > 1) I get lost in the #handleOAuth1Callback: part. I understand I need to provide to oauth a callback url so that this is call once the user has logged in. The thing is that Sven demo seems to be using a (RESTfull) server directly. In my case, this is a Seaside app. So...how should I do this? I guess I could create a WAComponent but then I should use Seaside rest or something? Because I need to map that url to the component (and implement handleRequest: in the component?). Is there another way? > > 2) #loginUrlFor: seems to only set 'oauth_token' however, my protocol says the url should be: https://whatever/authorize?key={oauth_consumer_key}&token={oauth_token} > would that still work or I should adapt it? > > 3) Does anyone tested the mention code/repository in GemStone? > > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

April 17, 2014

Re: [Pharo-dev] Closure vs BlockClosure

by pharo4Stef＠free.fr

> abergel wrote >> Wellâ¦ the whole community of programming language call a closure a >> closure. Calling a block what is actually a closure may not be a >> well-marketed move in my opinion. > Given that Smalltalkers consider it a block and outsiders would understand > the closure part, maybe it is well-named as it is, as it is an obvious link > of these two terms. :) and do not expect us to change the name. We have a lot of other important things to do than to break for the sake of breaking the system. Stef > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Closure-vs-BlockClosure-tp4755091p4755104.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 17, 2014

Re: [Pharo-dev] Condense changes

by Sven Van Caekenberghe

On 17 Apr 2014, at 21:13, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > I tried the new version: > > PharoChangesCondenser condense. -> parse error I tried recently and it just worked. > Do we open a new bug? Yes > Is there another way that I missed? > > Do you agree that we should remove condenseChanges from SmalltalkImage? Maybe not just yet ;-)

April 17, 2014

Re: [Pharo-dev] IMPORTANT: Looking for names of contributors for Pharo 3

by pharo4Stef＠free.fr

yes it does On 17/4/14 10:49, Stephan Eggermont wrote: > Esteban wrote: >> Iâm collecting the names of those who contributed code for Pharo 3. > If that includes making configurations work in Pharo 3, you definitely miss > Diego Lont. > > Stephan >

April 17, 2014

Re: [Pharo-dev] InfiniteForm

by pharo4Stef＠free.fr

thanks igor I was thinking about that too but I thought that it could not be that simple :) On 17/4/14 02:20, Igor Stasenko wrote: > > > > On 15 April 2014 23:15, pharo4Stef(a)free.fr <mailto:pharo4Stef@free.fr> > <pharo4Stef(a)free.fr <mailto:pharo4Stef@free.fr>> wrote: > > There a plenty of isKindOf: InfiniteForm in the system and I was > trying to understand how we could get rid of them. > How other systems handle pattern based color filling shape? > > why bother? > > Just use The God's Hammer Dispatch (AKA Non-intuitive way of programming > for those who don't think in objects ;) : > > fillRectangle: aRectangle basicFillStyle: aFillStyle > "Fill the given rectangle with the given, non-composite, fill style." > > | pattern | > > (aFillStyle isKindOf: InfiniteForm) ifTrue: [ > ^self infiniteFillRectangle: aRectangle fillStyle: aFillStyle > ]. > > > => > > fillRectangle: aRectangle basicFillStyle: aFillStyle > "Fill the given rectangle with the given, non-composite, fill style." > ^ aFillStyle fillRectangle: aRectangle onCanvas: self > > > ..and then after refactoring it will look exactly how Athens doing it, > because if you rename fill style with "paint" and rectangle with > "shape" you will see it :) > > > Stef > > > > > -- > Best regards, > Igor Stasenko.

April 17, 2014

Question about Oauth

by Mariano Martinez Peck

Hi, Sorry for the multiple list mail. I am analyzing the possibility to implement a API that requires OAuth. I have been reading this link from Sven: https://github.com/svenvc/docs/blob/master/zinc/zinc-sso-paper.md and I have a few questions: 1) I get lost in the #handleOAuth1Callback: part. I understand I need to provide to oauth a callback url so that this is call once the user has logged in. The thing is that Sven demo seems to be using a (RESTfull) server directly. In my case, this is a Seaside app. So...how should I do this? I guess I could create a WAComponent but then I should use Seaside rest or something? Because I need to map that url to the component (and implement handleRequest: in the component?). Is there another way? 2) #loginUrlFor: seems to only set 'oauth_token' however, my protocol says the url should be: https://whatever/authorize?key={oauth_consumer_key}&token={oauth_token} would that still work or I should adapt it? 3) Does anyone tested the mention code/repository in GemStone? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

April 17, 2014

Re: [Pharo-dev] IMPORTANT: Looking for names of contributors for Pharo 3

by pharo4Stef＠free.fr

On 16/4/14 16:12, Esteban Lorenzano wrote: > everything counts, there is no such thing as a âsmall fixâ :) + 1 > > Esteban > > On 16 Apr 2014, at 16:02, Sergi Reyner <sergi.reyner(a)gmail.com > <mailto:sergi.reyner@gmail.com>> wrote: > >> I did contribute some code for SpecÂ´s ImageModel, if that counts :D >> >> Cheers, >> Sergi >> >> >> 2014-04-16 13:59 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com >> <mailto:estebanlm@gmail.com>>: >> >> oops, fixed :) >> >> On 16 Apr 2014, at 14:51, Norbert Hartl <norbert(a)hartl.name >> <mailto:norbert@hartl.name>> wrote: >> >> > Mine is there but spelled wrongly. >> > >> > Norbert >> > >> > Am 16.04.2014 um 14:24 schrieb Esteban Lorenzano >> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> > >> >> Hi guys, >> >> >> >> Iâm collecting the names of those who contributed code for >> Pharo 3. >> >> I made my own list, but is almost made by memory, so Iâm sure >> Iâm forgetting MANY names. So, pleaseâ¦ look yourself in the list >> and if you are not there, reply adding it. >> >> (btwâ¦ Kilon, I know you contributed, is just that I donât know >> your real name :P) >> >> >> >> Jean Baptiste Arnaud >> >> Philippe Back >> >> ClÃ©ment Bera >> >> Alexandre Bergel >> >> Camillo Bruni >> >> Sven Van Caekenberghe >> >> Damien Cassou >> >> Nicolas Cellier >> >> Ben Coman >> >> Gisela Decuzzi >> >> Christophe Demarey >> >> Sean DeNigris >> >> Marcus Denker >> >> Martin Dias >> >> Stephane Ducasse >> >> Stephan Eggermont >> >> Luc Fabresse >> >> Hilaire Fernandes >> >> Tudor Girba >> >> Thierry Goubier >> >> Norbert Harlt >> >> Nicolai Hess >> >> Andre Hora >> >> Pavel Krivanek >> >> Jannik Laval >> >> Max Leske >> >> David Lewis >> >> Esteban Lorenzano >> >> Stefan Marr >> >> Mariano Martinez Peck >> >> Eliot Miranda >> >> Nicolas Petton >> >> Alain Plantec >> >> Guillermo Polito >> >> Damien Pollet >> >> Camille Teruel >> >> Benjamin Van Ryseghem >> >> Frank Shearar >> >> Igor Stasenko >> >> Sebastian Tleye >> >> Yuriy Tymchuk >> >> >> >> Thanks, >> >> Esteban >> > >> > >> >> >> >

April 17, 2014

Condense changes

by Luc Fabresse

hi all, In a fresh image #30826, I tried: Smalltalk image condenseChanges -> ZnInvalidUTF8 error https://pharo.fogbugz.com/default.asp?12729& describes that but it is closed. I tried the new version: PharoChangesCondenser condense. -> parse error Do we open a new bug? Is there another way that I missed? Do you agree that we should remove condenseChanges from SmalltalkImage? Cheers, #Luc

April 17, 2014