[Pharo-project] Regarding SimpleMorphic

Benjamin benjamin.vanryseghem.pharo at gmail.com
Fri Apr 1 13:09:15 CEST 2011


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