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