- Pharo-dev - lists.pharo.org

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

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

by pharo＠googlecode.com

Status: FixToInclude Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3924 by marcus.d...(a)gmail.com: remove #scopeFor:from:envtAndPathIfFound: http://code.google.com/p/pharo/issues/detail?id=3924 ... very old method leftover from the nested Smalltalk Dictionaries experiment from the last century. Attachments: Clean.1.cs 163 bytes

March 31, 2011

[Pharo-project] Issue 3923 in pharo: #condenseChanges not working in 1.3

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New issue 3923 by marcus.d...(a)gmail.com: #condenseChanges not working in 1.3 http://code.google.com/p/pharo/issues/detail?id=3923 ... stops with a syntax error.

March 31, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Benjamin

On Mar 31, 2011, at 2:14 PM, Fernando Olivero wrote: > 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 > > 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

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

by pharo＠googlecode.com

Comment #1 on issue 3922 by camillob...(a)gmail.com: Add ClassHierarchy Checks http://code.google.com/p/pharo/issues/detail?id=3922 (No comment was entered for this change.) Attachments: ClassHierarchyTest.st 917 bytes

March 31, 2011

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

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3922 by camillob...(a)gmail.com: Add ClassHierarchy Checks http://code.google.com/p/pharo/issues/detail?id=3922 Verify all the classes in the system that superclass and subclass are set correctly: Attachments: ClassHierarchyTest.st 908 bytes

March 31, 2011

Re: [Pharo-project] Issue 3921 in pharo: due to *graphics package, we lost some string changes

by pharo＠googlecode.com

Comment #2 on issue 3921 by marcus.d...(a)gmail.com: due to *graphics package, we lost some string changes http://code.google.com/p/pharo/issues/detail?id=3921 So by having the method in *graphics, they are part of the Graphics package. But this package has no MC repository, so when saving the code, it was skipped. (there should be no *graphics package, there are muttiple graphics- packages, having an *graphics package in addition confuses Monticello completely...)

March 31, 2011