March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Regarding SimpleMorphic

by StÃ©phane Ducasse

On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > Model > TextModel > Workspace > PluggableTextModel > TextProvider > CodeProvider > Browser > HierarchyBrowser > Debugger > Inspector Why this hierarchy is wrong? Wheel Car We do not like that Car inherits from Wheel? We prefer to say Car has Weels So BrowserModel inherits from Model but not from TextModel BrowserModel has a textModel et other stuff A BrowserModel should not inherit from CodeProvider it has a code provider. Let us kill this StringHolder crap and be in 2010. Stef

March 31, 2011

[Pharo-project] Regarding SimpleMorphic

by Torsten Bergmann

>> 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'. 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

March 31, 2011

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

by pharo＠googlecode.com

Updates: Status: FixToInclude Labels: Milestone-1.3 Comment #1 on issue 3920 by marcus.d...(a)gmail.com: String has extension for *graphics http://code.google.com/p/pharo/issues/detail?id=3920 fix attached Attachments: FixPackage.1.cs 4.7 KB

March 31, 2011

[Pharo-project] Issue 3926 in pharo: MorphTreeMorph autoSelet

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com CC: aplan...(a)gmail.com Labels: Nautilus New issue 3926 by Benjamin...(a)gmail.com: MorphTreeMorph autoSelet http://code.google.com/p/pharo/issues/detail?id=3926 Like PluggableListMorph, when you start typing, it automatically shows the first entry that matches. The search is shown in a different color that the selection. Attachments: MorphTreeMorphAutoSelect.1.cs 7.2 KB

March 31, 2011

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

by pharo＠googlecode.com

Updates: Status: FixToInclude Labels: Milestone-1.3 Comment #2 on issue 3922 by marcus.d...(a)gmail.com: Add ClassHierarchy Checks http://code.google.com/p/pharo/issues/detail?id=3922 (No comment was entered for this change.)

March 31, 2011

[Pharo-project] [update 1.3] #13122

by StÃ©phane Ducasse

13122 ----- - Issue 3924: remove #scopeFor:from:envtAndPathIfFound:. - Issue 3925: PluggableIconListMorph improvment. Thanks Benjamin van ryseghem. Stef

March 31, 2011

Re: [Pharo-project] Issue 3925 in pharo: PluggableIconListMorph improvment

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3925 by stephane...(a)gmail.com: PluggableIconListMorph improvment http://code.google.com/p/pharo/issues/detail?id=3925 in 13122

March 31, 2011

Re: [Pharo-project] Issue 3924 in pharo: remove #scopeFor:from:envtAndPathIfFound:

by pharo＠googlecode.com

Updates: Status: Closed Comment #1 on issue 3924 by stephane...(a)gmail.com: remove #scopeFor:from:envtAndPathIfFound: http://code.google.com/p/pharo/issues/detail?id=3924 13122

March 31, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by StÃ©phane Ducasse

+ 1 :) So I like the discussion. It would be nice to have Views that do not inherit from model. :) So let us get real model. Stef > In CUIS the intent is to provide specialization on the model, And then >> each model holds the responsibility of creating the appropriate view >> (SystemWindow), by creating a composition of widgets. This is a subset >> of the model hierarchy, >> > >> 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. So why it inherits from Model ? > The same for Browser, HierarchyBrowser, Debugger, Inspector and so on... > > > Maybe it's better to have something like > > > > <BrowserInheritance.pdf> > > > > > >> >> From what i've understood, you want to do something similar, but >> instead specialize the "View", and have a single "model"? Did i >> understood correctly you intent? >> >> If that is the case, then i advice to look at CUIS before. I believe >> the arguments below are quite strong ones for the CUIS approach ( >> Specialized Model and Generic View). >> >> I believe this scheme is flexible and extensible, because you make the >> view "stupid", and specialize the model. You avoid polluting an unique >> class (for example the mess in CodeHolder), and put the behavior in >> the model( in the proper sublcass). And you make the view dont know >> about the model logic, because it's just a composition of widgets. The >> downside is that the model knows how to "assemble" the view. But this >> means that you put the interaction handling logic in a model, and can >> assemble many different views on the same model >> >> Please dont take it the wrong way, i'm favor of discussing before >> blindly porting CUIS code, but i would like to know more about the >> reason behind your approach. So we can clean and simplify the ugly >> parts of the system! > > > Do not worry about, I'm always open to discussion, and always happy to learn ;) > > > Ben > > >> >> Thanks, >> Fernando >> >> >> >> >> On Thu, Mar 31, 2011 at 1:28 PM, Benjamin >> <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>> >>> On Mar 31, 2011, at 10:50 AM, StÃ©phane Ducasse wrote: >>> >>>>> >>>>> 2) 4) Regarding TextModel and subclasses such as CodeProvider and >>>>> Browser in CUIS: so it means that hierarchy wouldn't be needed at all >>>>> in Pharo. At least Nautilus must have a model for the text ? In CUIS >>>>> the root class is called TextModel , in Pharo 1.3 is called >>>>> StringHolder. I propose moving this discussion on another thread. >>>>> Maybe Benjamin could clarify this? >>>> >>>> benjamin will let us know. >>> >>> I think that the text should be handled by a Browser but by the TextMorph, or you will have the same ugly hierarchy than StringHolder, when a Model/View are badly mixed and where each tool that manage source code inherits from it, without using properly inheritance ... >>> >>> IMHO, it should be orthogonal to that, and should be "pluggable" in each tool which need it. >>> >>> Right now for Nautilus, I have borrowed only 3-4 methods from StringHolder/CodeHolder/Browser, almost all expected behavior is provided by PluggableTextMorph >>> >>> >>> >>> Ben >>> >> >

March 31, 2011

[Pharo-project] Issue 3925 in pharo: PluggableIconListMorph improvment

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 3925 by Benjamin...(a)gmail.com: PluggableIconListMorph improvment http://code.google.com/p/pharo/issues/detail?id=3925 now, instead of be forced to provide a Form as icon, you can provide everything than can understand asMorph. Doing that, I keep the backward compatibility, and I allow user to provide by example an IconicButton as icon Attachments: PluggableIconListMorphImprovment.1.cs 1.5 KB

March 31, 2011