[Pharo-project] 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.
Hi guys I would really like to get your feedback on this change because it seems to me that menu are not good enough. 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/13 Levente Uzonyi <leves@elte.hu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
thanks gary. On Jan 18, 2010, at 12:07 PM, Gary Chambers wrote:
Looks ok. Similar things have been done for a few other morphs (buttons I think)...
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/12 Ralph Boland <rpboland@gmail.com>:
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
note about #shallowCopy at the end. When i was dealing with this stuff, i found that text copied multiple times once it finally gets into editor. This , IMO wrong. Model , not editor should care about preserving a backup copy. Editor should feel free to modify an instance of Text, prodived by model. -- Best regards, Igor Stasenko AKA sig.
participants (6)
-
Gary Chambers -
Igor Stasenko -
Levente Uzonyi -
Nicolas Cellier -
Ralph Boland -
Stéphane Ducasse