>> 
> 
> 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
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to