June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [BUG]: Extension Methods Missing from Packages

by Goubier Thierry

However, if you write the extension category as *announcements-core, then the bug you describe does not happen. (Note: with my AltBrowser, you don't write the '*announcements-core' category, you drag the new method on the extension part of the Announcements-Core package, and the right protocol will be created for you) I think that overall we have a conflict with overlapping names in packages (a package with subcategories or: two packages, the first one with as name the prefix of another packages name) and I'd like a decisive resolution on that. In short, when you write *announcements-core-subcategory, to you want it to be: 1)a subcategory of *announcements-core, or 2)for a package named announcements-core-subcategory, 3)or a subcategory of announcements ? (I guess you want 1), and the system 2), but your change may result in 3) I like it that this code rely on category:matches: whose code is repeated four times in my 2.0 image: PackageInfo>>category:matches: RGContainer>>category:matches: RPackage>>category:matches: RPackageOrganizer>>category:matches: Thierry Le 11/06/2013 21:11, Sean P. DeNigris a Ã©crit : > This is a nasty one. It may lead to lost code, without warning or > notification. Applies to latest 2.0 and 3.0: > 1. In Nautilus, in any class outside Announcements-Core, add protocol > '*announcements-core-subcategory' > 2. Open MCWrokingCopyBrowser. You will see that Announcements-Core is dirty > 3. Click the "Changes" button > > It will say that there are no changes, and the package will be unmarked as > dirty. This is because 'announcements-core-subcategory' was created as a > separate RPackage and stole the extension method. > > For 3.0, > https://pharo.fogbugz.com/f/cases/10887/Compound-Extension-Methods-Unpackag… > >> Fix in inbox: >> SLICE-Issue-10887-Compound-Extension-Methods-Unpackaged-SeanDeNigris.1 >> >> Case 10887: Compound Extension Methods Unpackaged >> >> * Fix RPackageOrganizer>>checkPackageExistsOrRegister:, which is sent when >> a class organization changes, to see if extension methods have been added >> * Add test which fails before fix and passes after > > For 2.0, > https://pharo.fogbugz.com/f/cases/10888/Backport-2-0-Compound-Extension-Met… > >> Fix in inbox: >> SLICE-Issue-10888-Backport-20-Compound-Extension-Methods-Unpackaged-SeanDeNigris.1 > > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/BUG-Extension-Methods-Missing-from-Packages-tp4692842… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 13, 2013

Re: [Pharo-dev] Block Printing in 3.0

by Sven Van Caekenberghe

On 13 Jun 2013, at 14:23, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Why do we get [...] when Opal is not active? Why can't we keep the old > behavior? > > Thanks, > Sean I understood it was either/or - there is an issue somewhere. And Opal will be enabled by default in 3.0 anyway. Sven

June 13, 2013

Block Printing in 3.0

by Sean P. DeNigris

Why do we get [...] when Opal is not active? Why can't we keep the old behavior? Thanks, Sean ----- Cheers, Sean -- View this message in context: http://forum.world.st/Block-Printing-in-3-0-tp4693116.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 13, 2013

Re: [Pharo-dev] [BUG]: Extension Methods Missing from Packages

by Sean P. DeNigris

Bump. Will someone please review this? It is a nasty bug and should be fixed asap. Fixes in inbox for both 2.0 and 3.0: https://pharo.fogbugz.com/f/cases/10887/Compound-Extension-Methods-Unpackag… https://pharo.fogbugz.com/f/cases/10888/Backport-2-0-Compound-Extension-Met… ----- Cheers, Sean -- View this message in context: http://forum.world.st/BUG-Extension-Methods-Missing-from-Packages-tp4692842… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 13, 2013

Re: [Pharo-dev] GetText on Pharo 2.0

by Camillo Bruni

On 2013-06-13, at 10:16, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > On Wed, Jun 12, 2013 at 11:04 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: > >> 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. >> > > I'll NEED access rights to commit my changes. Can someone please add me > to PharoExtras team? done

June 13, 2013

Re: [Pharo-dev] GetText on Pharo 2.0

by Usman Bhatti

On Wed, Jun 12, 2013 at 11:04 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: > 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. > I'll NEED access rights to commit my changes. Can someone please add me to PharoExtras team? > > regards, > Usman > > >

June 13, 2013

[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