NewTextMorphEnterAndEscape bug and other refactorings

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

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:


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

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:


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

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.



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

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?


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