PluggableTextMorph >> getText proposed modification

> In my (Squeak) project I modified PluggableTextMorph >> getText to be
> as follows:
>
> getText
>       "Retrieve the current model text"
>
>       | newText |
>       getTextSelector isNil ifTrue: [^Text new].
>       newText := (getTextSelector numArgs = 1)
>               ifTrue: [model perform: getTextSelector with: self]
>               ifFalse: [model perform: getTextSelector].
>       newText ifNil: [^Text new].
>       ^newText shallowCopy
>
>
> The change allows the getTextSelector to pass an additional argument: self.
> I made this change because I wanted to know which PluggableTextMorph
> was asking for text.
> This is useful when one has large numbers of similar PluggableTextMorphs.
> Note that the method PluggableTextMorph >>  acceptTextInModel
> already does this so I didn't need to modify it.
> Thus I think my change makes PluggableTextMorph more consistent.
>
> Any chance of this change being made a part of the Pharo image?
>
> Frankly, I would prefer that all the GUI objects that have get/set messages
> had this capability.   For CheckBoxes  I earlier added the capability to return
> either self or some arguments (by subclassing this time).
> I am happy with the result.
>
> Another way I could do this would be to create a holder for the
> PluggableTextMorph
> (or other gui object) that would respond to the  getText and
> acceptTextInModel messages
> and would know which PluggableTextMorph is speaking to it (since there
> would be only one).
> The holder would replace the model in the PluggableTextMorph and have
> a reference to the original model to which it could forward messages.
> Again this would allow me to have a large number of similar PluggableTextMorphs.
> One could create a  PluggableTextMorphHolder class for this or create
> a single holder
> class that could work with different Morph classes (only one at a timeof course)
> (by responding to messages from all of them).  It would be nice of
> course if these
> GUI holders already existed in Squeak/Pharo so I didn't have to invent them.
>
> Which approach do you think is better?
>
> Regards,
>
> Ralph Boland
>
>
> --
> I've been middle class and I've been poor.
> Middle class is better.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> or not, but #isUnary seems to be a better (and faster) choice.
>
>
> Levente
>
>>
>> Stef
>>
>> On Jan 12, 2010, at 6:14 AM, Ralph Boland wrote:
>>
>>> In my (Squeak) project I modified PluggableTextMorph >> getText to be
>>> as follows:
>>>
>>> getText
>>>      "Retrieve the current model text"
>>>
>>>      | newText |
>>>      getTextSelector isNil ifTrue: [^Text new].
>>>      newText := (getTextSelector numArgs = 1)
>>>              ifTrue: [model perform: getTextSelector with: self]
>>>              ifFalse: [model perform: getTextSelector].
>>>      newText ifNil: [^Text new].
>>>      ^newText shallowCopy
>>>
>>>
>>> The change allows the getTextSelector to pass an additional argument:
>>> self.
>>> I made this change because I wanted to know which PluggableTextMorph
>>> was asking for text.
>>> This is useful when one has large numbers of similar PluggableTextMorphs.
>>> Note that the method PluggableTextMorph >>  acceptTextInModel
>>> already does this so I didn't need to modify it.
>>> Thus I think my change makes PluggableTextMorph more consistent.
>>>
>>> Any chance of this change being made a part of the Pharo image?
>>>
>>> Frankly, I would prefer that all the GUI objects that have get/set
>>> messages
>>> had this capability.   For CheckBoxes  I earlier added the capability to
>>> return
>>> either self or some arguments (by subclassing this time).
>>> I am happy with the result.
>>>
>>> Another way I could do this would be to create a holder for the
>>> PluggableTextMorph
>>> (or other gui object) that would respond to the  getText and
>>> acceptTextInModel messages
>>> and would know which PluggableTextMorph is speaking to it (since there
>>> would be only one).
>>> The holder would replace the model in the PluggableTextMorph and have
>>> a reference to the original model to which it could forward messages.
>>> Again this would allow me to have a large number of similar
>>> PluggableTextMorphs.
>>> One could create a  PluggableTextMorphHolder class for this or create
>>> a single holder
>>> class that could work with different Morph classes (only one at a timeof
>>> course)
>>> (by responding to messages from all of them).  It would be nice of
>>> course if these
>>> GUI holders already existed in Squeak/Pharo so I didn't have to invent
>>> them.
>>>
>>> Which approach do you think is better?
>>>
>>> Regards,
>>>
>>> Ralph Boland
>>>
>>>
>>> --
>>> I've been middle class and I've been poor.
>>> Middle class is better.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> In my (Squeak) project I modified PluggableTextMorph >> getText to be
> as follows:
>
> getText
>       "Retrieve the current model text"
>
>       | newText |
>       getTextSelector isNil ifTrue: [^Text new].
>       newText := (getTextSelector numArgs = 1)
>               ifTrue: [model perform: getTextSelector with: self]
>               ifFalse: [model perform: getTextSelector].
>       newText ifNil: [^Text new].
>       ^newText shallowCopy
>
>
> The change allows the getTextSelector to pass an additional argument: self.
> I made this change because I wanted to know which PluggableTextMorph
> was asking for text.
> This is useful when one has large numbers of similar PluggableTextMorphs.
> Note that the method PluggableTextMorph >>  acceptTextInModel
> already does this so I didn't need to modify it.
> Thus I think my change makes PluggableTextMorph more consistent.
>
> Any chance of this change being made a part of the Pharo image?
>
> Frankly, I would prefer that all the GUI objects that have get/set messages
> had this capability.   For CheckBoxes  I earlier added the capability to return
> either self or some arguments (by subclassing this time).
> I am happy with the result.
>
> Another way I could do this would be to create a holder for the
> PluggableTextMorph
> (or other gui object) that would respond to the  getText and
> acceptTextInModel messages
> and would know which PluggableTextMorph is speaking to it (since there
> would be only one).
> The holder would replace the model in the PluggableTextMorph and have
> a reference to the original model to which it could forward messages.
> Again this would allow me to have a large number of similar PluggableTextMorphs.
> One could create a  PluggableTextMorphHolder class for this or create
> a single holder
> class that could work with different Morph classes (only one at a timeof course)
> (by responding to messages from all of them).  It would be nice of
> course if these
> GUI holders already existed in Squeak/Pharo so I didn't have to invent them.
>
> Which approach do you think is better?
>
> Regards,
>
> Ralph Boland
>
>
> --
> I've been middle class and I've been poor.
> Middle class is better.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Gary ??
> Alain??
> do one of you have a feedback for this change.
> I would like to integrate it because it makes sense to me but I'm far from
> a UI expert
>
> Stef
>
>
> On Jan 12, 2010, at 6:14 AM, Ralph Boland wrote:
>
>> In my (Squeak) project I modified PluggableTextMorph >> getText to be
>> as follows:
>>
>> getText
>>       "Retrieve the current model text"
>>
>>       | newText |
>>       getTextSelector isNil ifTrue: [^Text new].
>>       newText := (getTextSelector numArgs = 1)
>>               ifTrue: [model perform: getTextSelector with: self]
>>               ifFalse: [model perform: getTextSelector].
>>       newText ifNil: [^Text new].
>>       ^newText shallowCopy
>>
>>
>> The change allows the getTextSelector to pass an additional argument:
>> self.
>> I made this change because I wanted to know which PluggableTextMorph
>> was asking for text.
>> This is useful when one has large numbers of similar PluggableTextMorphs.
>> Note that the method PluggableTextMorph >>  acceptTextInModel
>> already does this so I didn't need to modify it.
>> Thus I think my change makes PluggableTextMorph more consistent.
>>
>> Any chance of this change being made a part of the Pharo image?
>>
>> Frankly, I would prefer that all the GUI objects that have get/set
>> messages
>> had this capability.   For CheckBoxes  I earlier added the capability to
>> return
>> either self or some arguments (by subclassing this time).
>> I am happy with the result.
>>
>> Another way I could do this would be to create a holder for the
>> PluggableTextMorph
>> (or other gui object) that would respond to the  getText and
>> acceptTextInModel messages
>> and would know which PluggableTextMorph is speaking to it (since there
>> would be only one).
>> The holder would replace the model in the PluggableTextMorph and have
>> a reference to the original model to which it could forward messages.
>> Again this would allow me to have a large number of similar
>> PluggableTextMorphs.
>> One could create a  PluggableTextMorphHolder class for this or create
>> a single holder
>> class that could work with different Morph classes (only one at a timeof
>> course)
>> (by responding to messages from all of them).  It would be nice of
>> course if these
>> GUI holders already existed in Squeak/Pharo so I didn't have to invent
>> them.
>>
>> Which approach do you think is better?
>>
>> Regards,
>>
>> Ralph Boland
>>
>>
>> --
>> I've been middle class and I've been poor.
>> Middle class is better.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Looks ok. Similar things have been done for a few other morphs (buttons I
> think)...
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Stéphane Ducasse" <[hidden email]>
> To: <[hidden email]>
> Sent: Monday, January 18, 2010 8:12 AM
> Subject: Re: [Pharo-project] PluggableTextMorph >> getText
> proposedmodification
>
>
>> Gary ??
>> Alain??
>> do one of you have a feedback for this change.
>> I would like to integrate it because it makes sense to me but I'm far from
>> a UI expert
>>
>> Stef
>>
>>
>> On Jan 12, 2010, at 6:14 AM, Ralph Boland wrote:
>>
>>> In my (Squeak) project I modified PluggableTextMorph >> getText to be
>>> as follows:
>>>
>>> getText
>>>      "Retrieve the current model text"
>>>
>>>      | newText |
>>>      getTextSelector isNil ifTrue: [^Text new].
>>>      newText := (getTextSelector numArgs = 1)
>>>              ifTrue: [model perform: getTextSelector with: self]
>>>              ifFalse: [model perform: getTextSelector].
>>>      newText ifNil: [^Text new].
>>>      ^newText shallowCopy
>>>
>>>
>>> The change allows the getTextSelector to pass an additional argument:
>>> self.
>>> I made this change because I wanted to know which PluggableTextMorph
>>> was asking for text.
>>> This is useful when one has large numbers of similar PluggableTextMorphs.
>>> Note that the method PluggableTextMorph >>  acceptTextInModel
>>> already does this so I didn't need to modify it.
>>> Thus I think my change makes PluggableTextMorph more consistent.
>>>
>>> Any chance of this change being made a part of the Pharo image?
>>>
>>> Frankly, I would prefer that all the GUI objects that have get/set
>>> messages
>>> had this capability.   For CheckBoxes  I earlier added the capability to
>>> return
>>> either self or some arguments (by subclassing this time).
>>> I am happy with the result.
>>>
>>> Another way I could do this would be to create a holder for the
>>> PluggableTextMorph
>>> (or other gui object) that would respond to the  getText and
>>> acceptTextInModel messages
>>> and would know which PluggableTextMorph is speaking to it (since there
>>> would be only one).
>>> The holder would replace the model in the PluggableTextMorph and have
>>> a reference to the original model to which it could forward messages.
>>> Again this would allow me to have a large number of similar
>>> PluggableTextMorphs.
>>> One could create a  PluggableTextMorphHolder class for this or create
>>> a single holder
>>> class that could work with different Morph classes (only one at a timeof
>>> course)
>>> (by responding to messages from all of them).  It would be nice of
>>> course if these
>>> GUI holders already existed in Squeak/Pharo so I didn't have to invent
>>> them.
>>>
>>> Which approach do you think is better?
>>>
>>> Regards,
>>>
>>> Ralph Boland
>>>
>>>
>>> --
>>> I've been middle class and I've been poor.
>>> Middle class is better.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> In my (Squeak) project I modified PluggableTextMorph >> getText to be
> as follows:
>
> getText
>       "Retrieve the current model text"
>
>       | newText |
>       getTextSelector isNil ifTrue: [^Text new].
>       newText := (getTextSelector numArgs = 1)
>               ifTrue: [model perform: getTextSelector with: self]
>               ifFalse: [model perform: getTextSelector].
>       newText ifNil: [^Text new].
>       ^newText shallowCopy
>