Re: [Pharo-project] NewTextMorphEnterAndEscape bug and other refactorings
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. 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. how do you handle specific keybinding with gaucho? 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] NewTextMorphEnterAndEscape bug and other refactorings
fernando we decided that we will use WindowOpened instead of WindowOpenedAnnouncement So it would be good that after you do a pass on your announcement. 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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] NewTextMorphEnterAndEscape bug and other refactorings
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@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] NewTextMorphEnterAndEscape bug and other refactorings
>> > > 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@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project