SVI is really neat !

Stephane Ducasse ducasse at iam.unibe.ch
Thu Aug 21 07:59:51 UTC 2003


Hi

you did it better than me ;). I should really look at your code.
Daniel have you look at it because it sounds quite good.

However I used another trick that I learned once by reading Scanner.
I have a classVariable to which per default the instance var is 
pointing.  All the methods only access the instance variable. This way 
I can avoid to have one keybinding map for
each paragreditor instance but I can still have :). I also created a 
class Mapper this way we can manipulate it as real object (store on, 
printOn:....). Why did not you? Too dumb oject?

Stef


On Thursday, August 21, 2003, at 09:03 AM, Steven Swerling wrote:

> Hi Stephane,
>
> It sounds like we did something similar. The KeyMapper adds an iv to 
> TextMorph called keyMapper, and each keymapper can have it's own 
> keymappings. If a keysequence is matched, it's "target" is called with 
> the desired command selector. If the selector takes an argument, then 
> the entire key sequence is passed as the argument to the selector.
>
> A little bonus is a facility for creating commands that "type" a 
> sequence of keystrokes. For instance, if you mapped a keysequence to 
> the command #myNewCommand, then added a method #myNewCommand (to the 
> target) that does this:
> 	self playKMKeystrokes: '<m-cr><tab>ifTrue:[]<left>'
> Then if you triggered the command, "ifTrue:[]" would be typed on the 
> next line, indented, with the cursor winding up between the brackets. 
> (<m-cr> is KeyMapper-ese for alt-enter, <left> is the left arrow key).
>
> I included a few sample custom commands in the changeset.
>
> Below is the KeyMapper class comment if your interested:
>
> ===== from KeyMapper class comment =====
> Provides the ability to bind multi-key sequences to commands. As of 
> this writing only implemented for TextMorph.
>
> Syntax for keybindings is below. Also see the examples in 'default 
> bindings'.
>
> Inst variables:
> 	keymap -
> 		A dict of key mappings
> 	sorted -
> 		A sorted collection of key sequences
> 	target -
> 		The object that is notified by keymapper (details below)
> 	buffer -
> 		Contains the key events typed so far during the current key match 
> attempt.
>
> The target must implement a few methods:
>
> keyMapperCommandInProcess:
> Called to alert the target that the user has partialy matched, but  
> not completely matched, a registered key sequence. The intent of this 
> callback is to allow targets to modify the cursor or provide some 
> other visual cue that a multi-key command is being entered.
>
> keyMapperFinishedCommand:
> Called to alert the target that a command has been matched. The intent 
> of this callback is to allow targets to remove any visual feedback 
> given to the user to indicate a command is being entered.
>
> keyMapperNoMatch:
> Called to alert the target that a command has been aborted (user  
> typed an invalid key sequence that partialy matched a registered 
> command. The intent of this callback is to allow targets to  remove 
> any visual feedback given to the user to indicate a  command is being 
> entered.
>
> ================
>
> Keybindings Syntax (also see examples in default bindings)
>
> A "keybinding spec" must be passed to KeyMapper during instance 
> creation. It should have the following form:
>
> 	{ assoc1. assoc2. assoc3...assosN }
>
> Each assoc should have the folowing form:
>
> 	'keyString'->#myCommand
>
> The value of assoc (#myCommand in the above example) is a method that 
> will be called on the 'target' when a key sequence has been matched. 
> The handler should take 0 or 1 arg. If it takes 1 arg, then the entire 
> key sequence is passed to the handler method in the form of a 
> collection of KeyboardEvents.
>
> The 'keyString' is the sequence of keystrokes to be matched. The 
> syntax for describing keystrokes is below.
>
> 	
> ============
> KeyString Syntax
>
> Special keys like home, ins, etc. are represented as follows:
> 	<home> <end> <ins> <bs> <tab> <pgup> <pgdn> <cr> <esc>
> 	<left> <right> <up> <down> <space> <del>
> 	<space><tab>
> Note: Use <space> and <tab> when creating KMFakeKeyEvent for those 
> characters (as opposed to $ and $	).
>
> Keys modified by the control key are represented as follows:
> 	<c-x> (matches control-x)
> 	<c-X> (matches control-X, ie. capital X)
> Keys modified by the meta key (alt or comand key) are represented as 
> follows:
> 	<m-x> (matches meta-x)
> 	<m-X> (matches meta-X)
>
> Keys that are not modified by the control or meta key are represented 
> normally in a keystring. For instance: 'abc'
>
> Another Example:
> If the line below were included in a keymapper spec, then KeyMapper 
> would execute the method #doSomething on the target when the user 
> types control-a, then meta-b, then A (capital a), then b, and finally 
> c"
> 	'<c-a><m-b>Abc'->#doSomething.
>
> =======
> Keys That Can't Be Mapped
>
> The ability to specify the 'shift' key is not included at this time.
> See the class coment of KMFakeKeyEvent for a detailed list of events 
> that cannot be mapped.
>
> ========================================
>
>
> Stephane Ducasse wrote:
>> Hi Steven
>> I was about to bring from the graveyard my implementation to get 
>> paragraphEditor
>> handling multiple key binding table. So that on a per-instance based 
>> we could have different bindings.
>> Do you think that this is worth? or should I use your Keymapper?
>> I would really to have that kind of simple functionality in the 
>> image. Is keymapper fixing paragraph editor? Because my changes were 
>> small (introducing the right instance and class var in paragraph 
>> editor, fixing all the methods to use the instance var) and adding a 
>> Binding class.
>> Stef
>
>



More information about the Squeak-dev mailing list