[Pharo-project] Regarding SimpleMorphic

Fernando Olivero fernando.olivero at usi.ch
Fri Apr 1 09:16:36 CEST 2011


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) ?


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