[Pharo-project] abouth nautilus and the removal of CodeHolder hierarchy

Benjamin 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
>> hierarchy).
> 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?


>> Thanks,

>> Fernando

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 mailing list