August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update 1.2] #12076

by StÃ©phane Ducasse

> Why was SmalltalkImage >> os marked as deprecated? > I thought the result of previous discussion was that the methods themselves should be moved to separate classes (like OSPlatform), but the delegating method in SmalltalkImage should be kept... if we have OSPlatform as in Sophie and all the infrastructure there (like isUnix, isMacOS...) do we want to duplicate it in SmalltalkImage? (except for compatibility with squeak). Ideally Smalltalk should be a simple lightweight lobby to access behavior Smalltalk platform -> OSPlatform Smalltalk vm Smalltalk globals. Stef > > Cheers, > Henry > > On Aug 3, 2010, at 4:30 55PM, StÃ©phane Ducasse wrote: > >> 12076 >> ----- >> >> - Issue 2347: Migrating some OS queries from SmalltalkImage to OSPlatform. This changes is really nice since it used the existing Platform classes for that they should. >> Now do you use Smalltalk os, Smalltalk platform but >> OSPlatform os >> OSPlatform platform >> This way OSPlatform is used for what it should. It would be nice if Squeak would follow this change, else we will add a compatibility package. Thanks Simon Denier. >> >> >> I like these changes that apply OOP thinking to the system. Distribution of responsibilities. >> >> Stef >> _______________________________________________ >> 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

Aug. 4, 2010

Re: [Pharo-project] Shrink image

by StÃ©phane Ducasse

On Aug 4, 2010, at 12:20 PM, nullPointer wrote: > > Hi > > I start implementing a little app for shrink image for deploy purposes. I > want know if exists a standard way for execute some tasks: > > 1- Delete World menu, and context menu when a morph is clicked with Control > pressed. In fact, Delete ALL default context menus. the world menu is build using settings so you can just block that > 2- Remove halos ( changing Preferences, true? ) > 3- Remove development mechanism ( for example, the behavior of text editor > widgets when I input a class name and pressing Control B appears the class > in Explorer ) this is not there yet since the shortcut table is global > 4- Change message when the close window is pressed and appears the message > 'Quit Pharo without save?' this should be move to the UImanager and handled there. > 5- Override the default behavior of debugger. Perhaps show a simple message > with the error. have a look at the UnhandledError default action and follow it. Now when you have an error you want to log it and andrey was working on a solution. > > I know search some that things, but I want know if exists the BEST way. There is a UI manager and it can be specialized for some of this. I know that andrey (I guess asked for the same questions) it would be good to share and build a nice solution. > > All conseils for that app will be welcomed. > > Regards. > -- > View this message in context: http://forum.world.st/Shrink-image-tp2313236p2313236.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2010

Re: [Pharo-project] [update 1.2] #12076

by Henrik Johansen

Why was SmalltalkImage >> os marked as deprecated? I thought the result of previous discussion was that the methods themselves should be moved to separate classes (like OSPlatform), but the delegating method in SmalltalkImage should be kept... Cheers, Henry On Aug 3, 2010, at 4:30 55PM, StÃ©phane Ducasse wrote: > 12076 > ----- > > - Issue 2347: Migrating some OS queries from SmalltalkImage to OSPlatform. This changes is really nice since it used the existing Platform classes for that they should. > Now do you use Smalltalk os, Smalltalk platform but > OSPlatform os > OSPlatform platform > This way OSPlatform is used for what it should. It would be nice if Squeak would follow this change, else we will add a compatibility package. Thanks Simon Denier. > > > I like these changes that apply OOP thinking to the system. Distribution of responsibilities. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2010

[Pharo-project] Shrink image

by nullPointer

Hi I start implementing a little app for shrink image for deploy purposes. I want know if exists a standard way for execute some tasks: 1- Delete World menu, and context menu when a morph is clicked with Control pressed. In fact, Delete ALL default context menus. 2- Remove halos ( changing Preferences, true? ) 3- Remove development mechanism ( for example, the behavior of text editor widgets when I input a class name and pressing Control B appears the class in Explorer ) 4- Change message when the close window is pressed and appears the message 'Quit Pharo without save?' 5- Override the default behavior of debugger. Perhaps show a simple message with the error. I know search some that things, but I want know if exists the BEST way. All conseils for that app will be welcomed. Regards. -- View this message in context: http://forum.world.st/Shrink-image-tp2313236p2313236.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 4, 2010

Re: [Pharo-project] NewTextMorphEnterAndEscape bug and other refactorings

by StÃ©phane Ducasse

>> > > In Pharo1.2 : there are two diferent mechanisms: > 1. Morphs that present text, and forward the keybinding logic to an editor ( NewTextMorph, EntryfieldMorph and old TextMorph and Pluggables => Editor , TextEditor and SmalltalkEditor ). > > EditableTextMorph>>keyStroke: aKeyboardEvent > self handleInteraction: [ editor processKeyStroke: aKeyboardEvent ]. > > > 2.Morphs that don't deal with text, do their own customizations by overriding keyStroke: anEvent ( or using their own customized event handler ) > > keyStroke: anEvent > "Handle a keystroke event. The default response is to let my eventHandler, if any, handle it." > eventHandler ifNotNil: > [self eventHandler keyStroke: anEvent fromMorph: self]. > > We could either > 1. Unify all Morphs to use the first mechanisms > (2) Add by default to all Morphs a specific event handler that handles keybindings objects on #keyStroke: would 1 imply to always creates a editor? May be we could have a ClassVariable in Morph and the trick I mentioned? What are the cost? May be having a nice trait that can add interaction to a morph would be nice. I do not like this top heavy classes. > how do you handle specific keybinding with gaucho? > > In Gaucho i do (2),. > > All interactive Gaucho morphs are subclass of GMLivelyShape, and i override #keyStroke: , > so that it finds any keyBinding that can be applied to the received event, and executes it. I would like to help people creating advanced interaction easily, could not we also invoke keyStroke: as a fallback when the editor table does not contain the keystroke? > Fernando > > > > pd: here is the code, in case my explanation wasn't good enough! > > GMLivelyShape >>keyStroke: aMorphicEvent > | existingKeybinding binding result appliedCommand | > existingKeybinding := GCondition existingKeybindingCondition evaluateOn: aMorphicEvent with: keyBindings . > existingKeybinding wasUnsuccesfull ifTrue:[ > ^ self justRejectedKeyStroke: aMorphicEvent failedEvaluation: existingKeybinding ]. > binding := self keyBindingActingOn: aMorphicEvent. > result := binding canBeAppliedOn: self . > result wasUnsuccesfull ifTrue:[ ^ self > justRejectedKeyStroke: gEvent > failedEvaluation: result ]. > appliedCommand := self applyKeybinding: binding. > > >> Stef >> >> On Aug 4, 2010, at 11:26 AM, Fernando olivero wrote: >> >>> Name: SLICE-Issue-2749-NewTextMorphEnterAndEscape-FernandoOlivero.1 >>> Author: FernandoOlivero >>> Time: 4 August 2010, 11:23:18 am >>> UUID: 4558cda9-d2f7-4839-9c9c-bf8438c9b28f >>> Ancestors: >>> Dependencies: Morphic-FernandoOlivero.673, System-Text-FernandoOlivero.25 >>> >>> . Added edited announcements, so we can create morphs that react to every user input. >>> 2. Removed some "morphic" methods from the TextEditor ( #offerMenuFromEsc:, now escape is handled by sending the editor's morphs #escapePressed ). >>> 3. Fixed the bug >>> 4 .Simplified KeyStroke: methods, so that all the keyboard bindings logic remains in the Editors ( to easily implement customized keyboard bindings, now hardcoded in the Editors classes ) >>> _______________________________________________ >>> 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

Aug. 4, 2010

[Pharo-project] [update 1.2] #12081

by StÃ©phane Ducasse

12081 ----- - Fixing vmVersion comments and guessDefaultEndline - Issue 2746: NewTextMorph now uses theme text adornments Polymorph text addornment and other minor refactorings to NewTextMorph and related classes. Thanks Fernando Olivero - Issue 2749: NewTextMorph does not react to enter and escape keystrokes. Thanks Fernando Olivero Stef

Aug. 4, 2010

Re: [Pharo-project] NewTextMorphEnterAndEscape bug and other refactorings

by Fernando olivero

On Aug 4, 2010, at 11:30 AM, StÃ©phane Ducasse wrote: > Thanks > > Will be intergated now. > > BTW at ESUG we should sit together and talk about the way we want to have custom keybinding at the morph level. > Yes! > Once I was thinking to do the following: > use a classvar for a default table > and use an instance to point to it and all methods using it so that > we could get sharing of the table by default and instance based possible cosutomization. > Ok, here are some thoughts: In Pharo1.2 : there are two diferent mechanisms: 1. Morphs that present text, and forward the keybinding logic to an editor ( NewTextMorph, EntryfieldMorph and old TextMorph and Pluggables => Editor , TextEditor and SmalltalkEditor ). EditableTextMorph>>keyStroke: aKeyboardEvent self handleInteraction: [ editor processKeyStroke: aKeyboardEvent ]. 2.Morphs that don't deal with text, do their own customizations by overriding keyStroke: anEvent ( or using their own customized event handler ) keyStroke: anEvent "Handle a keystroke event. The default response is to let my eventHandler, if any, handle it." eventHandler ifNotNil: [self eventHandler keyStroke: anEvent fromMorph: self]. We could either 1. Unify all Morphs to use the first mechanisms (2) Add by default to all Morphs a specific event handler that handles keybindings objects on #keyStroke: > how do you handle specific keybinding with gaucho? In Gaucho i do (2),. All interactive Gaucho morphs are subclass of GMLivelyShape, and i override #keyStroke: , so that it finds any keyBinding that can be applied to the received event, and executes it. Fernando pd: here is the code, in case my explanation wasn't good enough! GMLivelyShape >>keyStroke: aMorphicEvent | existingKeybinding binding result appliedCommand | existingKeybinding := GCondition existingKeybindingCondition evaluateOn: aMorphicEvent with: keyBindings . existingKeybinding wasUnsuccesfull ifTrue:[ ^ self justRejectedKeyStroke: aMorphicEvent failedEvaluation: existingKeybinding ]. binding := self keyBindingActingOn: aMorphicEvent. result := binding canBeAppliedOn: self . result wasUnsuccesfull ifTrue:[ ^ self justRejectedKeyStroke: gEvent failedEvaluation: result ]. appliedCommand := self applyKeybinding: binding. > Stef > > On Aug 4, 2010, at 11:26 AM, Fernando olivero wrote: > >> Name: SLICE-Issue-2749-NewTextMorphEnterAndEscape-FernandoOlivero.1 >> Author: FernandoOlivero >> Time: 4 August 2010, 11:23:18 am >> UUID: 4558cda9-d2f7-4839-9c9c-bf8438c9b28f >> Ancestors: >> Dependencies: Morphic-FernandoOlivero.673, System-Text-FernandoOlivero.25 >> >> . Added edited announcements, so we can create morphs that react to every user input. >> 2. Removed some "morphic" methods from the TextEditor ( #offerMenuFromEsc:, now escape is handled by sending the editor's morphs #escapePressed ). >> 3. Fixed the bug >> 4 .Simplified KeyStroke: methods, so that all the keyboard bindings logic remains in the Editors ( to easily implement customized keyboard bindings, now hardcoded in the Editors classes ) >> _______________________________________________ >> 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

Aug. 4, 2010

Re: [Pharo-project] Telling the OS that the VM wants focus

by StÃ©phane Ducasse

why not growl events? On Aug 4, 2010, at 10:38 AM, Max Leske wrote: > Ok, thanks. > Would be nice if at some point in the future unhandled exceptions would notify the OS automatically (for instance). > > > On 04.08.2010, at 00:34, John M McIntosh wrote: > >> Many things come to mind, one is to use some of the old text to voice features of squeak and have the computer yell at you when it's ready... That should work on all platforms that support sound. >> >> More subtle and complex would be to use Alien/FFI and talk to the operating system's notification/alert API. >> >> On 2010-08-03, at 12:51 AM, Max Leske wrote: >> >>> Hi folks >>> >>> The project I'm currently working on requires that I have to wait frequently for computations / operations to complete. To control the status I used progress bars wherever possible. Now, since the operations might take several minutes I like to sometimes switch to another Desktop, maybe read an e-mail or an article. >>> I'd find it rather useful if the OS would notify me that the VM needs my attention as soon as the operations have completed or if there was an error during execution, so that I don't have to go and check every 30 seconds. Is there an existing way to do this? If not, I'd like to propose this as a feature for a future release (although I don't have an inkling how one would accomplish this...). >>> >>> Cheers, >>> Max >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> _______________________________________________ >> 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

Aug. 4, 2010

Re: [Pharo-project] [update 1.2] #12080

by StÃ©phane Ducasse

argh..... bound with the past On Aug 4, 2010, at 11:47 AM, Henrik Johansen wrote: > It's referenced directly by f.ex. VMMaker, so I wouldn't do that. > > Cheers, > Henry > > On Aug 4, 2010, at 11:40 49AM, StÃ©phane Ducasse wrote: > >> Yes there is a substituteClass which delegate to Multi.... >> May be we should remove CrLFFileStream >> >> On Aug 3, 2010, at 11:28 PM, Levente Uzonyi wrote: >> >>> On Tue, 3 Aug 2010, StÃ©phane Ducasse wrote: >>> >>>> 12080 >>>> ----- >>>> >>>> - Issue 1298: CrLfFileStream not properly initialized on Mac OS. Thanks Andrew Black and Carlo Teixeira. >>> >>> CrLFFileStream? That shouldn't be used anywhere. It was superseded by MultiByteFileStream. In Squeak [CrLfFileStream new] will return a MultiByteFileStream. >>> >>> >>> Levente >>> >>>> >>>> Lot of conflicts on this one.... >>>> >>>> Stef >>>> _______________________________________________ >>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2010

Re: [Pharo-project] Gofer support for Universes

by StÃ©phane Ducasse

Yes I saw that. and yes the name is really misleading. We should call that MetacelloRepositories Stef On Aug 4, 2010, at 11:45 AM, Serge Stinckwich wrote: > I think you miss the point of Miguel. > > This is not the previous "Universe" but just repositories of > ConfigurationOfXXX for Pharo 1.0&1.1. > > Maybe the name is misleading. > > Regards, > > On Wed, Aug 4, 2010 at 4:26 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> I'll have a look when I am back from holidays. >> >> Two questions arise: >> >> - Is Universe still relevant and maintained by anybody these days? >> Looks like all current code is managed with Metacello nowadays. >> >> - Gofer was designed to make Monticello scriptable. How do actions >> like commit and merge map to Gofer? >> >> Lukas >> >> On Wednesday, August 4, 2010, Miguel Enrique CobÃ¡ MartÃnez >> <miguel.coba(a)gmail.com> wrote: >>> StÃ©phane, Lukas, >>> >>> I have uploaded >>> >>> Gofer-Core-MiguelCoba.124 >>> Gofer-Tests-MiguelCoba.117 >>> >>> to PharoInbox repository on squeaksource. >>> >>> They are based on the versions of gofer in Pharo 1.0 >>> Gofer-Core-MarkusDenker.117 >>> Gofer-Tests-MarkusDenker.116 >>> >>> and add universes support to gofer. >>> >>> What do you think, are they worth integrating to mainstream gofer? >>> Does this functionality belongs to Gofer? I know of GoferProjectLoader, >>> but it isn't part of PharoCore, so that discards it right now. >>> >>> What is the procedure to merge it to trunk gofer, if so decided, so that >>> a >>> >>> Gofer upgrade >>> >>> in any Pharo image gets this new version? >>> >>> Cheers >>> -- >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2010