2010/1/13 Levente Uzonyi <[email protected]>:
> On Wed, 13 Jan 2010, Stéphane Ducasse wrote:
>
>> Hi guys
>>
>> I would really like to get your feedback on this change because it seems
>> to me that menu are not
>> good enough.
>
> There were problems with String >> #numArgs, don't know if they still exist

http://code.google.com/p/pharo/issues/detail?id=237 ? I think this
should go in trunk too if not already here...

> 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
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to