On 2012-09-11, at 22:21, GOUBIER Thierry <[email protected]> wrote:

> I've seen the combination and modifiers for Keymapper already; what I would 
> like is the alternative :
> 
> Either
> Character tab
> or
> Character tab ctrl
> 
> (because I've linked tab to nextFocus in a TreeModel, and ctrl + tab in a 
> TextModel (since tab can't be used)) Ok, not much of a gain anyway, so no 
> need to add this to Keymapper.

I though once about this as well, so you can do something like
$a cmd | $a cmd shift


> Ben, Guillermo and Stéphane, in AltBrowser, all hard-coded shortcuts are 
> desactivated and only the AltBrowser defined shortcuts are active (and those 
> shortcuts are dependent on the selection and resetted on each selection 
> change : it's mostly a recreation of the existing shortcuts, like doIt, 
> copy/paste, navigation, etc...). It takes as code :
> 
> - A subclass of KMDispatcher with two methods (keymapObservers and 
> dispatchKeystroke:).
> - The code to replace each necessary KMDispatcher by this subclass.
> - The code to reset and add shortcuts to those KMDispatchers.

As far as I remember I once had my own image which used KM shortcuts for all 
the default
shortcuts with proper Settings entries (maybe I find the image somewhere so I 
can share
the settings code (cause it's really only copy pasting...)

> So, apart from a bit of incompatibility (ListModel shortcuts in Spec), for 
> Spec it's really easy to push that once you review why I had to do that 
> change to KMDispatcher. For the other parts (SmalltalkEditor), it's a matter 
> of replacing some class configs by KMShortcuts. I believe someone with 
> Nautilus knowledge would be nice : it is the heaviest user of shortcuts, and 
> I really don't use shortcuts in the same way. A merge of both is probably 
> necessary.
> 
> For example, I have this method, called each time the selection changes :
> 
> updateTextKeymap
>    "Update the text keymap. Change the key dispatcher if needed. Change all 
> dispatchers to force and really force default shortcuts not to be used."
> 
>    | keyMorph |
>    keyMorph := self targetShortcutMorph.
>    (textModel widget kmDispatcher isKindOf: AltKMDispatcher)
>        ifFalse: [ textModel widget setProperty: #kmDispatcher toValue: 
> (AltKMDispatcher target: textModel widget) ].
>    (keyMorph kmDispatcher isKindOf: AltKMDispatcher)
>        ifFalse: [ keyMorph setProperty: #kmDispatcher toValue: 
> (AltKMDispatcher target: keyMorph) ]
>        ifTrue: [ keyMorph kmDispatcher reset ].
>    self selectedItem notNil
>        ifTrue: [ self selectedItem item buildTextShortcutsOn: keyMorph with: 
> self ]
> 
> And, in the select object side :
> 
> buildTextShortcutsOn: aKMDispatcher with: aRequestor
>    "This is an attempt at handling shortcuts... Which works, with the help of 
> a custom KMDispatcher."
> 
>    (Pragma allNamed: #textAreaCommand from: self class to: ABAbstractNode)
>        do: [ :e |
>            (self perform: e selector)
>                do: [ :c |
>                    | command |
>                    command := c on: aRequestor textModel for: aRequestor.
>                    command buildShortcut: aKMDispatcher ] ]
> 
> And then the shortcut itself in the Command object.
> 
> buildShortcut: aKMDispatcher
>    "Add a shortcut to the keymap. Conditions : must have a keystroke, must 
> wantsKeyboard and must be active."
> 
>    (self keystroke isNil or: [ self wantsKeyboard not or: [ self isActive not 
> ] ])
>        ifTrue: [ ^ self ].
>    aKMDispatcher
>        on: self keystroke
>        do: [ self execute ]
> 
> As you see, the use of KMDispatcher is dynamic and very simple, so I need 
> your comments on how that would fit with Nautilus and the global keymaps, 
> that I have disconnected in my case because they interfere in two ways : 
> KMDispatch randomly chooses which will apply, and that disallows instance 
> based overriding of shortcuts, and I don't want to have to mask all 
> pre-existing shortcuts to avoid pass-through effect (a shortcut get applied 
> because a global map has it and me, for my application, I don't want that to 
> happen).

given that I am a total ignorant :P, can you explain again in different words 
why you need
the "ugly" code above?

If you remove all the hardcoded shortcuts, is your dynamic KMDispatcher switch 
still necessary?

I still remember a vague discussion with Guillermo about how to handle local
overrides of keyboard shortcuts, wish I had made a picture of that draft back 
then :P

But I think we need a bit more general solution for that problem 
(of course if yours works right now, we should definitely go for it now!)


Reply via email to