Smalltalk › Pharo › Pharo Smalltalk Developers

Two possible Morphic-related issues

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Carlos Lombardi

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

Stephan Eggermont-3

Re: Two possible Morphic-related issues

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

Stephan Eggermont-3

Re: Two possible Morphic-related issues

In reply to this post by Carlos Lombardi

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

philippeback

Re: Two possible Morphic-related issues

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 <[hidden email]> 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

Stephan Eggermont-3

Re: Two possible Morphic-related issues

On 06-04-16 15:27, [hidden email] wrote:
> Is there anything else than a SmalltalkEditor there? Now there is Rubric
> too, but...
The superclass of SmalltalkEditor is TextEditor. That is the one I'd expect.

Stephan

Carlos Lombardi

Re: Two possible Morphic-related issues

In reply to this post by Stephan Eggermont-3

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 <[hidden email]> 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

Carlos Lombardi

Re: Two possible Morphic-related issues

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 <[hidden email]> 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 <[hidden email]> 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