- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Loading Polymorph

by StÃ©phane Ducasse

I will try to see what I can do to load it. Stef > Latest Polymorph-Widgets versions (from 41 to 42) require the MC > workaround to load/merge, unfortunately. > Anything down to drawing... in this case the change to dropShadows. > > Regards, Gary > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 15, 2009

Re: [Pharo-project] LogicalFont deepCopy infinite loop with Arial font

by StÃ©phane Ducasse

Alain It would be nice to redesign completely preferences. Did you read the thread Re: [Pharo-project] About Preference Flow of 4 of Feb ? Summary here Instead of having the current situation ie MyTool>>doSomething .... Preferences useNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj] and not been able to remove the preferences (or that the preference is just a configuration layer). I would like to have the preference made that way MyTool class>>useNewDiff MyTool class>> useOldDiff **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! Preferences useNewDiffTool MyTool useNewDiff I like the idea of lukas to use pragmas. Why not use pragmas on accessors of the class side that would be picked up by the preference browser? Then all state would be local to the affected code. Something along these lines: MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean <preference: 'Show advanced diff tool' group: 'Monticello' type: #Boolean> advancedDiffTool := aBoolean >>> Hi all, > Here is a changeset with a new version of the PreferencesBrowser. > It is for testing. I can improve it a little bit > (by including display depth, desktop color, gradient color and > author initials) > and provide a slice if it is ok. > > I've investigated how preferences are implemented and it seems to me > that > current situation is the result of succesives hacks. > I would like to clean out this part of the system. > I will provide a roadmap before any coding. > Can I start working on it ? > > Cheers > alain >>> >>>> On 11 Feb 2009, at 16:22, Alain Plantec wrote: >>>> >>>> >>>>> Hi all, >>>>> I would like to improve the PreferencesBrowser so that it includes >>>>> standard Fonts preferences (see joined snapshot). >>>>> It's almost done except that, if a preference font is set to >>>>> Arial, >>>>> clicking on Save button leads to an infinite loop. >>>>> >>>>> To reproduce it, set button font to Arial-12 and >>>>> Preferences standardButtonFont deepCopy. >>>>> >>>>> Cheers >>>>> alain >>>>> < >>>>> FontsInPreferences >>>>> .png >>>>> >>>>>> <FTFdeepcopy.png>_______________________________________________ >>>>>> >>>>> 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 >>> >>> >> >> > > <PBFont.8.cs.gz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 15, 2009

Re: [Pharo-project] [ANN] 10234 SmallLint cleaning

by StÃ©phane Ducasse

On Feb 14, 2009, at 6:59 PM, Igor Stasenko wrote: > 2009/2/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> addressed or tagged as addressed >> >> Issue 523: [SmallLint] Undeclared variables >> This check is similar to the "References an undeclared variable" >> check, but it looks for variables that >> are not defined in the class or in the undeclared dictionary. You >> probably had to work hard to get >> your code in this state. >> >> PasteUpMorph>>#makeNewDrawing:at: >> Project>>#storeSegmentNoFile > > not sure about the rest methods, but these two showing that people > worked hard to get code in this state. > or maybe its my brain is too small to fit such amount of code in > attempt to understand it. Indeed this is why I tagged the code as "let us let it like that " > > >> CollectionRootTest>>#nonEmpty >> ScriptLoader>>#update10196 >> ScriptLoader>>#update10074 >> >> Issue 525: useless boolean checks on Morphic extras >> MorphicExtras Check for a =, ==, ~=, or ~~ message being sent >> to true/ >> false or with true/false as the argument. >> SqueakPage>>#write >> URLMorph>>#mouseUp: >> ClockMorph>>#addCustomMenuItems:hand: >> ClockMorph>>#step >> ClockMorph>>#toggleShowingSeconds >> ClockMorph>>#toggleShowing24hr >> MorphObjectOut>>#doesNotUnderstand: >> SketchEditorMorph>>#verifyState: >> SketchEditorMorph>>#deliverPainting:evt: >> FlapTab>>#inboard >> FlapTab>>#flapShowing >> FlapTab>>#tabSelected >> ReferenceMorph>>#isHighlighted >> SimpleSliderMorph>>#truncate >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 15, 2009

Re: [Pharo-project] unnecessary =, == :)

by StÃ©phane Ducasse

yes this is why we cannot do that automatically and this is also why we should tag the method with pragma http://code.google.com/p/pharo/wiki/SmallLintPharoFixing so that SmallLint will not report them again and again Stef > Sometimes i using ivars , which going to hold boolean value only , but > i leave it to be initialized later > so, a value of variable could be nil, true, false. > Accessor, however alway returns a boolean, but depending of default > value it could look like: > ^ myvar == true > > or > ^ myvar == false > > > > 2009/2/14 Gary Chambers <gazzaguru2(a)btinternet.com>: >> SystemWindow>>#mouseDown: (actually needed, on first call that >> property will >> almost certainly be nil, set later in the method). >> >> Regards, Gary >> >> >> ----- Original Message ----- >> From: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, February 14, 2009 5:12 PM >> Subject: Re: [Pharo-project] unnecessary =, == :) >> >> >> PluggableTextMorph>>#accept (sadly required defence against text >> setters >> that don't return a boolean) >> SystemWindow>>#mouseDown: (removed offending line, now obsolete, >> apparently) >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, February 14, 2009 3:23 PM >> Subject: [Pharo-project] unnecessary =, == :) >> >> >>> Check for a =, ==, ~=, or ~~ message being sent to true/false or >>> with >>> true/false as the argument. Many times these can be eliminated since >>> their receivers are already booleans. For example, "anObject isFoo >>> == >>> false" could be replaced with "anObject isFoo not" if isFoo always >>> returns a boolean. Sometimes variables might refer to true, false, >>> and >>> something else, but this is considered bad style since the variable >>> has multiple types. >>> >>> Project>>#setChangeSet: >>> Project>>#isolationSet >>> Project>>#compileAll:from: >>> Project>>#writeFileNamed:fromDirectory:toServer: >>> Project>>#isolationHead >>> PNGReadWriter>>#debugging >>> ClockMorph>>#addCustomMenuItems:hand: >>> ClockMorph>>#step >>> ClockMorph>>#toggleShowingSeconds >>> ClockMorph>>#toggleShowing24hr >>> WorldState>>#interCyclePause: >>> Integer>>#quo: >>> Integer>>#digitSubtract: >>> SimpleServiceEntry>>#useLineAfter >>> MorphicUIManager>>#interactiveParserFor: >>> OBPluggableListMorph>>#mouseUp: >>> PianoRollScoreMorph>>#addCustomMenuItems:hand: >>> SystemDictionary>>#abandonSources >>> SystemDictionary>>#internalizeSources >>> SystemDictionary>>#internalizeChangeLog >>> SetTest>>#testRemoveIfAbsent >>> SimpleButtonDelayedMenuMorph>>#mouseUp: >>> Installer>>#validate >>> Installer>>#logErrorDuring: >>> SketchEditorMorph>>#verifyState: >>> SketchEditorMorph>>#deliverPainting:evt: >>> SketchMorph>>#useInterpolation: >>> Slider>>#descending >>> JoystickMorph>>#autoCenterString >>> JoystickMorph>>#button1 >>> JoystickMorph>>#button2 >>> SARInstaller>>#errorNoSuchMember: >>> MessageSet>>#growable >>> HandMorph>>#handleEvent: >>> HandMorph>>#fullDrawOn: >>> ImageSegment>>#declareAndPossiblyRename: >>> PluggableListMorphPlus>>#wantsDroppedMorph:event: >>> SUnitTest>>#testRanOnlyOnce >>> BitmapFillStyle>>#isTiled >>> InstallerMonticello>>#mcDetectFileBlock >>> FTPClient>>#login >>> Object>>#mustBeBooleanIn: >>> Object>>#'~=' >>> Decompiler>>#pushConstant: >>> TextMorphForEditView>>#acceptOnCR >>> HostSystemMenusMenuItem>>#shift >>> FlapTab>>#inboard >>> FlapTab>>#flapShowing >>> FlapTab>>#tabSelected >>> PluggableTreeMorph>>#wantsDroppedNode:on: >>> DisplayScreen>>#deferUpdates: >>> OBSystemBrowser>>#defaultBackgroundColor >>> SmalltalkImage>>#setPlatformPreferences >>> SmalltalkImage>>#snapshot:andQuit:embedded: >>> URLMorph>>#mouseUp: >>> MultiNewParagraph >>> >>#multiComposeLinesFrom:to:delta:into:priorLines:atY: >>> Collection>>#reject: >>> TextDiffBuilder>>#hasMultipleMatches >>> TrueTest>>#testNot >>> TrueTest>>#testInMemory >>> TrueTest>>#testAND >>> MCFileBasedRepository>>#possiblyNewerVersionsOfAnyOf: >>> Process>>#terminate >>> ProtoObjectTest>>#testIsNil >>> SqueakPage>>#write >>> ColorPickerMorph>>#putUpFor:near: >>> FalseTest>>#testAnd >>> FalseTest>>#testOR >>> FalseTest>>#testNot >>> FalseTest>>#testAND >>> UpdatingStringMorph>>#growable >>> UpdatingStringMorph>>#autoAcceptOnFocusLoss >>> LanguageEditor>>#selectedTranslationsAt:put: >>> Socket>>#setOption:value: >>> MultiCompositionScanner>>#setFont >>> PositionableStream>>#unCommand >>> HTTPSocket>>#logToTranscript >>> Number>>#odd >>> OBHierarchyBrowser>>#defaultBackgroundColor >>> MorphExtension>>#isDefault >>> MorphExtension>>#sortedPropertyNames >>> MorphExtension>>#printOn: >>> MorphExtension>>#hasProperty: >>> ObjectOut>>#doesNotUnderstand: >>> PluggableTextMorph>>#hasEditingConflicts >>> PluggableTextMorph>>#accept >>> SimpleSliderMorph>>#truncate >>> OBProtocolBrowser>>#defaultBackgroundColor >>> SystemWindow>>#mustNotClose >>> SystemWindow>>#mouseDown: >>> RBReadBeforeWrittenTester>>#read >>> RBReadBeforeWrittenTester>>#processBlock: >>> RBReadBeforeWrittenTester>>#processStatementNode: >>> RBReadBeforeWrittenTester>>#processIfTrueIfFalse: >>> GradientFillStyle>>#isRadialFill >>> RefactoryTyper>>#typeFor: >>> CompiledMethodTest>>#testValueWithReceiverArguments >>> OBLazyListMorph>>#handleMouseMove: >>> BlockContextTest>>#testSupplyAnswerThroughNestedBlocks >>> BlockContextTest>>#testSupplyAnswerUsingTraditionalMatchOfQuestion >>> BlockContextTest>>#testSupplySameAnswerToAllQuestions >>> BlockContextTest>>#testSupplyAnswerUsingOnlySubstringOfQuestion >>> BlockContextTest>>#testSupplySpecificAnswerToQuestion >>> BlockContextTest>>#testSupplyAnswerUsingRegexMatchOfQuestion >>> ImageMorph>>#isOpaque: >>> ProjectSwikiServer>>#acceptsUploads >>> PolygonMorph>>#rotateTestFlip: >>> PolygonMorph>>#beStraightSegments >>> PolygonMorph>>#beSmoothCurve >>> BitBlt>>#drawFrom:to:withFirstPoint: >>> FileList>>#getSelectedDirectory >>> FileList>>#getSelectedFile >>> RBParser>>#patchLiteralMessage >>> OBMultipleSelectionColumn>>#listSelectionAt:put: >>> ServerDirectory>>#upLoadProject:members:retry: >>> MorphObjectOut>>#doesNotUnderstand: >>> HaloMorph>>#addHandles >>> ThumbnailImageMorph>>#togglePopupFeature >>> ThumbnailImageMorph>>#handlesMouseDown: >>> ThumbnailImageMorph>>#popupFeatureString >>> ContextPart>>#jump:if: >>> MCWorkingCopy>>#merge: >>> FileDoesNotExistException>>#readOnly >>> RBLiteralNodeTest>>#testValue >>> Prefer... >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 15, 2009

Re: [Pharo-project] unnecessary =, == :)

by StÃ©phane Ducasse

gary do you use <lint: 'Long methods' rationale: 'Rendering method' author: 'lr'> to tag the method you checked? http://code.google.com/p/pharo/wiki/SmallLintPharoFixing Stef On Feb 14, 2009, at 6:14 PM, Gary Chambers wrote: > SystemWindow>>#mouseDown: (actually needed, on first call that > property will > almost certainly be nil, set later in the method). > > Regards, Gary > > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 5:12 PM > Subject: Re: [Pharo-project] unnecessary =, == :) > > > PluggableTextMorph>>#accept (sadly required defence against text > setters > that don't return a boolean) > SystemWindow>>#mouseDown: (removed offending line, now obsolete, > apparently) > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 3:23 PM > Subject: [Pharo-project] unnecessary =, == :) > > >> Check for a =, ==, ~=, or ~~ message being sent to true/false or with >> true/false as the argument. Many times these can be eliminated since >> their receivers are already booleans. For example, "anObject isFoo == >> false" could be replaced with "anObject isFoo not" if isFoo always >> returns a boolean. Sometimes variables might refer to true, false, >> and >> something else, but this is considered bad style since the variable >> has multiple types. >> >> Project>>#setChangeSet: >> Project>>#isolationSet >> Project>>#compileAll:from: >> Project>>#writeFileNamed:fromDirectory:toServer: >> Project>>#isolationHead >> PNGReadWriter>>#debugging >> ClockMorph>>#addCustomMenuItems:hand: >> ClockMorph>>#step >> ClockMorph>>#toggleShowingSeconds >> ClockMorph>>#toggleShowing24hr >> WorldState>>#interCyclePause: >> Integer>>#quo: >> Integer>>#digitSubtract: >> SimpleServiceEntry>>#useLineAfter >> MorphicUIManager>>#interactiveParserFor: >> OBPluggableListMorph>>#mouseUp: >> PianoRollScoreMorph>>#addCustomMenuItems:hand: >> SystemDictionary>>#abandonSources >> SystemDictionary>>#internalizeSources >> SystemDictionary>>#internalizeChangeLog >> SetTest>>#testRemoveIfAbsent >> SimpleButtonDelayedMenuMorph>>#mouseUp: >> Installer>>#validate >> Installer>>#logErrorDuring: >> SketchEditorMorph>>#verifyState: >> SketchEditorMorph>>#deliverPainting:evt: >> SketchMorph>>#useInterpolation: >> Slider>>#descending >> JoystickMorph>>#autoCenterString >> JoystickMorph>>#button1 >> JoystickMorph>>#button2 >> SARInstaller>>#errorNoSuchMember: >> MessageSet>>#growable >> HandMorph>>#handleEvent: >> HandMorph>>#fullDrawOn: >> ImageSegment>>#declareAndPossiblyRename: >> PluggableListMorphPlus>>#wantsDroppedMorph:event: >> SUnitTest>>#testRanOnlyOnce >> BitmapFillStyle>>#isTiled >> InstallerMonticello>>#mcDetectFileBlock >> FTPClient>>#login >> Object>>#mustBeBooleanIn: >> Object>>#'~=' >> Decompiler>>#pushConstant: >> TextMorphForEditView>>#acceptOnCR >> HostSystemMenusMenuItem>>#shift >> FlapTab>>#inboard >> FlapTab>>#flapShowing >> FlapTab>>#tabSelected >> PluggableTreeMorph>>#wantsDroppedNode:on: >> DisplayScreen>>#deferUpdates: >> OBSystemBrowser>>#defaultBackgroundColor >> SmalltalkImage>>#setPlatformPreferences >> SmalltalkImage>>#snapshot:andQuit:embedded: >> URLMorph>>#mouseUp: >> MultiNewParagraph >> >>#multiComposeLinesFrom:to:delta:into:priorLines:atY: >> Collection>>#reject: >> TextDiffBuilder>>#hasMultipleMatches >> TrueTest>>#testNot >> TrueTest>>#testInMemory >> TrueTest>>#testAND >> MCFileBasedRepository>>#possiblyNewerVersionsOfAnyOf: >> Process>>#terminate >> ProtoObjectTest>>#testIsNil >> SqueakPage>>#write >> ColorPickerMorph>>#putUpFor:near: >> FalseTest>>#testAnd >> FalseTest>>#testOR >> FalseTest>>#testNot >> FalseTest>>#testAND >> UpdatingStringMorph>>#growable >> UpdatingStringMorph>>#autoAcceptOnFocusLoss >> LanguageEditor>>#selectedTranslationsAt:put: >> Socket>>#setOption:value: >> MultiCompositionScanner>>#setFont >> PositionableStream>>#unCommand >> HTTPSocket>>#logToTranscript >> Number>>#odd >> OBHierarchyBrowser>>#defaultBackgroundColor >> MorphExtension>>#isDefault >> MorphExtension>>#sortedPropertyNames >> MorphExtension>>#printOn: >> MorphExtension>>#hasProperty: >> ObjectOut>>#doesNotUnderstand: >> PluggableTextMorph>>#hasEditingConflicts >> PluggableTextMorph>>#accept >> SimpleSliderMorph>>#truncate >> OBProtocolBrowser>>#defaultBackgroundColor >> SystemWindow>>#mustNotClose >> SystemWindow>>#mouseDown: >> RBReadBeforeWrittenTester>>#read >> RBReadBeforeWrittenTester>>#processBlock: >> RBReadBeforeWrittenTester>>#processStatementNode: >> RBReadBeforeWrittenTester>>#processIfTrueIfFalse: >> GradientFillStyle>>#isRadialFill >> RefactoryTyper>>#typeFor: >> CompiledMethodTest>>#testValueWithReceiverArguments >> OBLazyListMorph>>#handleMouseMove: >> BlockContextTest>>#testSupplyAnswerThroughNestedBlocks >> BlockContextTest>>#testSupplyAnswerUsingTraditionalMatchOfQuestion >> BlockContextTest>>#testSupplySameAnswerToAllQuestions >> BlockContextTest>>#testSupplyAnswerUsingOnlySubstringOfQuestion >> BlockContextTest>>#testSupplySpecificAnswerToQuestion >> BlockContextTest>>#testSupplyAnswerUsingRegexMatchOfQuestion >> ImageMorph>>#isOpaque: >> ProjectSwikiServer>>#acceptsUploads >> PolygonMorph>>#rotateTestFlip: >> PolygonMorph>>#beStraightSegments >> PolygonMorph>>#beSmoothCurve >> BitBlt>>#drawFrom:to:withFirstPoint: >> FileList>>#getSelectedDirectory >> FileList>>#getSelectedFile >> RBParser>>#patchLiteralMessage >> OBMultipleSelectionColumn>>#listSelectionAt:put: >> ServerDirectory>>#upLoadProject:members:retry: >> MorphObjectOut>>#doesNotUnderstand: >> HaloMorph>>#addHandles >> ThumbnailImageMorph>>#togglePopupFeature >> ThumbnailImageMorph>>#handlesMouseDown: >> ThumbnailImageMorph>>#popupFeatureString >> ContextPart>>#jump:if: >> MCWorkingCopy>>#merge: >> FileDoesNotExistException>>#readOnly >> RBLiteralNodeTest>>#testValue >> Prefer... >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 15, 2009

Re: [Pharo-project] LogicalFont deepCopy infinite loop with Arial font

by Alain Plantec

Alexandre Bergel a Ã©crit : >> Thank, I'm sure that you are tired of having to set >> >> fonts each time you take a fresh image :) >> > > More than this :-) > "tired" is a weak word... > > Alexandre > Hi all, Here is a changeset with a new version of the PreferencesBrowser. It is for testing. I can improve it a little bit (by including display depth, desktop color, gradient color and author initials) and provide a slice if it is ok. I've investigated how preferences are implemented and it seems to me that current situation is the result of succesives hacks. I would like to clean out this part of the system. I will provide a roadmap before any coding. Can I start working on it ? Cheers alain >> >>> On 11 Feb 2009, at 16:22, Alain Plantec wrote: >>> >>> >>>> Hi all, >>>> I would like to improve the PreferencesBrowser so that it includes >>>> standard Fonts preferences (see joined snapshot). >>>> It's almost done except that, if a preference font is set to Arial, >>>> clicking on Save button leads to an infinite loop. >>>> >>>> To reproduce it, set button font to Arial-12 and >>>> Preferences standardButtonFont deepCopy. >>>> >>>> Cheers >>>> alain >>>> < >>>> FontsInPreferences >>>> .png >>>> >>>>> <FTFdeepcopy.png>_______________________________________________ >>>>> >>>> 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 >> >> > >

Feb. 15, 2009

Re: [Pharo-project] Boring confirmation message...

by Alexandre Bergel

> How far back does the workspace history go? Can it be cleared? > Perhaps unique to my working style, I end up with a workspace that > stays open and becomes a journal; I save its contents to disk every > so often, and finally it gets so big that I start a new one under a > new file name. They are not quite as useful as they once were > because I have started using comments in methods to hold expressions > to make things happen. It is nice to have the resulting "context > sensitive help" but the journal idea suffers for it. First time I've heard about this way of using workspaces. Keith produced an enhancement to save a workspace content in a file. > Putting all of that together, I think I would want the following: > > * debugger and browser code panes warn Me too. You do not have a warning if you haven't touch a text pane. If I just do a print-It in a text pane, I haven't produced any new code that deserve to be warned against loosing it. > * workspaces warn on close; history is a nice addition Before I produce my change that is now in Pharo, I did a small poll on this mailing list: who actually answer yes when trying to close a workspace. Two people answered (as far as I recall) saying that they never press 'Yes'. Since this is something I wanted to change for long, I did it. > * inspectors have history and do not warn on close There is no warning on inspector. > Just what a history means for inspectors (class level, > chronological, sorted based on the species of the inspected > object??) is open for debate. Agree. For now, it is just an ordered collection of texts contained in a pane. Cheers, Alexandre > > > > Bill > > > ---- > Wilhelm K. Schwab, Ph.D. > bschwab AT anest DOT ufl DOT edu > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr > ] On Behalf Of Alexandre Bergel [alexandre(a)bergel.eu] > Sent: Sunday, February 15, 2009 4:23 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Boring confirmation message... > > Hi Bill > >> There is a preference for confirm on close or something like that - >> I think. Your test for change in value is an interesting idea, but >> I am often willing/expecting to toss whatever I type into an >> inspector. I very much want the system to warn me if I am about to >> discard code in the debugger or browser source pane, and certainly >> in workspaces. > > I agree with you, and everybody wants this behavior. If I type > something in a debugger or browser, I should get a warning to prevent > loss upon closing it. However, if I just do a 'printIt' of an > expression (without typing anything else), i do not think there is a > reason to raise a warning if I want to close the window. I see myself > confirming "yes, I am sure I want to discard the content" without > having typed any code. Am I the only one to think this? > > For workspace, I added an history few weeks ago. You can now close a > workspace without having a warning. The content is inserted into a > history collection, that once can retrieve at anytime. I hope this > behavior will satisfy you. > > Cheers, > Alexandre > >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr >> ] On Behalf Of Alexandre Bergel [Alexandre.Bergel(a)inria.fr] >> Sent: Saturday, February 14, 2009 2:09 PM >> To: Pharo Development >> Subject: [Pharo-project] Boring confirmation message... >> >> Hi All, >> >> Often, I do a print-it in a debugger or browser. For some mysterious >> reason, I subsequently press the delete key that erases what was just >> print. Some changes occurred therefore. When I then select another >> method (or frame if I am in a debugger), a confirmation whether I >> want >> to save my changes is done. I find this very boring. Am i the only >> one ? >> >> A simple check whether the textual content has been modified would >> prevent this stupid question. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 15, 2009

Re: [Pharo-project] EventSensor>>createMouseEvent

by Schwab,Wilhelm K

Alexandre, A small refinement: backward compatibility is good when we are being compatible with things that are well designed. It is bad when it preserves cruft and inhibits progress. That said, +1 I am also pleased to see Aida on your list. I recently re-discovered it and am wondering how to compare it and Seaside. I have _no_ idea which way I would go on that, but guidance would be appreciated. Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [alexandre(a)bergel.eu] Sent: Sunday, February 15, 2009 4:30 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] EventSensor>>createMouseEvent Just an idea. Maybe we should identify the set of important applications that enhancement of Pharo should not break. I think that Seaside, Pier, OB, Aida, Monticello are probably the most important applications for Pharo. We should definitely do not preserve backward compatibility. Cheers, Alexandre On 15 Feb 2009, at 10:22, Hilaire Fernandes wrote: > I suspect external applicatiom may want this method > > 2009/2/15 Igor Stasenko <siguctua(a)gmail.com>: >> Hi, >> i found this method used only in two places in my image: >> >> Rectangle>>newRectFrom: >> Rectangle>>newRectButtonPressedDo: >> >> i think it could be candidate for removal along with #newRect's >> >> Still, i think it is useful to create graphics primitives based on >> user input. >> But i think that Rectangle is inappropriate place for it, where it >> hard-wiring with many globals and Morpic framework. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 15, 2009

Re: [Pharo-project] Boring confirmation message...

by Schwab,Wilhelm K

Alexandre, How far back does the workspace history go? Can it be cleared? Perhaps unique to my working style, I end up with a workspace that stays open and becomes a journal; I save its contents to disk every so often, and finally it gets so big that I start a new one under a new file name. They are not quite as useful as they once were because I have started using comments in methods to hold expressions to make things happen. It is nice to have the resulting "context sensitive help" but the journal idea suffers for it. Back on topic, I typically inspect rather than print, probably for just this type of reason. Most changes to text in the debugger are "real" as a result, so a warning is appreciated more than dreaded. Most things I type in an inspector I am willing to lose rather than be bothered every time I close one, especially since I close so many because I am using them to avoid making changes in the debugger (now that you've gotten me to think about it). Putting all of that together, I think I would want the following: * debugger and browser code panes warn * workspaces warn on close; history is a nice addition * inspectors have history and do not warn on close Just what a history means for inspectors (class level, chronological, sorted based on the species of the inspected object??) is open for debate. Bill ---- Wilhelm K. Schwab, Ph.D. bschwab AT anest DOT ufl DOT edu ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [alexandre(a)bergel.eu] Sent: Sunday, February 15, 2009 4:23 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Boring confirmation message... Hi Bill > There is a preference for confirm on close or something like that - > I think. Your test for change in value is an interesting idea, but > I am often willing/expecting to toss whatever I type into an > inspector. I very much want the system to warn me if I am about to > discard code in the debugger or browser source pane, and certainly > in workspaces. I agree with you, and everybody wants this behavior. If I type something in a debugger or browser, I should get a warning to prevent loss upon closing it. However, if I just do a 'printIt' of an expression (without typing anything else), i do not think there is a reason to raise a warning if I want to close the window. I see myself confirming "yes, I am sure I want to discard the content" without having typed any code. Am I the only one to think this? For workspace, I added an history few weeks ago. You can now close a workspace without having a warning. The content is inserted into a history collection, that once can retrieve at anytime. I hope this behavior will satisfy you. Cheers, Alexandre > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr > ] On Behalf Of Alexandre Bergel [Alexandre.Bergel(a)inria.fr] > Sent: Saturday, February 14, 2009 2:09 PM > To: Pharo Development > Subject: [Pharo-project] Boring confirmation message... > > Hi All, > > Often, I do a print-it in a debugger or browser. For some mysterious > reason, I subsequently press the delete key that erases what was just > print. Some changes occurred therefore. When I then select another > method (or frame if I am in a debugger), a confirmation whether I want > to save my changes is done. I find this very boring. Am i the only > one ? > > A simple check whether the textual content has been modified would > prevent this stupid question. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 15, 2009

Re: [Pharo-project] EventSensor>>createMouseEvent

by Igor Stasenko

Its a common practice in such cases (like in newRectFrom:) to capture a mouse events directly. So, i'd rather add a method to Hand or less likely Sensor, which will hide details from consumer and could be used like: Word activeHand captureMouseDuring: [:event | .. process the event ... event anyButtonPressed "if block returns true - keep capture and release otherwise , on non-local return - release as well" ] 2009/2/15 Igor Stasenko <siguctua(a)gmail.com>: > 2009/2/15 Hilaire Fernandes <hilaire(a)ofset.org>: >> I suspect external applicatiom may want this method >> > > As to me, this is too low-level for external app to bother with. > See how much handing it needed to work correctly in #newRectFrom:. > There is also an equivalent ways to synthesize events using morphic. > >> 2009/2/15 Igor Stasenko <siguctua(a)gmail.com>: >>> Hi, >>> i found this method used only in two places in my image: >>> >>> Rectangle>>newRectFrom: >>> Rectangle>>newRectButtonPressedDo: >>> >>> i think it could be candidate for removal along with #newRect's >>> >>> Still, i think it is useful to create graphics primitives based on user input. >>> But i think that Rectangle is inappropriate place for it, where it >>> hard-wiring with many globals and Morpic framework. >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Feb. 15, 2009