- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Towards Pharo 1.0

by Hilaire Fernandes

I don't know how well tested/stable could be the closure change (expecially with third party packages as seaside, Magma or other DB backend) but if unsure it may be wise to keep it for a latter release, people may want first stability for a 1.0 to start productivity project with. Hilaire 2009/5/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >>> > > Hi guys > > Here are the discussions we forgot to get on the list :) > > > >> I was thinking that I would not do the license cleaning for 1.0 > > > > Yes, I agree. We can do this in 1.1, which can follow shortly after > > 1.0. Any objections from Marcus, Mike? > > > > What is the status of "Main EToys removal, reorganize > > MorphicExtras-"? Do you plan to do more for 1.0? > > > > Apart from that we have left on our list ( > http://code.google.com/p/pharo/wiki/Milestones > > ): > > > > - default in-image font(s) > > - Package management system with stable and unstable distributions > > - Remove SqueakMap and Installer from core > > > > - All tests green > > - Clean up package and class category organization > > - Pharo one-click image (including developer tools, GettingStarted > > information, screenshots, ...) > > - New sources file > > > > Are we going to integrate the new preference system/browser in 1.0? > > > >> Now we are waiting for eliot closures changes. > > > > What kind of changes are theses? Did he say something about when > > they will be ready? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://blog.ofset.org/hilaire

May 11, 2009

[Pharo-project] Traits Merging problem

by StÃ©phane Ducasse

Hi I want to report that if you try to merge code containing traits you get a DNU. I get a reproduceable bug: try to merge the collectiontext in the PharoTaskForces project. Stef

May 11, 2009

Re: [Pharo-project] Error when trying to create a package

by Keith Hodges

Alexandre Bergel wrote: > The temporary variable is there in case that Installer is not > installed. It assumes that ScriptLoader is present. > > Cheers, > Alexandre > Installer is intended to be the first and only dependency in a minimal system. i.e. you are using ScriptLoader to do Installer's job Keith

May 11, 2009

Re: [Pharo-project] Error when trying to create a package

by Keith Hodges

Alexandre Bergel wrote: > This is what we've been doing for long time... > > Alexandre > > > Yes I know, that's why it is so annoying. Keith

May 11, 2009

[Pharo-project] Questions about the debugger

by Hernan Wilkinson

Hi, I'd like to be able to open the debugger without the notifier... when programming the notifier does help really (at least to me...). I modified StandarToolSet class>>debugError: anError to pass true as parameter to the full: keyword of #debug:title:full, but I was wondering if there was a preference to do this whitout modifying the code. Also, what does the class OTToolset do? The DevToolSet delegates to it the messages when installed, but the pharo image does not have it install. And the last question!, I'd like the debugger to open in a bigger window. I know I can press the "expand to full screen" button, but I'd like the debugger window to be 3/4 of the screen when opened automatically. I did not find a way to configure that... does it exist? if not, what is the message I should send to the debugger morph to do that? Thanks! Hernan

May 11, 2009

[Pharo-project] RBNamespace does not like Trait ?

by FranÃ§ois Tanguy

Hello, no class is created when sending defineClass: message to an RBNamespace instance with the following class string definition Object subclass: #SCElement uses: {TPrintable} instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: #'SC' Having a quick look to the implementation, RBNamespace does not like Trait... Francois

May 11, 2009

Re: [Pharo-project] Preferences -> Settings: #browsing group

by StÃ©phane Ducasse

On May 11, 2009, at 11:44 AM, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> Thanks this is cool to have such an evaluation. >> I would love that we start to refactor the system so that at the end >> we could unload >> preferences (this would show that the flow of a program does use a >> preference but does not >> rely on the class Preference) > ok this is exactly the goal here. > Replace global preferences by local settings. > Setting of the #browsing group can be defined locally in the > CodeHolder > class or in a new ToolsSetting class created in the Tools package. good question. I have the impression that local would mean in codeHolder package so may be in CodeHolder > > what do you prefer ? > alain > >> >> Stef >> >>> >>> Below are listed all old preferences of the #browsing group. >>> For each one, its name is shown with the comment that we can read >>> from >>> the preference browser. >>> Then I've added and 'action' (remove or keep it). >>> If kept, I've also added a possible new setting declaration. >>> >>> Could you read it carefully and give your point of view about the >>> desired action. >>> Thanks >>> Alain >>> >>> >>> ------------------------------------------------ >>> ------------------------------------------------ >>> >>> alternativeBrowseIt : >>> "if true cmd-b offers a list of class names matching selection" >>> >>> >>> action: remove it because this feature is always desired >>> >>> ----------------------------------- >>> >>> >>> annotationPanes: >>> "if true, a thin horizontal pane is used in browsers" >>> >>> >>> action: don't know because the annotation pane seems not correctly >>> updated by browsers. However, it is correctly updated by >>> MessageSet. >>> >>> if kept: >>> >>> CodeHolder class>>annotationPane >>> >>> <setting> >>> >>> ^ AnnotationPane ifNil: [AnnotationPane := (SettingManager >>> newSetting: 'Annotation pane') >>> default: false; >>> parent: #browsing; >>> description: 'If true, a thin horizontal annotation pane is >>> used >>> in browsers. When a method is selected, then the pane is updated >>> with >>> useful informations about the method'] >>> >>> ----------------------------------- >>> >>> >>> balloonHelpInMessageLists: >>> "If true, then message-list browsers in Morphic will show balloon >>> help, >>> consisting of the first comment of the method or of a superclass" >>> >>> >>> action: would remove it. didn't succeed in making it work. Serves >>> as a >>> value for a Morph property #balloonTextSelectorForSubMorphs. This >>> property is used by PluggableListMorph>>list: which has following >>> comment: >>> >>> "lex doesn't think this is used any longer, but is not yet brave >>> enough >>> to remove it. It should be removed eventually" >>> >>> ------------------------------------ >>> >>> >>> browseWithPrettyPrint >>> "If true, browsers will automatically format their contents" >>> >>> >>> action: keep it ? >>> CodeHolder class>>browseWithPrettyPrint >>> <setting> >>> ^BrowseWithPrettyPrint ifNil: [BrowseWithPrettyPrint := >>> (SettingManager newSetting: 'Pretty print') >>> default: false; >>> parent: #browsing; >>> description: 'If true, browsers will automatically format >>> their contents'] >>> >>> question: do we really need style for code file out ? >>> (problem: >>> used by Text>>askIfAddStyle: priorMethod req: requestor send by >>> ClassDescription and TraitDescription) >>> ->would introduce a dependence from Text to CodeHolder). >>> >>> ------------------------------------ >>> >>> >>> colorWhenPrettyPrinting:"If true, then when browseWithPrettyPrint >>> is in >>> effect, the pretty-printing will be presented in color" >>> action: remove it ? >>> >>> No effect anymore on pharo-core browsers >>> >>> ------------------------------------ >>> >>> >>> decorateBrowserButtons: "Governs whether certain buttons, such as >>> the >>> Inheritance button, should bear colors that provide user feedback on >>> their applicability" >>> action: maybe remove it ? >>> >>> such a feedback is now provided by OB-browser with its icon set. >>> >>> ------------------------------------ >>> >>> diffsInChangeList: "If true, changeList browsers and Versions >>> browsers >>> will open up by default showing diffs, i.e. revealing the >>> differences >>> between successive versions or between the in-memory code and the >>> code >>> on disk" >>> >>> action: keep it ? >>> >>> CodeHolder class>>showDifferencesInChangeList >>> <setting> >>> ^ ShowDifferencesInChangeList ifNil: >>> [ShowDifferencesInChangeList := >>> (SettingManager newSetting: 'Show differences in ChangeList') >>> default: true; >>> parent: #browsing; >>> description: 'If true, changeList browsers and Versions >>> browsers will open up by default showing diffs, i.e. revealing the >>> differences between successive versions or between the in-memory >>> code >>> and the code on disk'] >>> >>> ------------------------------------ >>> >>> >>> diffsWithPrettyPrint: "if true, displays of source code >>> differences will >>> be pretty-printed first" >>> action: keep it ? >>> >>> CodeHolder class>>prettyPrintDifferences >>> <setting> >>> ^ PrettyPrintDifferences ifNil: [PrettyPrintDifferences := >>> (SettingManager newSetting: 'Pretty print differences') >>> default: false; >>> parent: #browsing; >>> description: 'if true, displays of source code differences >>> will be pretty-printed first'] >>> >>> ------------------------------------ >>> >>> >>> optionalButtons: "If true, then optional buttons will be used in >>> certain >>> standard tools, including browsers, message lists, fileLists, >>> changeLists, and debuggers" >>> action: remove it ? >>> because it is always used >>> >>> ------------------------------------ >>> >>> >>> smartUpdating: "If true, then morphic tools such as browsers and >>> inspectors will keep their contents up to date automatically, so >>> that if >>> something changes anywhere, the change will be reflected >>> everywhere." >>> action: keep it ? >>> >>> true by default, when do we set this to false ? >>> CodeHolder class>>smartUpdating >>> <setting> >>> ^ SmartUpdating ifNil: [SmartUpdating := (SettingManager >>> newSetting: >>> 'Smart updating') >>> default: true; >>> parent: #browsing; >>> description: 'If true, then morphic tools such as browsers >>> and inspectors will keep their contents up to date automatically, so >>> that if something changes anywhere, the change will be reflected >>> everywhere.'] >>> >>> ------------------------------------ >>> >>> >>> useNewDiffToolsForMC: "When enabled the Polymorph diff tools will be >>> used with Monticello. When diabled, the original tools are used." >>> action: remove it ? >>> >>> Should it be a setting ? >>> What is wrong with the new diff tool ? >>> >>> ------------------------------------ >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 11, 2009

Re: [Pharo-project] Preferences -> Settings: #browsing group

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > Thanks this is cool to have such an evaluation. > I would love that we start to refactor the system so that at the end > we could unload > preferences (this would show that the flow of a program does use a > preference but does not > rely on the class Preference) ok this is exactly the goal here. Replace global preferences by local settings. Setting of the #browsing group can be defined locally in the CodeHolder class or in a new ToolsSetting class created in the Tools package. what do you prefer ? alain > > Stef > >> >> Below are listed all old preferences of the #browsing group. >> For each one, its name is shown with the comment that we can read from >> the preference browser. >> Then I've added and 'action' (remove or keep it). >> If kept, I've also added a possible new setting declaration. >> >> Could you read it carefully and give your point of view about the >> desired action. >> Thanks >> Alain >> >> >> ------------------------------------------------ >> ------------------------------------------------ >> >> alternativeBrowseIt : >> "if true cmd-b offers a list of class names matching selection" >> >> >> action: remove it because this feature is always desired >> >> ----------------------------------- >> >> >> annotationPanes: >> "if true, a thin horizontal pane is used in browsers" >> >> >> action: don't know because the annotation pane seems not correctly >> updated by browsers. However, it is correctly updated by MessageSet. >> >> if kept: >> >> CodeHolder class>>annotationPane >> >> <setting> >> >> ^ AnnotationPane ifNil: [AnnotationPane := (SettingManager >> newSetting: 'Annotation pane') >> default: false; >> parent: #browsing; >> description: 'If true, a thin horizontal annotation pane is used >> in browsers. When a method is selected, then the pane is updated with >> useful informations about the method'] >> >> ----------------------------------- >> >> >> balloonHelpInMessageLists: >> "If true, then message-list browsers in Morphic will show balloon help, >> consisting of the first comment of the method or of a superclass" >> >> >> action: would remove it. didn't succeed in making it work. Serves as a >> value for a Morph property #balloonTextSelectorForSubMorphs. This >> property is used by PluggableListMorph>>list: which has following >> comment: >> >> "lex doesn't think this is used any longer, but is not yet brave enough >> to remove it. It should be removed eventually" >> >> ------------------------------------ >> >> >> browseWithPrettyPrint >> "If true, browsers will automatically format their contents" >> >> >> action: keep it ? >> CodeHolder class>>browseWithPrettyPrint >> <setting> >> ^BrowseWithPrettyPrint ifNil: [BrowseWithPrettyPrint := >> (SettingManager newSetting: 'Pretty print') >> default: false; >> parent: #browsing; >> description: 'If true, browsers will automatically format >> their contents'] >> >> question: do we really need style for code file out ? >> (problem: >> used by Text>>askIfAddStyle: priorMethod req: requestor send by >> ClassDescription and TraitDescription) >> ->would introduce a dependence from Text to CodeHolder). >> >> ------------------------------------ >> >> >> colorWhenPrettyPrinting:"If true, then when browseWithPrettyPrint is in >> effect, the pretty-printing will be presented in color" >> action: remove it ? >> >> No effect anymore on pharo-core browsers >> >> ------------------------------------ >> >> >> decorateBrowserButtons: "Governs whether certain buttons, such as the >> Inheritance button, should bear colors that provide user feedback on >> their applicability" >> action: maybe remove it ? >> >> such a feedback is now provided by OB-browser with its icon set. >> >> ------------------------------------ >> >> diffsInChangeList: "If true, changeList browsers and Versions browsers >> will open up by default showing diffs, i.e. revealing the differences >> between successive versions or between the in-memory code and the code >> on disk" >> >> action: keep it ? >> >> CodeHolder class>>showDifferencesInChangeList >> <setting> >> ^ ShowDifferencesInChangeList ifNil: [ShowDifferencesInChangeList := >> (SettingManager newSetting: 'Show differences in ChangeList') >> default: true; >> parent: #browsing; >> description: 'If true, changeList browsers and Versions >> browsers will open up by default showing diffs, i.e. revealing the >> differences between successive versions or between the in-memory code >> and the code on disk'] >> >> ------------------------------------ >> >> >> diffsWithPrettyPrint: "if true, displays of source code differences will >> be pretty-printed first" >> action: keep it ? >> >> CodeHolder class>>prettyPrintDifferences >> <setting> >> ^ PrettyPrintDifferences ifNil: [PrettyPrintDifferences := >> (SettingManager newSetting: 'Pretty print differences') >> default: false; >> parent: #browsing; >> description: 'if true, displays of source code differences >> will be pretty-printed first'] >> >> ------------------------------------ >> >> >> optionalButtons: "If true, then optional buttons will be used in certain >> standard tools, including browsers, message lists, fileLists, >> changeLists, and debuggers" >> action: remove it ? >> because it is always used >> >> ------------------------------------ >> >> >> smartUpdating: "If true, then morphic tools such as browsers and >> inspectors will keep their contents up to date automatically, so that if >> something changes anywhere, the change will be reflected everywhere." >> action: keep it ? >> >> true by default, when do we set this to false ? >> CodeHolder class>>smartUpdating >> <setting> >> ^ SmartUpdating ifNil: [SmartUpdating := (SettingManager newSetting: >> 'Smart updating') >> default: true; >> parent: #browsing; >> description: 'If true, then morphic tools such as browsers >> and inspectors will keep their contents up to date automatically, so >> that if something changes anywhere, the change will be reflected >> everywhere.'] >> >> ------------------------------------ >> >> >> useNewDiffToolsForMC: "When enabled the Polymorph diff tools will be >> used with Monticello. When diabled, the original tools are used." >> action: remove it ? >> >> Should it be a setting ? >> What is wrong with the new diff tool ? >> >> ------------------------------------ >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > >

May 11, 2009

Re: [Pharo-project] Capturing window events

by Alexandre Bergel

Ok. I will propose something in the next few days. Alexandre On 11 May 2009, at 11:14, David RÃ¶thlisberger wrote: > Hi Alex, > >> Is there an easy way to capture windows related events such as >> resizing and hiding ? > > I was seeking for the same things just last week... > For collapsing and expanding using the tool buttons in the window's > task bar, the > methods #collapse and #expand of SystemWindow get executed. > > Resizing and moving with the mouse is more difficult to intercept. > The best way I found was to hook into #doFastWindowReframe: > (resizing) and > #doFastFrameDrag: (moving). > I had to override these methods to send a notification to my stuff. > Not the best way, > so enhancing SystemWindow to announce resizing, moving, maybe also > expanding, > collapsing, closing, etc. would be better. > > David > >> I do not have the feeling this is supported currently. One way to >> implement this I guess, is to redefine the method >> SystemWindow>>extent: to emit an instance of a subclass of >> Announcement, which could be named MorphicWindowResize. >> >> I plan to do this for Mondrian, but maybe this is of an interest to >> GUI guys. >> >> Any comment before I proceed? >> >> Cheers, >> Alexandre >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 11, 2009

Re: [Pharo-project] Preferences -> Settings: #browsing group

by StÃ©phane Ducasse

Thanks this is cool to have such an evaluation. I would love that we start to refactor the system so that at the end we could unload preferences (this would show that the flow of a program does use a preference but does not rely on the class Preference) Stef > > Below are listed all old preferences of the #browsing group. > For each one, its name is shown with the comment that we can read from > the preference browser. > Then I've added and 'action' (remove or keep it). > If kept, I've also added a possible new setting declaration. > > Could you read it carefully and give your point of view about the > desired action. > Thanks > Alain > > > ------------------------------------------------ > ------------------------------------------------ > > alternativeBrowseIt : > "if true cmd-b offers a list of class names matching selection" > > > action: remove it because this feature is always desired > > ----------------------------------- > > > annotationPanes: > "if true, a thin horizontal pane is used in browsers" > > > action: don't know because the annotation pane seems not correctly > updated by browsers. However, it is correctly updated by MessageSet. > > if kept: > > CodeHolder class>>annotationPane > > <setting> > > ^ AnnotationPane ifNil: [AnnotationPane := (SettingManager > newSetting: 'Annotation pane') > default: false; > parent: #browsing; > description: 'If true, a thin horizontal annotation pane is > used > in browsers. When a method is selected, then the pane is updated with > useful informations about the method'] > > ----------------------------------- > > > balloonHelpInMessageLists: > "If true, then message-list browsers in Morphic will show balloon > help, > consisting of the first comment of the method or of a superclass" > > > action: would remove it. didn't succeed in making it work. Serves as a > value for a Morph property #balloonTextSelectorForSubMorphs. This > property is used by PluggableListMorph>>list: which has following > comment: > > "lex doesn't think this is used any longer, but is not yet brave > enough > to remove it. It should be removed eventually" > > ------------------------------------ > > > browseWithPrettyPrint > "If true, browsers will automatically format their contents" > > > action: keep it ? > CodeHolder class>>browseWithPrettyPrint > <setting> > ^BrowseWithPrettyPrint ifNil: [BrowseWithPrettyPrint := > (SettingManager newSetting: 'Pretty print') > default: false; > parent: #browsing; > description: 'If true, browsers will automatically format > their contents'] > > question: do we really need style for code file out ? > (problem: > used by Text>>askIfAddStyle: priorMethod req: requestor send by > ClassDescription and TraitDescription) > ->would introduce a dependence from Text to CodeHolder). > > ------------------------------------ > > > colorWhenPrettyPrinting:"If true, then when browseWithPrettyPrint is > in > effect, the pretty-printing will be presented in color" > action: remove it ? > > No effect anymore on pharo-core browsers > > ------------------------------------ > > > decorateBrowserButtons: "Governs whether certain buttons, such as the > Inheritance button, should bear colors that provide user feedback on > their applicability" > action: maybe remove it ? > > such a feedback is now provided by OB-browser with its icon set. > > ------------------------------------ > > diffsInChangeList: "If true, changeList browsers and Versions browsers > will open up by default showing diffs, i.e. revealing the differences > between successive versions or between the in-memory code and the code > on disk" > > action: keep it ? > > CodeHolder class>>showDifferencesInChangeList > <setting> > ^ ShowDifferencesInChangeList ifNil: > [ShowDifferencesInChangeList := > (SettingManager newSetting: 'Show differences in ChangeList') > default: true; > parent: #browsing; > description: 'If true, changeList browsers and Versions > browsers will open up by default showing diffs, i.e. revealing the > differences between successive versions or between the in-memory code > and the code on disk'] > > ------------------------------------ > > > diffsWithPrettyPrint: "if true, displays of source code differences > will > be pretty-printed first" > action: keep it ? > > CodeHolder class>>prettyPrintDifferences > <setting> > ^ PrettyPrintDifferences ifNil: [PrettyPrintDifferences := > (SettingManager newSetting: 'Pretty print differences') > default: false; > parent: #browsing; > description: 'if true, displays of source code differences > will be pretty-printed first'] > > ------------------------------------ > > > optionalButtons: "If true, then optional buttons will be used in > certain > standard tools, including browsers, message lists, fileLists, > changeLists, and debuggers" > action: remove it ? > because it is always used > > ------------------------------------ > > > smartUpdating: "If true, then morphic tools such as browsers and > inspectors will keep their contents up to date automatically, so > that if > something changes anywhere, the change will be reflected everywhere." > action: keep it ? > > true by default, when do we set this to false ? > CodeHolder class>>smartUpdating > <setting> > ^ SmartUpdating ifNil: [SmartUpdating := (SettingManager > newSetting: > 'Smart updating') > default: true; > parent: #browsing; > description: 'If true, then morphic tools such as browsers > and inspectors will keep their contents up to date automatically, so > that if something changes anywhere, the change will be reflected > everywhere.'] > > ------------------------------------ > > > useNewDiffToolsForMC: "When enabled the Polymorph diff tools will be > used with Monticello. When diabled, the original tools are used." > action: remove it ? > > Should it be a setting ? > What is wrong with the new diff tool ? > > ------------------------------------ > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 11, 2009