Polymorph (and a few other) changes/fixes

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

Polymorph (and a few other) changes/fixes

Gary Chambers-4
Finally found the time to package out.
Have tested a bit after fixing some conflicts.
A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
 
Attached cs and description of changes

Regards, Gary

Pharo2.0Changes.4.cs (106K) Download Attachment
PharoPolymorphChanges.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Stéphane Ducasse
Thanks!
I really want to have a look at your changes to learned.

I cleaned the <on> <off> menu items handling. Now no string generation and string parsing anymore :)
I let the code to be compatible and in 2.1 we can flush them.

Stef




> Finally found the time to package out.
> Have tested a bit after fixing some conflicts.
> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
>  
> Attached cs and description of changes
>
> Regards, Gary
> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>


Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Benjamin Van Ryseghem (Pharo)
In reply to this post by Gary Chambers-4
<base href="x-msg://850/">Do you have an example where the DropListMorph wrapSelector is broken ? 

Ben

On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:

Finally found the time to package out.
Have tested a bit after fixing some conflicts.
A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
 
Attached cs and description of changes

Regards, Gary
<Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>

Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Stéphane Ducasse
In reply to this post by Gary Chambers-4
Gary

I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ?

ExpanderMorph>>defaultTitleMorph
        "Answer a default title morph for the receiver."

        ^ExpanderTitleMorph basicNew
                basicTheme: self theme;
                initialize;
                hResizing: #spaceFill;
                vResizing: #shrinkWrap;
                basicTheme: nil
       



On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:

> Finally found the time to package out.
> Have tested a bit after fixing some conflicts.
> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
>  
> Attached cs and description of changes
>
> Regards, Gary
> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>


Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Stéphane Ducasse
In reply to this post by Gary Chambers-4
esteban, marcus I will integrate these fixes probably in the beginning of the afternoon.

Stef

On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:

> Finally found the time to package out.
> Have tested a bit after fixing some conflicts.
> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
>  
> Attached cs and description of changes
>
> Regards, Gary
> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>


Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Gary Chambers-4
In reply to this post by Benjamin Van Ryseghem (Pharo)
<BASE href="x-msg://850/">
Hi,
 
well it seems that there is now an inst var on DropListMorph for wrapSelector,
only used by getter/setter and wrapItem:index:
 
Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed.
So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as
updateList never gets sent to the list...
 
E.g.
 
(UITheme builder
 newDropListFor: (ListModel new list: {Object. Rectangle})
 list: #list
 getSelected: nil
 setSelected: nil
 getEnabled: nil
 help: nil)
 wrapSelector: #className;
 openInWindow
 
 
Easy to fix but I'll wait till it is before I post some of my changes that were in conflict.
 
Regards, Gary
----- Original Message -----
Sent: Wednesday, April 25, 2012 10:28 AM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes

Do you have an example where the DropListMorph wrapSelector is broken ? 

Ben

On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:

Finally found the time to package out.
Have tested a bit after fixing some conflicts.
A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
 
Attached cs and description of changes

Regards, Gary
<Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>

Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Gary Chambers-4
In reply to this post by Stéphane Ducasse
Hi Stef,

I guess you mean to move the resizing bits.
It is explicit in ExpanderMorph because that's how the title
should be in the context of an expander.

The ExpanderTitleMorph *could* be used elsewhere with different
properties.

Regards, Gary

----- Original Message -----
From: "Stéphane Ducasse" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, April 25, 2012 10:42 AM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes


Gary

I was wondering if a part of this method could be used in
ExpanderTitleMorph>>initialize ?

ExpanderMorph>>defaultTitleMorph
"Answer a default title morph for the receiver."

^ExpanderTitleMorph basicNew
basicTheme: self theme;
initialize;
hResizing: #spaceFill;
vResizing: #shrinkWrap;
basicTheme: nil




On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:

> Finally found the time to package out.
> Have tested a bit after fixing some conflicts.
> A few minor ones left for DropListMorph as it seems the wrapSelector stuff
> has changed (and appears broken in 2.0 too).
>
> Attached cs and description of changes
>
> Regards, Gary
> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>



Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Benjamin Van Ryseghem (Pharo)
In reply to this post by Gary Chambers-4
<base href="x-msg://850/">I do not get why, but in your example, wrapSelector instance is always nil ...

I use this (DropListMorph + wrapSelector) for nautilus, and it works as expected (the list is wrapped too).


Ben

On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote:

Hi,
 
well it seems that there is now an inst var on DropListMorph for wrapSelector,
only used by getter/setter and wrapItem:index:
 
Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed.
So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as
updateList never gets sent to the list...
 
E.g.
 
(UITheme builder
 newDropListFor: (ListModel new list: {Object. Rectangle})
 list: #list
 getSelected: nil
 setSelected: nil
 getEnabled: nil
 help: nil)
 wrapSelector: #className;
 openInWindow
 
 
Easy to fix but I'll wait till it is before I post some of my changes that were in conflict.
 
Regards, Gary
----- Original Message -----
Sent: Wednesday, April 25, 2012 10:28 AM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes

Do you have an example where the DropListMorph wrapSelector is broken ? 

Ben

On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:

Finally found the time to package out.
Have tested a bit after fixing some conflicts.
A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
 
Attached cs and description of changes

Regards, Gary
<Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>



Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Benjamin Van Ryseghem (Pharo)
In reply to this post by Gary Chambers-4
<base href="x-msg://850/">
Ok, found why :)


This fix it for me :)

Can you have a quick look ?


Thanks in advance,

Ben



<base href="x-msg://850/">




On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote:

Hi,
 
well it seems that there is now an inst var on DropListMorph for wrapSelector,
only used by getter/setter and wrapItem:index:
 
Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed.
So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as
updateList never gets sent to the list...
 
E.g.
 
(UITheme builder
 newDropListFor: (ListModel new list: {Object. Rectangle})
 list: #list
 getSelected: nil
 setSelected: nil
 getEnabled: nil
 help: nil)
 wrapSelector: #className;
 openInWindow
 
 
Easy to fix but I'll wait till it is before I post some of my changes that were in conflict.
 
Regards, Gary
----- Original Message -----
Sent: Wednesday, April 25, 2012 10:28 AM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes

Do you have an example where the DropListMorph wrapSelector is broken ? 

Ben

On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:

Finally found the time to package out.
Have tested a bit after fixing some conflicts.
A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
 
Attached cs and description of changes

Regards, Gary
<Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>




DropListMorph-wrapSelector.st (370 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Stéphane Ducasse
In reply to this post by Gary Chambers-4
I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo:

self allMorphsDo: [:m |
                (m ~= self and: [m respondsTo: #font:])
                        ifTrue: [m font: aFont]]


Stef
Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Stéphane Ducasse
In reply to this post by Gary Chambers-4

On Apr 25, 2012, at 12:33 PM, Gary Chambers wrote:

> Hi Stef,
>
> I guess you mean to move the resizing bits.

I do not know.
I was more thinking about the use of basicNew and the explicit initialize which was a kind of bad smell to me.

Stef

> It is explicit in ExpanderMorph because that's how the title
> should be in the context of an expander.
>
> The ExpanderTitleMorph *could* be used elsewhere with different
> properties.
>
> Regards, Gary
>
> ----- Original Message ----- From: "Stéphane Ducasse" <[hidden email]>
> To: <[hidden email]>
> Sent: Wednesday, April 25, 2012 10:42 AM
> Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
>
>
> Gary
>
> I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ?
>
> ExpanderMorph>>defaultTitleMorph
> "Answer a default title morph for the receiver."
>
> ^ExpanderTitleMorph basicNew
> basicTheme: self theme;
> initialize;
> hResizing: #spaceFill;
> vResizing: #shrinkWrap;
> basicTheme: nil
>
>
>
>
> On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
>
>> Finally found the time to package out.
>> Have tested a bit after fixing some conflicts.
>> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
>>
>> Attached cs and description of changes
>>
>> Regards, Gary
>> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Stéphane Ducasse
In reply to this post by Gary Chambers-4

On Apr 25, 2012, at 12:33 PM, Gary Chambers wrote:

> Hi Stef,
>
> I guess you mean to move the resizing bits.

I do not know.
I was more thinking about the use of basicNew and the explicit initialize which was a kind of bad smell to me.

Stef

> It is explicit in ExpanderMorph because that's how the title
> should be in the context of an expander.
>
> The ExpanderTitleMorph *could* be used elsewhere with different
> properties.
>
> Regards, Gary
>
> ----- Original Message ----- From: "Stéphane Ducasse" <[hidden email]>
> To: <[hidden email]>
> Sent: Wednesday, April 25, 2012 10:42 AM
> Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
>
>
> Gary
>
> I was wondering if a part of this method could be used in ExpanderTitleMorph>>initialize ?
>
> ExpanderMorph>>defaultTitleMorph
> "Answer a default title morph for the receiver."
>
> ^ExpanderTitleMorph basicNew
> basicTheme: self theme;
> initialize;
> hResizing: #spaceFill;
> vResizing: #shrinkWrap;
> basicTheme: nil
>
>
>
>
> On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
>
>> Finally found the time to package out.
>> Have tested a bit after fixing some conflicts.
>> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
>>
>> Attached cs and description of changes
>>
>> Regards, Gary
>> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Gary Chambers-4
In reply to this post by Benjamin Van Ryseghem (Pharo)
<BASE href="x-msg://850/">
Yep, that's what I expected as fix ;-)

Regards, Gary
----- Original Message -----
Sent: Wednesday, April 25, 2012 11:58 AM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes

Ok, found why :)


This fix it for me :)

Can you have a quick look ?


Thanks in advance,

Ben



<BASE href="x-msg://850/">




On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote:

Hi,
 
well it seems that there is now an inst var on DropListMorph for wrapSelector,
only used by getter/setter and wrapItem:index:
 
Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed.
So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as
updateList never gets sent to the list...
 
E.g.
 
(UITheme builder
 newDropListFor: (ListModel new list: {Object. Rectangle})
 list: #list
 getSelected: nil
 setSelected: nil
 getEnabled: nil
 help: nil)
 wrapSelector: #className;
 openInWindow
 
 
Easy to fix but I'll wait till it is before I post some of my changes that were in conflict.
 
Regards, Gary
----- Original Message -----
Sent: Wednesday, April 25, 2012 10:28 AM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes

Do you have an example where the DropListMorph wrapSelector is broken ? 

Ben

On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:

Finally found the time to package out.
Have tested a bit after fixing some conflicts.
A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
 
Attached cs and description of changes

Regards, Gary
<Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>




Ok, found why :)


This fix it for me :)

Can you have a quick look ?


Thanks in advance,

Ben







On Apr 25, 2012, at 12:29 PM, Gary Chambers wrote:

> Hi,

> well it seems that there is now an inst var on DropListMorph for wrapSelector,
> only used by getter/setter and wrapItem:index:

> Setting sends updateContents which uses wrapItem:index: on the (sub) list morph, which never gets changed.
> So, although the contents are correct (eventually returns to the local wrapItem:index), the list items are incorrect as
> updateList never gets sent to the list...

> E.g.

> (UITheme builder
>  newDropListFor: (ListModel new list: {Object. Rectangle})
>  list: #list
>  getSelected: nil
>  setSelected: nil
>  getEnabled: nil
>  help: nil)
>  wrapSelector: #className;
>  openInWindow


> Easy to fix but I'll wait till it is before I post some of my changes that were in conflict.

> Regards, Gary
> ----- Original Message -----
> From: Benjamin
> To: [hidden email]
> Sent: Wednesday, April 25, 2012 10:28 AM
> Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
>
> Do you have an example where the DropListMorph wrapSelector is broken ?
>
> Ben
>
> On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
>
>> Finally found the time to package out.
>> Have tested a bit after fixing some conflicts.
>> A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too).
>> 
>> Attached cs and description of changes
>>
>> Regards, Gary
>> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Gary Chambers-4
In reply to this post by Stéphane Ducasse
Indeed, unfortunately, due to the way it was done all those years ago,
many (Poly)morphs create sub/ancillary morphs in the initialize.
If the theme is not set they will get created with the current theme, rather
than the theme doing the initial creation.

I suppose the submorph creation could be done in a separate method and
called after initalize and theme setting, a lot more work to do that way
though.

Regards, Gary

----- Original Message -----
From: "Stéphane Ducasse" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, April 25, 2012 12:55 PM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes



On Apr 25, 2012, at 12:33 PM, Gary Chambers wrote:

> Hi Stef,
>
> I guess you mean to move the resizing bits.

I do not know.
I was more thinking about the use of basicNew and the explicit initialize
which was a kind of bad smell to me.

Stef

> It is explicit in ExpanderMorph because that's how the title
> should be in the context of an expander.
>
> The ExpanderTitleMorph *could* be used elsewhere with different
> properties.
>
> Regards, Gary
>
> ----- Original Message ----- From: "Stéphane Ducasse"
> <[hidden email]>
> To: <[hidden email]>
> Sent: Wednesday, April 25, 2012 10:42 AM
> Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
>
>
> Gary
>
> I was wondering if a part of this method could be used in
> ExpanderTitleMorph>>initialize ?
>
> ExpanderMorph>>defaultTitleMorph
> "Answer a default title morph for the receiver."
>
> ^ExpanderTitleMorph basicNew
> basicTheme: self theme;
> initialize;
> hResizing: #spaceFill;
> vResizing: #shrinkWrap;
> basicTheme: nil
>
>
>
>
> On Apr 24, 2012, at 5:21 PM, Gary Chambers wrote:
>
>> Finally found the time to package out.
>> Have tested a bit after fixing some conflicts.
>> A few minor ones left for DropListMorph as it seems the wrapSelector
>> stuff has changed (and appears broken in 2.0 too).
>>
>> Attached cs and description of changes
>>
>> Regards, Gary
>> <Pharo2.0Changes.4.cs><PharoPolymorphChanges.txt>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Gary Chambers-4
In reply to this post by Stéphane Ducasse
Well, since a TabLabelMorph could have any morph within it all
morphs would have to implement #font: otherwise.

It is the price of having both convenience and flexibility.

Regards, Gary

----- Original Message -----
From: "Stéphane Ducasse" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, April 25, 2012 12:53 PM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes


I see such idiom and I'm thinking that it would be good to fix such kind of
respondsTo:

self allMorphsDo: [:m |
(m ~= self and: [m respondsTo: #font:])
ifTrue: [m font: aFont]]


Stef


Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Stéphane Ducasse
In reply to this post by Stéphane Ducasse
In the future we will have to look at respondsTo:
and remove them because we should enforce for example that objects that are used have the right protocol

        |label|
        label := self checkboxLabelForText: aCheckbox label.
        (label respondsTo: #enabled:) ifTrue: [
                label enabled: aCheckbox enabled].
        label font: self labelFont.
        ^label


On Apr 25, 2012, at 1:53 PM, Stéphane Ducasse wrote:

> I see such idiom and I'm thinking that it would be good to fix such kind of respondsTo:
>
> self allMorphsDo: [:m |
> (m ~= self and: [m respondsTo: #font:])
> ifTrue: [m font: aFont]]
>
>
> Stef


Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Gary Chambers-4
Indeed.

Hold off on integration for a few mins, some last minute fixes...

Regards, Gary

----- Original Message -----
From: "Stéphane Ducasse" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, April 25, 2012 1:17 PM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes


In the future we will have to look at respondsTo:
and remove them because we should enforce for example that objects that are
used have the right protocol

|label|
label := self checkboxLabelForText: aCheckbox label.
(label respondsTo: #enabled:) ifTrue: [
label enabled: aCheckbox enabled].
label font: self labelFont.
^label


On Apr 25, 2012, at 1:53 PM, Stéphane Ducasse wrote:

> I see such idiom and I'm thinking that it would be good to fix such kind
> of respondsTo:
>
> self allMorphsDo: [:m |
> (m ~= self and: [m respondsTo: #font:])
> ifTrue: [m font: aFont]]
>
>
> Stef



Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Gary Chambers-4
Fixes for checkbox, Benjamin, please check as I had to revert the
CheckboxMorph>>initialize to not hook the click event.

Also I notice that tabbing from lists (and shift-tabbing from multiline
text) appears to have been broken at some point
before these changes.

Attached lastest cs

Regards, Gary

----- Original Message -----
From: "Gary Chambers" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, April 25, 2012 3:36 PM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes


> Indeed.
>
> Hold off on integration for a few mins, some last minute fixes...
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Stéphane Ducasse" <[hidden email]>
> To: <[hidden email]>
> Sent: Wednesday, April 25, 2012 1:17 PM
> Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
>
>
> In the future we will have to look at respondsTo:
> and remove them because we should enforce for example that objects that
> are used have the right protocol
>
> |label|
> label := self checkboxLabelForText: aCheckbox label.
> (label respondsTo: #enabled:) ifTrue: [
> label enabled: aCheckbox enabled].
> label font: self labelFont.
> ^label
>
>
> On Apr 25, 2012, at 1:53 PM, Stéphane Ducasse wrote:
>
>> I see such idiom and I'm thinking that it would be good to fix such kind
>> of respondsTo:
>>
>> self allMorphsDo: [:m |
>> (m ~= self and: [m respondsTo: #font:])
>> ifTrue: [m font: aFont]]
>>
>>
>> Stef
>
>
>

Pharo2.0Changes.6.cs (107K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Gary Chambers-4
And another...

That'll have to do for now. The tab focus things will take quite some
investigation...

Regards, Gary

----- Original Message -----
From: "Gary Chambers" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, April 25, 2012 3:52 PM
Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes


> Fixes for checkbox, Benjamin, please check as I had to revert the
> CheckboxMorph>>initialize to not hook the click event.
>
> Also I notice that tabbing from lists (and shift-tabbing from multiline
> text) appears to have been broken at some point
> before these changes.
>
> Attached lastest cs
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Gary Chambers" <[hidden email]>
> To: <[hidden email]>
> Sent: Wednesday, April 25, 2012 3:36 PM
> Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
>
>
>> Indeed.
>>
>> Hold off on integration for a few mins, some last minute fixes...
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Stéphane Ducasse" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Wednesday, April 25, 2012 1:17 PM
>> Subject: Re: [Pharo-project] Polymorph (and a few other) changes/fixes
>>
>>
>> In the future we will have to look at respondsTo:
>> and remove them because we should enforce for example that objects that
>> are used have the right protocol
>>
>> |label|
>> label := self checkboxLabelForText: aCheckbox label.
>> (label respondsTo: #enabled:) ifTrue: [
>> label enabled: aCheckbox enabled].
>> label font: self labelFont.
>> ^label
>>
>>
>> On Apr 25, 2012, at 1:53 PM, Stéphane Ducasse wrote:
>>
>>> I see such idiom and I'm thinking that it would be good to fix such kind
>>> of respondsTo:
>>>
>>> self allMorphsDo: [:m |
>>> (m ~= self and: [m respondsTo: #font:])
>>> ifTrue: [m font: aFont]]
>>>
>>>
>>> Stef
>>
>>
>>
>

Pharo2.0Changes.7.cs (107K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Polymorph (and a few other) changes/fixes

Sean P. DeNigris
Administrator
In reply to this post by Gary Chambers-4
Gary Chambers-4 wrote
Well, since a TabLabelMorph could have any morph within it all
morphs would have to implement #font: otherwise.
This is something I've wondered about since finding Smalltalk. Isn't that the Smalltalk way? i.e. put an extension method in Morph that does nothing and package it with Polymorph.
Cheers,
Sean
12