[Pharo-project] abouth nautilus and the removal of CodeHolder hierarchy
benjamin.vanryseghem.pharo at gmail.com
Wed Apr 6 16:58:18 CEST 2011
On Apr 6, 2011, at 1:19 PM, Stéphane Ducasse wrote:
> On Apr 5, 2011, at 2:32 PM, Fernando Olivero wrote:
>> Hi Ben, i was thinking about the discussion of the menus:
>> Since you are using menu pragma builder, and have explicit views for
>> each tool, then the CodeHolder hierarchy is no longer needed. Because
>> the specialized views get the behavior for answering the actions in
>> the menus (which currently is spread across the StringHolder
> I would say yes but I will let ben replied with more depth if necessary.
There is two kinds of menus, menus provided by the lists/trees and menus provided by the pluggable text morph.
They're different because first ones really act on the model elements (here classes/methods/etc), when second ones act on text
For lists/trees menus, because they act on your model have to be handled locally ( by your model or your view depending of the action ).
For text menus, they act on text, and will always act on text, so they should be managed by a kind of TextModel, because it's not the role of your Browser to tell how to implement copy/paste, or implementors :)
>> So this is the main reason why you simple need a pluggable text model,
>> for the model of the views. And a pluggable TextModel (or StringHolder
>> in Pharo) would suffice? Is this correct?
StringHolder shouldn't exist anymore :)
For Nautilus, menus actions are handled by the view, but could/should be moved in the model for some of them, but it can be a bit hard to separate the ones only related to the view, and ones relatives to the model ...
And text menus are handled by the PluggableTextMorph whose model is SmalltalkEditor. So it's SmalltalkEditor responsibility to know how to look for senders/implementors/etc
I hope it answer your question ^^
More information about the Pharo-project