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 >>> <[email protected]> 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 >>>>> >>>> >>>> >>>> >>> >> >> >
