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

Nautilus and Traits

by Torsten Bergmann

Hi, in Nautilus there is a menu "Analyze" -> "Class refs..." to see where a class is used. When I select a trait it is not displayed in the menu, but CMD+N is also working when I select a Traits name in the code pane. Is it by intention to not browse refs for traits or a bug in the menu? How can one browse the classes that "use" a trait? Looks like there is no option for that yet. (for instance to browse and see that "TBehavior" is used in "Behavior") Thx T.

Jan. 3, 2014

Re: [Pharo-dev] printString and asString

by Tudor Girba

+1. In all tools I wrote, I felt the need for some sort of #displayString, and sooner or later I introduced it in some form. Doru On Fri, Jan 3, 2014 at 1:39 PM, Carlo <snoobabk(a)gmail.com> wrote: > To me #asString is meant to be used when you need an object with the > String protocol. > As mentioned it looks like the seaside #asString and #greaseString are > meant for displaying which causes the confusion but Iâm not sure why > #displayString was removed apart from the obvious reasons of trying to > cater for common denominator across Smalltalk dialects. > > In my codebases I also tend to use #asString for displaying but have tried > to move to a #displayString and #displayOn: protocol for these purposes. > > Regards > Carlo > > > On 03 Jan 2014, at 1:24 PM, Otto Behrens <otto(a)finworks.biz> wrote: > > > #printString and #printOn: protocol should be used for printing and > #asString for conversion. This implies that #asString should not depend on > #print protocol. > > Ah, I used it the other way around: printOn depends on asString. I saw > 'conversion' as the lower level. > > Why do you distinguish here between conversion and 'printing'? > Especially if displayString is being replaced with asString - to me > that sounds against your thinking in principle. > > > If we are going to use #asString to mimic #displayString (instead of as > a conversion method) then to me #asString should be viewed at a higher > level abstraction than #printOn:. If not then we can run into these issues > when calling the higher-level abstraction from a lower level in the same > objectt, as you mentioned. Calling #printString from #asString from an API > perspective should not cause issues (as displaying something is very > different from converting something) so Iâd say this is an API design > problem. > > Yes, I think the API could be clearer. So this becomes the essence of > the question here: What is the meaning of these methods from an API > perspective? > > Thanks for the response > > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 3, 2014

Re: [Pharo-dev] DateModel label width

by Benjamin

I think we can do better :P (with still a workaround) Let me digest my jet lag (just arrived at Santiago) and I will give you a real answer :P Ben On 02 Jan 2014, at 20:16, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Benjamin Van Ryseghem-2 wrote >> A dirty patch in the meantime would be to specify the policy to the morph >> when built. > > A workaround would be fine for the moment. Were you suggesting a mess ( ;-) > ) like the following? â¦ > > open > > | windowModel paperworkDateWidget labelWidget | > windowModel := self new openWithSpec. > paperworkDateWidget := windowModel window submorphs last firstSubmorph > submorphs seventh firstSubmorph firstSubmorph. > paperworkDateWidget > hResizing: #spaceFill; > changeTableLayout; > listDirection: #rightToLeft. > labelWidget := paperworkDateWidget submorphs second. > labelWidget > hResizing: #shrinkWrap. > labelWidget width: 155. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/DateModel-label-width-tp4733674p4733757.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Jan. 3, 2014

Re: [Pharo-dev] printString and asString

by Otto Behrens

> #printString is used for debugging, that's why the default > implementation shows the class name. It's implemented using #printOn: Makes sense. So unless there's a nice symbol that one can add to show what it is (eg #foo printString = '#foo'), implementors of printOn: should call super printOn:, yes? In Pharo, this seems to be the general idea. But then printString should not be used (generally) as the mechanism to display something to for a user, right? As this would show something like 'a Person Otto' to the user. Some implementors of printOn: could be renamed to storeOn: In GemStone, the default implementation of asString is to show the class name. > #displayString (deprecated in Pharo*) is used to display the object in > the UI. It is implemented by means of #displayOn: (Dolphin used this > pattern) So we don't have this in Pharo anymore. Looks like it is mostly asString now. But then, really, Object asString ^ self printString does not make sense? > #asString is the toString() equivalent of other languages. In some > cases `anObject asString asObject` should give the same object back > (e.g. in Date, Numbers, etc.). Most of the times it is the same string > as #printString, but it is not consistent. The intention of #storeString implemented via #storeOn: is to do that: (Compiler evaluate: anObject storeString) = anObject. Probably not completely true for really complex objects... > Ej: > If you have aPerson: > aPerson printString -> "aPerson ('John Doe')" > aPerson displayString -> 'John Doe' Ok, since displayString is gone, is it: aPerson asString -> 'John Doe' aPerson storeString -> "Person name: 'John Doe'" Which means that by default, both printString and storeString can call asString, and asString is the 'lowest level'?

Jan. 3, 2014

Re: [Pharo-dev] stroke width in Athens

by Alexandre Bergel

Very true! looks like to be the thing. Thanks! Alexandre On Jan 3, 2014, at 11:12 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 03 Jan 2014, at 1:58 , Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> Hi! >> >> Apparently, the width (in pixels) of a stroke in athens seems to vary with the size of the path. Am I right? >> >> For example, I have the following rendering: >> >> <Screen Shot 2014-01-03 at 9.54.29 AM.png> >> >> There is just one code to draw a box, which is: >> >> athensCanvas pathTransform restoreAfter: [ >> athensCanvas pathTransform >> translateBy: rectangle center; >> scaleBy: rectangle extent / 2. >> >> athensCanvas >> setPaint: color; >> drawShape: self path. >> >> strokePaint ifNotNil: >> [ (athensCanvas >> setStrokePaint: strokePaint) width: 0.1. >> athensCanvas drawShape: path ] >> ] >> >> Having a width of 1 makes a very large border. >> Do I miss something? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > Well yes, you are using scaleBy:. > That scaling applies to the stroke width of the path as well, Iâd imagine... > > Cheers, > Henry -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 3, 2014

Re: [Pharo-dev] Pharo3 issues

by Tudor Girba

Oops :) Doru On Fri, Jan 3, 2014 at 3:04 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Doru wrote: > > Hmm, strange. It was available in 30666, but it is not available anymore > in 30669. > > > > Was it reverted because it was not good, or was it because of another > issue? > > It was never there. Did you by change load the slice in your 30666? > > Stephan > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 3, 2014

Lost changes recovery

by Lorenzo Schiavina

Hi, I tried to recover lost changes but I failed. I used the item in tools menu and I followed the expected actions, but I was not able to find the lost changes in my image; where do they go? Is there any place where I can find details about the expected results and understand what I missed? Thanks Lorenzo

Jan. 3, 2014

Re: [Pharo-dev] stroke width in Athens

by Henrik Johansen

On 03 Jan 2014, at 1:58 , Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Apparently, the width (in pixels) of a stroke in athens seems to vary with the size of the path. Am I right? > > For example, I have the following rendering: > > <Screen Shot 2014-01-03 at 9.54.29 AM.png> > > There is just one code to draw a box, which is: > > athensCanvas pathTransform restoreAfter: [ > athensCanvas pathTransform > translateBy: rectangle center; > scaleBy: rectangle extent / 2. > > athensCanvas > setPaint: color; > drawShape: self path. > > strokePaint ifNotNil: > [ (athensCanvas > setStrokePaint: strokePaint) width: 0.1. > athensCanvas drawShape: path ] > ] > > Having a width of 1 makes a very large border. > Do I miss something? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > Well yes, you are using scaleBy:. That scaling applies to the stroke width of the path as well, Iâd imagine... Cheers, Henry

Jan. 3, 2014

CI server builds

by Diego Lont

Hi all, Currently I build my QCMagritte only for Pharo 2.0, loading version 3.0.9 of Seaside. I should probably extend this to build both for Seaside 3.1 and Pharo 3.0, but here I run into trouble. The version with Seaside 3.0.9 won't work on Pharo 3. So if I make this matrix, I will get one failing build. How can I solve this? I can abuse the symbolic versions of course, but as you can read in my sentence: I do not think this is a good solution. I want to be able to tell jenkins not to build the entire matrix. Is there an easy solution for this? Cheers, Diego

Jan. 3, 2014

Re: [Pharo-dev] Pharo3 issues

by Stephan Eggermont

Doru wrote: > Hmm, strange. It was available in 30666, but it is not available anymore in 30669. > > Was it reverted because it was not good, or was it because of another issue? It was never there. Did you by change load the slice in your 30666? Stephan

Jan. 3, 2014