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
>
