* | 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@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:).

I submitted a slice yesterday extracting hardcoded width of splitters for using a theme property. I you want to wrap everything in a container morph, it works pretty well as ing as you do not forget the magic invocation container := Morph new; changeProportionalLayout; yourself Ben On Jun 13, 2013, at 3:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

On Jun 13, 2013, at 2:31 AM, Eliot Miranda <eliot.miranda@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?

We will rewrite a part of this code :).

...

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@gmail.com> wrote:

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

-- best, Eliot