- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Regarding SimpleMorphic

by StÃ©phane Ducasse

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(a)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 >>>>> >>>> >>>> >>>> >>> >> >> >

April 1, 2011

Re: [Pharo-project] Issue 3920 in pharo: String has extension for *graphics

by pharo＠googlecode.com

Updates: Status: Closed Comment #2 on issue 3920 by marcus.d...(a)gmail.com: String has extension for *graphics http://code.google.com/p/pharo/issues/detail?id=3920 in 12125

April 1, 2011

Re: [Pharo-project] Issue 3922 in pharo: Add ClassHierarchy Checks

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3922 by marcus.d...(a)gmail.com: Add ClassHierarchy Checks http://code.google.com/p/pharo/issues/detail?id=3922 in 13125

April 1, 2011

[Pharo-project] Solarized Color Scheme

by Sven Van Caekenberghe

I remember there were some discussions about (theme / syntax highlighting) colors on this list in the past, and someone said that picking good colors is an art. I came across this site: http://ethanschoonover.com/solarized And it seems to me that this could be a good basis for a professional color scheme in one of Pharo's look and feels. As a fan / user of Glamorous, using the light theme on top of it would seem great. I am just posting this as a way to bookmark this link and because it might be useful. Solarized is MIT licensed. Sven

April 1, 2011

Re: [Pharo-project] Issue 3896 in pharo: 1.3 core has wrong theme enabled

by pharo＠googlecode.com

Updates: Status: FixToInclude Comment #1 on issue 3896 by marcus.d...(a)gmail.com: 1.3 core has wrong theme enabled http://code.google.com/p/pharo/issues/detail?id=3896 add the following to the next postscript: GLMUITheme beCurrent

April 1, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Benjamin

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(a)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(a)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 >>>>> >>>> >>>> >>>> >>> >> >> >

April 1, 2011

[Pharo-project] Dynamic Languages Symposium 2011: call for participation

by Theo D'Hondt

Dynamic Languages Symposium 2011 Co-located with SPLASH 2011 In association with ACM SIGPLAN Portland, Oregon, USA, October 24, 2011 http://www.dynamic-languages-symposium.org/dls-11/ *** Call for papers *** The 7th Dynamic Languages Symposium (DLS) at SPLASH 2011 is a forum for discussion of dynamic languages, their implementation and application. While mature dynamic languages including Smalltalk, Lisp, Scheme, Self, Prolog, and APL continue to grow and inspire new converts, a new generation of dynamic scripting languages such as Python, Ruby, PHP, Tcl, Lua, and JavaScript are successful in a wide range of applications. DLS provides a place for researchers and practitioners to come together and share their knowledge, experience, and ideas for future research and development. DLS 2011 invites high quality papers reporting original research, innovative contributions or experience related to dynamic languages, their implementation and application. Accepted Papers will be published in the ACM Digital Library. Areas of interest include but are not limited to: - Innovative language features and implementation techniques - Development and platform support, tools - Interesting applications - Domain-oriented programming - Very late binding, dynamic composition, and runtime adaptation - Reflection and meta-programming - Software evolution - Language symbiosis and multi-paradigm languages - Dynamic optimization - Hardware support - Experience reports and case studies - Educational approaches and perspectives - Object-oriented, aspect-oriented, and context-oriented programming * Submissions and proceedings * We invite original contributions that neither have been published previously nor are under review by other refereed events or publications. Research papers should describe work that advances the current state of the art. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. Accepted papers will be published in the ACM Digital Library. Papers are to be submitted electronically at http://www.easychair.org/conferences?conf=dls2011 in PDF format. Submissions must not exceed 12 pages and need to use the ACM format, templates for which can be found at http://www.acm.org/sigs/pubs/proceed/template.html. * Important dates * Submission of papers: June 17, 2011 (hard deadline) Author notification: July 19, 2011 Final versions due: August 19, 2011 DLS 2011: October 24, 2011 SPLASH 2011: October 22-27, 2011 * Program chair * Theo D'Hondt, Software Languages Lab, Vrije Universiteit Brussel, Belgium * Program committee * Andrew Black, Portland State University, USA William R. Cook, University of Texas at Austin, USA Marc Feeley, University of Montreal, Canada Roberto Ierusalimschy, PUC-Rio, Brazil Michele Lanza, University of Lugano, Switzerland Hidehiko Masuhara, University of Tokyo, Japan Mira Mezini, University of Darmstadt, Germany Mark Miller, Google, USA Manuel Serrano, INRIA Nice, France Laurence Tratt, Middlesex University, UK David Ungar, IBM, USA Didier Verna, EPITA Research and Development Laboratory, France ________________ Theo D'Hondt tjdhondt(a)vub.ac.be

April 1, 2011

Re: [Pharo-project] Issue 3929 in pharo: Package Filter for MC based repo browser

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3929 by Torsten....(a)astares.de: Package Filter for MC based repo browser http://code.google.com/p/pharo/issues/detail?id=3929 (No comment was entered for this change.)

April 1, 2011

[Pharo-project] Issue 3929 in pharo: Package Filter for MC based repo browser

by pharo＠googlecode.com

Status: Accepted Owner: Torsten....(a)astares.de Labels: Milestone-1.3 New issue 3929 by Torsten....(a)astares.de: Package Filter for MC based repo browser http://code.google.com/p/pharo/issues/detail?id=3929 This changeset adds a package filter to file based repository browser in Monticello. This makes it easier to find something in large repos like PharoInbox, ... Attachments: PackageFilterForMCFileRepositories.1.cs 2.1 KB packageFilter.png 17.2 KB

April 1, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Fernando Olivero

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(a)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(a)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 >>>> >>> >>> >>> >> > >

April 1, 2011