straaannnnge code in SystemWindow>>addMorph:fullFrame:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

straaannnnge code in SystemWindow>>addMorph:fullFrame:

Eliot Miranda-2
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?
--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: straaannnnge code in SystemWindow>>addMorph:fullFrame:

Eliot Miranda-2


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


Reply | Threaded
Open this post in threaded view
|

Re: straaannnnge code in SystemWindow>>addMorph:fullFrame:

Nicolas Cellier
Concerning the gem, this remind me http://bugs.squeak.org/view.php?id=7012


2013/6/13 Eliot Miranda <[hidden email]>


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






Reply | Threaded
Open this post in threaded view
|

Re: straaannnnge code in SystemWindow>>addMorph:fullFrame:

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
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 <[hidden email]> wrote:


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


Reply | Threaded
Open this post in threaded view
|

Re: straaannnnge code in SystemWindow>>addMorph:fullFrame:

Bob Arning-2
AlignmentMorph. Although all its capabilities are available in Morph itself.

On 6/12/13 8:31 PM, Eliot Miranda wrote:
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?




Reply | Threaded
Open this post in threaded view
|

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

Stéphane Ducasse
In reply to this post by Eliot Miranda-2

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


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