Two possible Morphic-related issues
Hi, proviso: this is my first mail to a Pharo list. I guess that it is pertinent for the pharo-dev list, since it describes a possible failure in Pharo 4 and an enhancement suggestion. If this mail is better suited for the pharo-users list, or else it should be better addressed to both lists, please let me know. Thanks! ---------------------------------- I just upgraded an application from Pharo 3 to Pharo 4. In this application, we use StrikeFont class>>fromUser:allowKeyboard: to let the user choose the point size of the font in a PluggableTextMorph. In fact, the size is applied to the selected part of the text only, so that we allow the edition of a text mixing different point sizes, and also bold, italics and underline. I hope to be able to publish shortly a button row that adds this capability to a given PluggableTextMorph. The mentioned method, StrikeFont class>>fromUser:allowKeyboard:, builds a menu where a check box is added to each option. This menu is told the currently selected point size, to propose it as pre-selected value. To build such a menu, the options are Associations (Boolean -> String), where the boolean is true for the option to be pre-selected, instead of just Strings. This works OK in Pharo 3. But in Pharo 4, we get an error when using StrikeFont class>>fromUser:allowKeyboard:. The reason lies in MenuMorph>>addToggle:target:selector:getStateSelector:enablementSelector:argumentList:, where the message translated is sent to the first parameter. This parameter is assumed to be a String, whilst in this case it is the Association I just mentioned. I provisionally patched this issue by modifying the class method in StrikeFont, in order to give the menu Strings instead of Associations. As far as this way of selecting a point size is still usable, it would be nice to have this issue fixed. If there is another, maybe more modern, way of graphically choosing a point size, please let me know. We had another problem to obtain a mix-style PluggableTextMorph. When the Text is accepted, the model is given actually a style-less Text, this is explicitly established in PluggableTextMorph>>acceptTextInModel. I guess that such is convenient when the Text being edited is code, so that the styles are automatically set by the editor, and must not be present in the code of a method. But in our case, it is the user that establishes the styles, so that they must be preserved. I created a subclass of PluggableTextMorph, in which the Text is passed unchanged to the model. If there is a better way to solve this issue, please tell me. Please consider the possibility of creating a specific CodeTextMorph in order to deal with the peculiarities of the code edition, instead of mixing them in the would-be-generic PluggableTextMorph. Cordially - Carlos Lombardi
On 05-04-16 23:22, Carlos Lombardi wrote:
I provisionally patched this issue by modifying the class method in StrikeFont, in order to give the menu Strings instead of Associations. As far as this way of selecting a point size is still usable, it would be nice to have this issue fixed. If there is another, maybe more modern, way of graphically choosing a point size, please let me know. This is fixed in Pharo 5, if I understand you correctly:
StrikeFont fromUser: StrikeFont fromUser seems to do the right thing. The translated was added 2015-4-25 and removed again 2015-9-3 Current implementation is MenuMorph>addToggle: aString target: anObject selector: aSymbol getStateSelector: stateSymbol enablementSelector: enableSymbol argumentList: argList "Append a menu item with the given label. If the item is selected, it will send the given selector to the target object." |item| item := ToggleMenuItemMorph new contents: aString; target: anObject; selector: aSymbol; arguments: argList; getStateSelector: stateSymbol; enablementSelector: enableSymbol. ^ self addMenuItem: item If this solves the problem, you can open an issue for this and we can backPort it Stephan
Hi Stephan, thank you for your prompt answer. We are actually using TextEditor>>changeTextFont, which initiates the following message call chain TextEditor>>changeTextFont StrikeFont class>>fromUser: MorphicUIManager>>fontFromUser: StrikeFont class>>fromUser:allowKeyboard: Therefore, the method StrikeFont class>>fromUser: is already used. It is handy to us to use TextEditor>>changeTextFont, because it takes as default the font used in the currenty pointed character of the editor. Effectively, removing the use of the translated method in the MenuMorph method you transcribed solves the problem. I will try to open an issue. Cordially - Carlos Lombardi On Wed, Apr 6, 2016 at 9:16 AM, Stephan Eggermont <stephan@stack.nl> wrote:
On 05-04-16 23:22, Carlos Lombardi wrote:
I provisionally patched this issue by modifying the class method in StrikeFont, in order to give the menu Strings instead of Associations. As far as this way of selecting a point size is still usable, it would be nice to have this issue fixed. If there is another, maybe more modern, way of graphically choosing a point size, please let me know.
This is fixed in Pharo 5, if I understand you correctly:
StrikeFont fromUser: StrikeFont fromUser
seems to do the right thing.
The translated was added 2015-4-25 and removed again 2015-9-3 Current implementation is
MenuMorph>addToggle: aString target: anObject selector: aSymbol getStateSelector: stateSymbol enablementSelector: enableSymbol argumentList: argList "Append a menu item with the given label. If the item is selected, it will send the given selector to the target object."
|item| item := ToggleMenuItemMorph new contents: aString; target: anObject; selector: aSymbol; arguments: argList; getStateSelector: stateSymbol; enablementSelector: enableSymbol. ^ self addMenuItem: item
If this solves the problem, you can open an issue for this and we can backPort it
Stephan
Et voilà , I just opened the issue, the number given by fogbugz is 17951. Thanks again - Carlos On Thu, Apr 7, 2016 at 1:13 PM, Carlos Lombardi <carlombardi@gmail.com> wrote:
Hi Stephan,
thank you for your prompt answer.
We are actually using TextEditor>>changeTextFont, which initiates the following message call chain TextEditor>>changeTextFont StrikeFont class>>fromUser: MorphicUIManager>>fontFromUser: StrikeFont class>>fromUser:allowKeyboard:
Therefore, the method StrikeFont class>>fromUser: is already used. It is handy to us to use TextEditor>>changeTextFont, because it takes as default the font used in the currenty pointed character of the editor.
Effectively, removing the use of the translated method in the MenuMorph method you transcribed solves the problem. I will try to open an issue.
Cordially - Carlos Lombardi
On Wed, Apr 6, 2016 at 9:16 AM, Stephan Eggermont <stephan@stack.nl> wrote:
On 05-04-16 23:22, Carlos Lombardi wrote:
I provisionally patched this issue by modifying the class method in StrikeFont, in order to give the menu Strings instead of Associations. As far as this way of selecting a point size is still usable, it would be nice to have this issue fixed. If there is another, maybe more modern, way of graphically choosing a point size, please let me know.
This is fixed in Pharo 5, if I understand you correctly:
StrikeFont fromUser: StrikeFont fromUser
seems to do the right thing.
The translated was added 2015-4-25 and removed again 2015-9-3 Current implementation is
MenuMorph>addToggle: aString target: anObject selector: aSymbol getStateSelector: stateSymbol enablementSelector: enableSymbol argumentList: argList "Append a menu item with the given label. If the item is selected, it will send the given selector to the target object."
|item| item := ToggleMenuItemMorph new contents: aString; target: anObject; selector: aSymbol; arguments: argList; getStateSelector: stateSymbol; enablementSelector: enableSymbol. ^ self addMenuItem: item
If this solves the problem, you can open an issue for this and we can backPort it
Stephan
On 05-04-16 23:22, Carlos Lombardi wrote:
We had another problem to obtain a mix-style PluggableTextMorph. When the Text is accepted, the model is given actually a style-less Text, this is explicitly established in PluggableTextMorph>>acceptTextInModel. I guess that such is convenient when the Text being edited is code, so that the styles are automatically set by the editor, and must not be present in the code of a method. But in our case, it is the user that establishes the styles, so that they must be preserved.
That is a problem that occurs more in the Text subsystem. E.g. TextMorph>editorClass returns a SmalltalkEditor, which is also just wrong. Stephan
Stephan, Is there anything else than a SmalltalkEditor there? Now there is Rubric too, but... Phil On Wed, Apr 6, 2016 at 2:34 PM, Stephan Eggermont <stephan@stack.nl> wrote:
On 05-04-16 23:22, Carlos Lombardi wrote:
We had another problem to obtain a mix-style PluggableTextMorph. When the Text is accepted, the model is given actually a style-less Text, this is explicitly established in PluggableTextMorph>>acceptTextInModel. I guess that such is convenient when the Text being edited is code, so that the styles are automatically set by the editor, and must not be present in the code of a method. But in our case, it is the user that establishes the styles, so that they must be preserved.
That is a problem that occurs more in the Text subsystem. E.g. TextMorph>editorClass returns a SmalltalkEditor, which is also just wrong.
Stephan
participants (3)
-
Carlos Lombardi -
phil＠highoctane.be -
Stephan Eggermont