- Pharo-dev - lists.pharo.org

[update 3.0] #30198

by Marcus Denker

30198 ----- 6989 Inspect should be silent https://pharo.fogbugz.com/f/cases/6989 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1140.diff

June 13, 2013

Re: [Pharo-dev] straaannnnge code in SystemWindow>>addMorph:fullFrame:

by S Krish

* | m |* * m := AlignmentMorph new.* * * "create / put all morphs internal in this morph with their composition as required" * * * m layoutFrame: self panelWindowLayoutFrame. * * m hResizing: #spaceFill; vResizing: #spaceFill. * * primaryWindow addMorph: m . * "Create the layout spec viz LayoutFrame fractions: ( 0@0 corner: 1@1) offsets: ( 4@4 corner: -4 @ -4)." "primaryWindow can be SystemWindow new or any others from StandardWindow, Morph, PluggableDialogWindow et als: On Thu, Jun 13, 2013 at 6:01 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Further, the current SystemWindow>>addMorph:fullFrame: assumes thick > borders between components, for pane splitters. There used to be an > accessor on SystemWindow, allowPaneSplitters:, that could be used to > discard pane splitters and their thick borders, but this was ditched. > > So if I want a window containing lots of morphs with no splitters and no > thick borders how do I do it? > > a) Should I use a container morph and add this to the SystemWindow? > > b) should I add an override to SystemWindow that does what > addMorph:fullFrame: (or addMorph:frame:) does without adding the thick > borders? > > c) should I add back the allowPaneSplitters[:] accessor and modify > SystemWindow>>addMorph:fullFrame: to take account of allowPaneSplitters == > false? > > a) seems the right approach, but when I use either a Morph or a > BorderedMorph as my container I don't get things laid out correctly in that > morph. Is there a standard container morph that does layout correctly? If > so, what is it? > > c) is easy to do, but folks have to maintain it (it's no more than a guard > around all the frae manipulation in addMorph:fullFrame:). > > >

June 13, 2013

Re: [Pharo-dev] straaannnnge code in SystemWindow>>addMorph:fullFrame:

by Eliot Miranda

Further, the current SystemWindow>>addMorph:fullFrame: assumes thick borders between components, for pane splitters. There used to be an accessor on SystemWindow, allowPaneSplitters:, that could be used to discard pane splitters and their thick borders, but this was ditched. So if I want a window containing lots of morphs with no splitters and no thick borders how do I do it? a) Should I use a container morph and add this to the SystemWindow? b) should I add an override to SystemWindow that does what addMorph:fullFrame: (or addMorph:frame:) does without adding the thick borders? c) should I add back the allowPaneSplitters[:] accessor and modify SystemWindow>>addMorph:fullFrame: to take account of allowPaneSplitters == false? a) seems the right approach, but when I use either a Morph or a BorderedMorph as my container I don't get things laid out correctly in that morph. Is there a standard container morph that does layout correctly? If so, what is it? c) is easy to do, but folks have to maintain it (it's no more than a guard around all the frae manipulation in addMorph:fullFrame:). On Wed, Jun 12, 2013 at 3:23 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Wed, Jun 12, 2013 at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi All, >> >> in SystemWindow>>addMorph:fullFrame: towards the bottom are the lines: >> >> aMorph adoptPaneColor: self paneColor. >> aMorph borderWidth: 1; borderColor: Color lightGray; color: Color white. >> >> I'm adding a UpdatingThreePhaseButtonMorph checkBox to my window so, via >> ImageMorph>>colors: >> >> ImageMorph>>color: aColor >> super color: aColor. >> (image depth = 1 and: [aColor isColor]) ifTrue: [ >> image colors: {Color transparent. aColor}. >> self changed] >> >> this has the effect of completely smashing the checkBox's normal image, >> and setting to white ScriptingSystem formAtKey: #CheckBoxOn, which is what >> the checkBox uses as its default image. >> >> What business does SystemWindow have of smashing the colour of any morph >> added to it? Surely this is bogus, no? >> > > I see the regression. Back in 3.9 the method read > > (aMorph isKindOf: ImageMorph) ifFalse:[ > aMorph adoptPaneColor: self paneColor. > aMorph borderWidth: 2; borderColor: #inset; color: Color transparent] > > Unless anyone objects I'll put back this guard. it seems obviously > correct (or rather, obviously less broken; the method also includes this > priceless gem: > (aMorph class name = #BrowserCommentTextMorph) ifTrue: > [aLayoutFrame rightOffset: windowBorderWidth negated. > aLayoutFrame leftOffset: windowBorderWidth. > aLayoutFrame bottomOffset: windowBorderWidth negated. > aLayoutFrame topOffset: (windowBorderWidth negated) + 4]. > ). > > -- >> best, >> Eliot >> > > > > -- > best, > Eliot > -- best, Eliot

June 13, 2013

Re: [Pharo-dev] straaannnnge code in SystemWindow>>addMorph:fullFrame:

by Eliot Miranda

On Wed, Jun 12, 2013 at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi All, > > in SystemWindow>>addMorph:fullFrame: towards the bottom are the lines: > > aMorph adoptPaneColor: self paneColor. > aMorph borderWidth: 1; borderColor: Color lightGray; color: Color white. > > I'm adding a UpdatingThreePhaseButtonMorph checkBox to my window so, via > ImageMorph>>colors: > > ImageMorph>>color: aColor > super color: aColor. > (image depth = 1 and: [aColor isColor]) ifTrue: [ > image colors: {Color transparent. aColor}. > self changed] > > this has the effect of completely smashing the checkBox's normal image, > and setting to white ScriptingSystem formAtKey: #CheckBoxOn, which is what > the checkBox uses as its default image. > > What business does SystemWindow have of smashing the colour of any morph > added to it? Surely this is bogus, no? > I see the regression. Back in 3.9 the method read (aMorph isKindOf: ImageMorph) ifFalse:[ aMorph adoptPaneColor: self paneColor. aMorph borderWidth: 2; borderColor: #inset; color: Color transparent] Unless anyone objects I'll put back this guard. it seems obviously correct (or rather, obviously less broken; the method also includes this priceless gem: (aMorph class name = #BrowserCommentTextMorph) ifTrue: [aLayoutFrame rightOffset: windowBorderWidth negated. aLayoutFrame leftOffset: windowBorderWidth. aLayoutFrame bottomOffset: windowBorderWidth negated. aLayoutFrame topOffset: (windowBorderWidth negated) + 4]. ). -- > best, > Eliot > -- best, Eliot

June 12, 2013

GetText on Pharo 2.0

by Usman Bhatti

Hello, I worked a bit on GetText package for internationalization in Pharo to make it 2.0 comptable. So, I was able to make it work by adapting it to changes in FileSystem and SmalltalkImage class. Now, I need to commit it to test. I still need to see - if its initiated properly on startup; - tutorial here<http://book.pharo-project.org/book/LanguageAndLibraries/Localisation/Instal…> is working with the new changes; - create some tests. I'll access rights on PharoExtras/Gettext to commit my changes. regards, Usman

June 12, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. Zinc.Tests.ZnClientTests.testHeadSmallHTML

June 12, 2013

Re: [Pharo-dev] Monetary package

by Paul DeBruicker

Paul DeBruicker wrote > I'll move it to Smalltalkhub later now. I mean now. Its here: http://smalltalkhub.com/#!/~pdebruic/Money -- View this message in context: http://forum.world.st/Pharo-dev-Monetary-package-tp4692670p4693062.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2013

[update 3.0] #30197

by Marcus Denker

June 12, 2013

Re: [Pharo-dev] Monetary package

by Paul DeBruicker

For anybody who cares it originally comes from last chapter of Smalltalk Best Practices Patterns by Kent Beck and was uploaded by Avi Bryant. I've been decreasing the code quality for a little while. ;) I'll move it to Smalltalkhub later now. Sven Van Caekenberghe-2 wrote > Hi Torsten, > > On 10 Jun 2013, at 19:09, "Torsten Bergmann" < > astares@ > > wrote: > >> Do we have a "money" package for Pharo available? >> >> http://www.jarober.com/blog/blogView?showComments=true&title=ST+4U+396%3A+M… > > http://www.squeaksource.com/Money.html > > Paul DeBruicker ported it to Pharo. > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org -- View this message in context: http://forum.world.st/Pharo-dev-Monetary-package-tp4692670p4693053.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2013

Re: [Pharo-dev] Cairo vs openGL

by kilon

Yeap Igor already knew all that when I first visited the website awhile ago. My only concern is how much time will it take to make this work under opengl. If it take less than 60 hours of effort , sure I could do that, if it would take more than that then I am afraid Vector graphics is not such a big deal for me to justifying investing that amount of time. 3d graphics is my focus. But anyway as I said, that is something I will deal with after I have sufficient knowledge of the basics of opengl and finish the NBOpengl tutorial classes. -- View this message in context: http://forum.world.st/Pharo-dev-Cairo-vs-openGL-tp4692947p4693051.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2013