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 <[email protected]> wrote:
>
> On Jun 13, 2013, at 2:31 AM, Eliot Miranda <[email protected]> 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 <[email protected]>
>> wrote:
>>
>>
>> On Wed, Jun 12, 2013 at 2:39 PM, Eliot Miranda <[email protected]>
>> 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
>
