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

[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

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

by pharo＠googlecode.com

Comment #1 on issue 3921 by fernando...(a)gmail.com: due to *graphics package, we lost some string changes http://code.google.com/p/pharo/issues/detail?id=3921 In Issue 3584, i deprecated DisplayText and the use in string. I changed the implementation of displayOn:at:textColor: to not use asDisplayText, and call the Canvas drawString: method instead. (Based on CUIS implementation, that also removed the class DisplayText) I dont fully understand this issue, could you please clarify a bit?, i dont understand why it relates to *graphics package

March 31, 2011

Re: [Pharo-project] Issue 3918 in pharo: Package ST80 needs to be cleaned

by pharo＠googlecode.com

Updates: Status: FixProposed Labels: Milestone-1.3 Comment #1 on issue 3918 by marcus.d...(a)gmail.com: Package ST80 needs to be cleaned http://code.google.com/p/pharo/issues/detail?id=3918 fix attached Attachments: CleanST80.1.cs 16.9 KB

March 31, 2011

Re: [Pharo-project] Regarding SimpleMorphic

by Fernando Olivero

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 >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! 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 3921 in pharo: due to *graphics package, we lost some string changes

by pharo＠googlecode.com

Status: Accepted Owner: marcus.d...(a)gmail.com New 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 displayOn: aDisplayMedium at: aPoint textColor: aColor send asDisplayText which is not there.

March 31, 2011