[Pharo-project] Regarding SimpleMorphic
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'. 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
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@hSepFrac corner: 1@1) with: editString. window addMorph: mySingletonClassList fullFrame: ( LayoutFrame fractions: (0@0 corner: 0.5@0) offsets: (0@0 corner: 0@switchHeight) ). aBrowser addMorphicSwitchesTo: window at: ( LayoutFrame fractions: (0.5@0 corner: 1.0@0) offsets: (0@0 corner: 0@switchHeight) ). window addMorph: aBrowser buildMorphicMessageCatList fullFrame: ( LayoutFrame fractions: (0@0 corner: 0.5@hSepFrac) offsets: (0@switchHeight corner: 0@0) ). window addMorph: aBrowser buildMorphicMessageList fullFrame: ( LayoutFrame fractions: (0.5@0 corner: 1.0@hSepFrac) offsets: (0@switchHeight corner: 0@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
Correct, but this is not enough to advocate for the removal of the Browser as a "model" for the view. I believe you are both talking about the same thing, neither of you want to no have a "browser" model . The diff would be regarding the current implementation in Pharo. The model shouldn't know about the view, as in my previous mail, i was arguing that maybe the drawback of this approach is to have the model assemble the view. Thanks Benajamin for pdf detailing the idea, and Stef for the clarification. Current Browser class (model) would be the BrowserModel of your desing. But the VIEW responsibility would be in the BrowserMorph( VIEW). I imagine the same with the remaining tools? 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." 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 2) View on specialized views, moving the current functionality from the model to the view, that dont have model logic. 3) I suggest keeping the curent names, for instance, Browser is the model, BrowserMorph is the view ( in Morphic) 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@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@hSepFrac corner: 1@1)         with: editString.     window         addMorph: mySingletonClassList         fullFrame: (             LayoutFrame                 fractions: (0@0 corner: 0.5@0)                 offsets: (0@0 corner: 0@switchHeight)         ).
    aBrowser         addMorphicSwitchesTo: window         at: (             LayoutFrame                 fractions: (0.5@0 corner: 1.0@0)                 offsets: (0@0 corner: 0@switchHeight)         ).
    window         addMorph: aBrowser buildMorphicMessageCatList         fullFrame: (             LayoutFrame                 fractions: (0@0 corner: 0.5@hSepFrac)                 offsets: (0@switchHeight corner: 0@0)         ).
    window         addMorph: aBrowser buildMorphicMessageList         fullFrame: (             LayoutFrame                 fractions: (0.5@0 corner: 1.0@hSepFrac)                 offsets: (0@switchHeight corner: 0@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
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@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@hSepFrac corner: 1@1) with: editString. window addMorph: mySingletonClassList fullFrame: ( LayoutFrame fractions: (0@0 corner: 0.5@0) offsets: (0@0 corner: 0@switchHeight) ).
aBrowser addMorphicSwitchesTo: window at: ( LayoutFrame fractions: (0.5@0 corner: 1.0@0) offsets: (0@0 corner: 0@switchHeight) ).
window addMorph: aBrowser buildMorphicMessageCatList fullFrame: ( LayoutFrame fractions: (0@0 corner: 0.5@hSepFrac) offsets: (0@switchHeight corner: 0@0) ).
window addMorph: aBrowser buildMorphicMessageList fullFrame: ( LayoutFrame fractions: (0.5@0 corner: 1.0@hSepFrac) offsets: (0@switchHeight corner: 0@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
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@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@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@hSepFrac corner: 1@1)         with: editString.     window         addMorph: mySingletonClassList         fullFrame: (             LayoutFrame                 fractions: (0@0 corner: 0.5@0)                 offsets: (0@0 corner: 0@switchHeight)         ).
    aBrowser         addMorphicSwitchesTo: window         at: (             LayoutFrame                 fractions: (0.5@0 corner: 1.0@0)                 offsets: (0@0 corner: 0@switchHeight)         ).
    window         addMorph: aBrowser buildMorphicMessageCatList         fullFrame: (             LayoutFrame                 fractions: (0@0 corner: 0.5@hSepFrac)                 offsets: (0@switchHeight corner: 0@0)         ).
    window         addMorph: aBrowser buildMorphicMessageList         fullFrame: (             LayoutFrame                 fractions: (0.5@0 corner: 1.0@hSepFrac)                 offsets: (0@switchHeight corner: 0@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
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@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@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@hSepFrac corner: 1@1) with: editString. window addMorph: mySingletonClassList fullFrame: ( LayoutFrame fractions: (0@0 corner: 0.5@0) offsets: (0@0 corner: 0@switchHeight) ).
aBrowser addMorphicSwitchesTo: window at: ( LayoutFrame fractions: (0.5@0 corner: 1.0@0) offsets: (0@0 corner: 0@switchHeight) ).
window addMorph: aBrowser buildMorphicMessageCatList fullFrame: ( LayoutFrame fractions: (0@0 corner: 0.5@hSepFrac) offsets: (0@switchHeight corner: 0@0) ).
window addMorph: aBrowser buildMorphicMessageList fullFrame: ( LayoutFrame fractions: (0.5@0 corner: 1.0@hSepFrac) offsets: (0@switchHeight corner: 0@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
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@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@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@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@hSepFrac corner: 1@1)         with: editString.     window         addMorph: mySingletonClassList         fullFrame: (             LayoutFrame                 fractions: (0@0 corner: 0.5@0)                 offsets: (0@0 corner: 0@switchHeight)         ).
    aBrowser         addMorphicSwitchesTo: window         at: (             LayoutFrame                 fractions: (0.5@0 corner: 1.0@0)                 offsets: (0@0 corner: 0@switchHeight)         ).
    window         addMorph: aBrowser buildMorphicMessageCatList         fullFrame: (             LayoutFrame                 fractions: (0@0 corner: 0.5@hSepFrac)                 offsets: (0@switchHeight corner: 0@0)         ).
    window         addMorph: aBrowser buildMorphicMessageList         fullFrame: (             LayoutFrame                 fractions: (0.5@0 corner: 1.0@hSepFrac)                 offsets: (0@switchHeight corner: 0@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
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.
ok
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 -> TextMorph :) 4) SystemWindow 5) PluggableListMorph ( and maybe its variants)
Only one good one please (with multiselection, indentation, icons...)
MorphTreeMorph
---------- Tabbed pane the rest is extra :)
--------- Nautilus:
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@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@hSepFrac corner: 1@1) with: editString. window addMorph: mySingletonClassList fullFrame: ( LayoutFrame fractions: (0@0 corner: 0.5@0) offsets: (0@0 corner: 0@switchHeight) ).
aBrowser addMorphicSwitchesTo: window at: ( LayoutFrame fractions: (0.5@0 corner: 1.0@0) offsets: (0@0 corner: 0@switchHeight) ).
window addMorph: aBrowser buildMorphicMessageCatList fullFrame: ( LayoutFrame fractions: (0@0 corner: 0.5@hSepFrac) offsets: (0@switchHeight corner: 0@0) ).
window addMorph: aBrowser buildMorphicMessageList fullFrame: ( LayoutFrame fractions: (0.5@0 corner: 1.0@hSepFrac) offsets: (0@switchHeight corner: 0@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
participants (4)
-
Benjamin -
Fernando Olivero -
Stéphane Ducasse -
Torsten Bergmann