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.
On Wed, Jun 12, 2013 at 2:39 PM, Eliot Miranda <eliot.miranda@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