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
|