February 2009 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] EventSensor>>createMouseEvent

by Igor Stasenko

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.

Feb. 15, 2009

Re: [Pharo-project] EventSensor>>createMouseEvent

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 15, 2009

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 15, 2009

Re: [Pharo-project] EventSensor>>createMouseEvent

by Hilaire Fernandes

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

Feb. 15, 2009