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