I was looking at https://pharo.fogbugz.com/f/cases/edit/15237/Spec-TextModel-for-plain-text and it seems that we have (at least ) three different menus. TextEditor class>>yellowButtonMenu (TextModel for editing text) â âSmalltalkEditor class>>yellowButtonMenu (default TextModel, for code) â RubSmalltalkCodeMode class>>menuOn: (Playground) â Since we have already disabled code completion in TextModel some time ago I would propose to set TextEditor's menu by default, and have the Code one only explicitly (through #beForCode which would also enable the default codeCompletion). Shortcuts interestingly work even without the menu, so it shouldn't break people's workflow (e.g. you could still inspect things and so forth). Anyone has any objections? Peter
Let us imagine that TextEditor SmalltalkEditor should disappear. Stef Le 5/7/15 11:46, Peter Uhnák a écrit :
I was looking at https://pharo.fogbugz.com/f/cases/edit/15237/Spec-TextModel-for-plain-text and it seems that we have (at least ) three different menus.
TextEditor class>>yellowButtonMenu (TextModel for editing text)
â âSmalltalkEditor class>>yellowButtonMenu (default TextModel, for code)
â RubSmalltalkCodeMode class>>menuOn: (Playground)
â Since we have already disabled code completion in TextModel some time ago I would propose to set TextEditor's menu by default, and have the Code one only explicitly (through #beForCode which would also enable the default codeCompletion).
Shortcuts interestingly work even without the menu, so it shouldn't break people's workflow (e.g. you could still inspect things and so forth).
Anyone has any objections? go for it.
Peter
2015-07-05 11:46 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
I was looking at https://pharo.fogbugz.com/f/cases/edit/15237/Spec-TextModel-for-plain-text and it seems that we have (at least ) three different menus.
TextEditor class>>yellowButtonMenu (TextModel for editing text)
â âSmalltalkEditor class>>yellowButtonMenu (default TextModel, for code)
â RubSmalltalkCodeMode class>>menuOn: (Playground)
â Since we have already disabled code completion in TextModel some time ago I would propose to set TextEditor's menu by default, and have the Code one only explicitly (through #beForCode which would also enable the default codeCompletion).
Shortcuts interestingly work even without the menu, so it shouldn't break people's workflow (e.g. you could still inspect things and so forth).
The cleaner way would be to use TextEditor as default EditorClass in TextModel "beForText" and SmalltalkEditor for "beForCode". With that, the menublock coude ask the editor class for the default menu (now it uses SmalltalkEditors menu as default)
Anyone has any objections?
Peter
The cleaner way would be to use TextEditor as default EditorClass in TextModel "beForText" and SmalltalkEditor for "beForCode". With that, the menublock coude ask the editor class for the default menu (now it uses SmalltalkEditors menu as default)
That would work only if the TextModel would always have some EditorClass; so if you wanted your custom menu you would have to create a new EditorClass object. While this in principle is ok, Spec already has block-based API so I would stick to it.
2015-07-05 13:06 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
The cleaner way would be to use TextEditor as default EditorClass in
TextModel "beForText" and SmalltalkEditor for "beForCode". With that, the menublock coude ask the editor class for the default menu (now it uses SmalltalkEditors menu as default)
That would work only if the TextModel would always have some EditorClass; so if you wanted your custom menu you would have to create a new EditorClass object.
No, I meant specs TextModels default menuBlock could call its editor menus: menuHolder := [ :menu :shifted | shifted ifTrue: [ self editor shiftedYellowButtonMenu ] ifFalse: [ self editor yellowButtonMenu ] ] asValueHolder. and if you want your own menu you can set menuHolder to a new value (like we already do it now).
While this in principle is ok, Spec already has block-based API so I would stick to it.
And what would be the main benefit? Because there's no other usage of editor from TextModel, so you would have to add extra instance variable and method(s) just for this. Right now it's separated just in the two methods (beFor*) ... look to inbox at 15237. Peter On Sun, Jul 5, 2015 at 6:02 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2015-07-05 13:06 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
The cleaner way would be to use TextEditor as default EditorClass in
TextModel "beForText" and SmalltalkEditor for "beForCode". With that, the menublock coude ask the editor class for the default menu (now it uses SmalltalkEditors menu as default)
That would work only if the TextModel would always have some EditorClass; so if you wanted your custom menu you would have to create a new EditorClass object.
No, I meant specs TextModels default menuBlock could call its editor menus:
menuHolder := [ :menu :shifted | shifted ifTrue: [ self editor shiftedYellowButtonMenu ] ifFalse: [ self editor yellowButtonMenu ] ] asValueHolder.
and if you want your own menu you can set menuHolder to a new value (like we already do it now).
While this in principle is ok, Spec already has block-based API so I would stick to it.
2015-07-05 18:09 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
And what would be the main benefit? Because there's no other usage of editor from TextModel, so you would have to add extra instance variable and method(s) just for this. Right now it's separated just in the two methods (beFor*) ... look to inbox at 15237.
You could implement "self editor" with the TextModelAdapter and make the textmodel independent of any TextEditor/SmalltalkEditor.
Peter
On Sun, Jul 5, 2015 at 6:02 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2015-07-05 13:06 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
The cleaner way would be to use TextEditor as default EditorClass in
TextModel "beForText" and SmalltalkEditor for "beForCode". With that, the menublock coude ask the editor class for the default menu (now it uses SmalltalkEditors menu as default)
That would work only if the TextModel would always have some EditorClass; so if you wanted your custom menu you would have to create a new EditorClass object.
No, I meant specs TextModels default menuBlock could call its editor menus:
menuHolder := [ :menu :shifted | shifted ifTrue: [ self editor shiftedYellowButtonMenu ] ifFalse: [ self editor yellowButtonMenu ] ] asValueHolder.
and if you want your own menu you can set menuHolder to a new value (like we already do it now).
While this in principle is ok, Spec already has block-based API so I would stick to it.
participants (3)
-
Nicolai Hess -
Peter Uhnák -
stepharo