[Pharo-project] Regarding SimpleMorphic

Fernando Olivero fernando.olivero at usi.ch
Fri Apr 1 13:35:12 CEST 2011


Thanks ben, i will have that in mind.

 Regarding the menus, an interesting discussion with Juan came from
 analyzing the menu actions handling:

 1) Who must be responsible for raising the menu? In our case , is the
 menu pragma builder invocation on the view or on the model?
 2) Who should be responsible for handling the menu actions? the model
 , the view or both depending on the action itself?

 I'm intrigued to learn how are you handling this issues in Nautilus?

 Fernando

On Fri, Apr 1, 2011 at 1:09 PM, Benjamin
<benjamin.vanryseghem.pharo at gmail.com> wrote:
>
> On Apr 1, 2011, at 9:16 AM, Fernando Olivero wrote:
>
>> Ok.
>>
>> Regarding the names, I was arguing in favor of using BrowserMorph
>> instead of Browser for the Morphic side, because it would really a
>> Browser for the Morphic UI.
>>
>> So lets agree on the basic required widgets. On the Nautilus side,
>> what are the widgets needed? In a previous email you mentioned
>> MorphTreeMorph. Lets make a list so i know the status of the SMx port,
>> and what needs to be done at the View level.
>>
>> Basic:
>> 1) Button
>> 2) Menus
>> 3) PluggableTextMorph
>> 4) SystemWindow
>> 5) PluggableListMorph ( and maybe its variants)
>> ---------
>> Nautilus:
>> 5) MorphTreeMorph
>
> 6) PluggableIconListMorphOfMany (such a good name ...)
> 7) IconicButton
> 8) MenuBuilder (menus based on pragma)
>
> and I think that's all
>
>
>
> Ben
>
>
>>
>>
>> On Thu, Mar 31, 2011 at 10:01 PM, Stéphane Ducasse
>> <stephane.ducasse at inria.fr> wrote:
>>>>
>>>>
>>>> I agree with it and would like to help with the Nautilus model, and
>>>> the corresponding view for SimpleMorphic.
>>>>
>>>> I belive we should look at CUIS TexProvider hierarchy, since he
>>>> already cleanup this classes, and the intent is similar to the yours.
>>>> As he told in en email: "To clean the hierarchy is ok, but we should
>>>> be very careful to no put MODEL LOGIC in the VIEW. In CUIS the idea is
>>>> to deal with PluggableTextModel that gets plugged a TextProvider or
>>>> CodeProvider."
>>>
>>> I do not see why we need that at all.
>>> For the moment let us finish Nautilus and remove most of the StringHolder subclasses
>>> then after porting that to SimpleMorphic will just be switching to the correct treeMorph
>>> because the model will be the same in Morphic and in SM
>>>
>>>> Somehow similar to what you propose in the pdf, and what stef is
>>>> talking about. Composition instead of inheritance.
>>>>
>>>> So to summarize:
>>>>
>>>> 1) Model logic in specialized code providers
>>>        Not only: a browser model should know not only about code but about the current state of the tools:
>>>        which view (packages,.... buttons is selected).
>>>
>>>> 2) View on specialized views, moving the current functionality from
>>>> the model to the view, that dont have model logic.
>>>        Not really so far we use a good tree and this is enough
>>>
>>>> 3) I suggest keeping the curent names, for instance, Browser is the
>>>> model, BrowserMorph is the view ( in Morphic)
>>>        We will see.
>>>
>>> For the moment this is not important. We should get SM cleaned and port Polymorph on top of it
>>> and clean the main widgets.
>>>
>>>
>>>>
>>>>
>>>> Fernando
>>>> pd: I will sync with Juan on this effort, so we can all work together
>>>> on the next Morphic.
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Mar 31, 2011 at 5:46 PM, Benjamin
>>>> <benjamin.vanryseghem.pharo at gmail.com> wrote:
>>>>>
>>>>> On Mar 31, 2011, at 5:51 PM, Torsten Bergmann wrote:
>>>>>
>>>>>>>> Model
>>>>>>>> TextModel
>>>>>>>> Workspace
>>>>>>>> PluggableTextModel
>>>>>>>> TextProvider
>>>>>>>> CodeProvider
>>>>>>>>    Browser
>>>>>>>>    HierarchyBrowser
>>>>>>>>    Debugger
>>>>>>>>    Inspector
>>>>>>>
>>>>>>> For me, this hierarchy is bad.
>>>>>>> Workspace is not a model, it's a view basically.
>>>>>>
>>>>>> Take care not to confuse things here. If you think as "Workspace"
>>>>>> as the window that is popping up when you open a workspace
>>>>>> then you are on the wrong track.
>>>>>> What you see is just one (morphic) view on a model/workspace instance.
>>>>>>
>>>>>>
>>>>>> Workspace, Inspector, Browser - all these ARE models and
>>>>>> you can have different looking views on it or open one or more views
>>>>>> on the same model.
>>>>>>
>>>>>> Try
>>>>>>
>>>>>> |browserModel  |
>>>>>> browserModel := Browser new.
>>>>>> Browser
>>>>>>  openBrowserView: (browserModel openEditString: nil)
>>>>>>  label: 'View 1'.
>>>>>> Browser
>>>>>>  openBrowserView: (browserModel openEditString: nil)
>>>>>>  label: 'View 2'.
>>>>>
>>>>>
>>>>>
>>>>> Browser class>>#newOnClass: aClass label: aLabel
>>>>>        "Open a new class browser on this class."
>>>>>        | newBrowser |
>>>>>
>>>>>        newBrowser := self new.
>>>>>        newBrowser setClass: aClass selector: nil.
>>>>>        ^ self
>>>>>                openBrowserView: (newBrowser openOnClassWithEditString: nil)
>>>>>                label: aLabel
>>>>>
>>>>>
>>>>> openOnClassWithEditString: aString
>>>>>        "Create a pluggable version of all the views for a Browser, including views and controllers."
>>>>>        ^ self openAsMorphClassEditing: aString.
>>>>>
>>>>>
>>>>> openAsMorphClassEditing: editString
>>>>>        "Create a pluggable version a Browser on just a single class."
>>>>>        ^UIManager default openBrowser: self asMorphClassEditing: editString
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> So here, a Browser instance send openBrowser: asMorphClassEditing: with self as parameter:
>>>>>
>>>>> openBrowser: aBrowser asMorphClassEditing: editString
>>>>>        "Create a pluggable version a Browser on just a single class."
>>>>>        | window dragNDropFlag hSepFrac switchHeight mySingletonClassList |
>>>>>
>>>>>        window := (SystemWindow labelled: 'later') model: aBrowser.
>>>>>        dragNDropFlag := true.
>>>>>        hSepFrac := 0.3.
>>>>>        switchHeight := 25.
>>>>>        mySingletonClassList := PluggableListMorph on: aBrowser list: #classListSingleton
>>>>>                        selected: #indexIsOne changeSelected: #indexIsOne:
>>>>>                        menu: #classListMenu:shifted: keystroke: #classListKey:from:.
>>>>>        mySingletonClassList enableDragNDrop: dragNDropFlag.
>>>>>
>>>>>        aBrowser
>>>>>                addLowerPanesTo: window
>>>>>                at: (0 at hSepFrac corner: 1 at 1)
>>>>>                with: editString.
>>>>>        window
>>>>>                addMorph: mySingletonClassList
>>>>>                fullFrame: (
>>>>>                        LayoutFrame
>>>>>                                fractions: (0 at 0 corner: 0.5 at 0)
>>>>>                                offsets: (0 at 0 corner: 0 at switchHeight)
>>>>>                ).
>>>>>
>>>>>        aBrowser
>>>>>                addMorphicSwitchesTo: window
>>>>>                at: (
>>>>>                        LayoutFrame
>>>>>                                fractions: (0.5 at 0 corner: 1.0 at 0)
>>>>>                                offsets: (0 at 0 corner: 0 at switchHeight)
>>>>>                ).
>>>>>
>>>>>        window
>>>>>                addMorph: aBrowser buildMorphicMessageCatList
>>>>>                fullFrame: (
>>>>>                        LayoutFrame
>>>>>                                fractions: (0 at 0 corner: 0.5 at hSepFrac)
>>>>>                                offsets: (0 at switchHeight corner: 0 at 0)
>>>>>                ).
>>>>>
>>>>>        window
>>>>>                addMorph: aBrowser buildMorphicMessageList
>>>>>                fullFrame: (
>>>>>                        LayoutFrame
>>>>>                                fractions: (0.5 at 0 corner: 1.0 at hSepFrac)
>>>>>                                offsets: (0 at switchHeight corner: 0 at 0)
>>>>>                ).
>>>>>
>>>>>        window setUpdatablePanesFrom: #(messageCategoryList messageList).
>>>>>        ^ window
>>>>>
>>>>> For me, it's not a Model behavior to add panes ...
>>>>>
>>>>>
>>>>> Ben
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Evaluate it, show the windows side by side and then click
>>>>>> in one: two views on the same model and the changes are
>>>>>> propagated to all dependent views.
>>>>>>
>>>>>> So they ARE MODELS:
>>>>>> Take a browser for example. It should know about which class
>>>>>> is selected, which methods to display, ... it's a code holder
>>>>>> and manager thing. Nothing more ... it doesnt even need a UI.
>>>>>>
>>>>>> But it's "view parts" could be (one or more) real windows
>>>>>> layouted in either morphic or a view in Squeaks old MVC or
>>>>>> browser on a Seaside webpage (actually Seaside really has an HTML
>>>>>> based browser).
>>>>>>
>>>>>> The browser model does for instance care if you are working
>>>>>> on the instance or class side (see #metaClassIndicated
>>>>>> and senders) - but it doesnt care if you switch either using
>>>>>> buttons or radio buttons or whatever ... thats up to the view/presentation
>>>>>> layer.
>>>>>>
>>>>>> In general you should be able to also drive this model
>>>>>> without ever really having to open a view ...
>>>>>>
>>>>>> So that even the tools are models (although most people think of them
>>>>>> as windows) is a major difference in Smalltalk's UI design compared to
>>>>>> most UI frameworks in other languages.
>>>>>>
>>>>>> VisualWorks uses a special class ApplicationModel to subclass
>>>>>> for tools and application windows to make this more clear.
>>>>>>
>>>>>> Java's Swing (written by people who designed VisualWorks UI first) has a
>>>>>> similar but more excessive model design JButton -> ButtonModel, ...
>>>>>> The other extreme is VB6/Delphi where you dont have a model at all
>>>>>> and have to write an own if you want separation ;)
>>>>>>
>>>>>> Nothing said about the code quality of the current implementation
>>>>>> in Pharo...
>>>>>>
>>>>>> Bye
>>>>>> T.
>>>>>> --
>>>>>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
>>>>>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



More information about the Pharo-project mailing list