Hi!

On Sun, Oct 16, 2011 at 4:31 AM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi guillermo

I would like to push Keymapping in the core.
Do you think that it is ready?

I think it has not ugly bugs.� Esteban (another early adopter :D) found some little issues I fixed in the last weeks.� Also, most issues (like the ones of this email) usually appear from inconsistent shortcut definitions, not from a bug in the framework.
I don't know how other users (if any) feel it, but I feel it stable enough.

But, on the other way, until I make experience integrating it with OB, task manager, etc..� I don't know if it fits every usage in the image, so I don't know if it needs to be changed in some way :).� But it is difficult to make it evolve right now...

Guille
Like that we could remove the hardcoded way.
Stef
>
>
> On Sat, Oct 15, 2011 at 9:47 AM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
> Hi guys. I was trying to use TWM in Pharo 1.3 release. TWM brings with keymappings, which breaks the shortcuts of my image.
>
> The main problem here is that it's not integrated with current tools (i.e. OB). �If you just load Keymapping you will have an image where:
> - lots of shortcuts are hardcoded
> - some shortcuts like OB's are handled with it's own and specific way/framework
>
> Having keymapping living with those, introduces a third way of handling shortcuts (yeap, it's not good enough, but It's not easy to remove all the old code in a row ). �So, the following problems happens:
>
> - first of all, there are shortcuts collisions. �If a morph handles cmd + a and its owner handles cmd + a, cmd + b, the owner morph will never handle the shortcut because it was handled by it's child first.
> - second. �It's hard to keep track and find every hardcoded shortcut :). �And furthermore, �this leads in the fact that I cannot easily analyse shortcuts collisions between keymapping and hardcoded shortcuts.
>
> So, how does Keymapping live with that by now?
> 1) a keyEvent reaches a morph
> 2) the morph delegates the handling in keymapping (bubbling until the world instance).
> 3) if keymapping does not handle the shortcut, It is delegated to the old-hardcoded shortcuts (so the original behavior is still there yet)
>
> All this is just to understand what is happening and where the errors come from :P
>
> For example, after installing keymappings I cannot close windows anymore with cmd + w �or I cannot run tests from the browser using cmd + t.
>
> So far, I've found those two collisions in keymapping 1.9 and one more in keymapping+TWM:
>
> 1) Cmd+w was defined for TextEditor for delete backword.
>
> Esteban already complained about this, so I've changed it in 2.0 for Cmd + Backspace
> This shortcut was taken from SimpleEditor, in #initializeCmdKeyShortcuts. �I don't know if it should be there or not.
>
> �2) Cmd+t from omnibrowser was colliding with some global shortcuts I defined in the initial versions of keymapping to play opening a test runner, a browser, a monticello browser.
>
> I've fixed it removing the global shortcuts by now (because I'm not conviced the key combinations are nice).
>
> 3) When loading TWM + Keymapping, I realized the cmd+w was not working again. �Wandering, I found that the TWM shortcuts were defined for a lot of morphs, in this way, causing a little of trouble:
>
> � � {PasteUpMorph. SystemWindow. SmalltalkEditor. TextEditor. PluggableTextMorph} do: [:aClass|
> � � � � aBuilder
> � � � � � � attachShortcutCategory: self shortcutCategory
> � � � � � � to: aClass.
> � � ].
>
> But replacing it by
>
> aBuilder
> � � � � � � attachShortcutCategory: self shortcutCategory
> � � � � � � to: PasteUpMorph.
>
> should be working the same way :/.
> Laurent, did you have any problems when not attaching the categories in this way?.
>
> Also: TWM by default has a lot of (cmd+w, ...) mappings colliding with the window cmd+w shortcut. �So the window shortcut or the TWM ones are to be sacrificed :P.
>
>
> So i installed TWM without keybinding but now I cannot open the settings window because keymappings is not load.
>
> Any solution? (install TWM without keymappings or fixing keymappings)
>
> I've done some fixes and improvements to keymapping, and I've created a 2.0 version where:
>
> - the collisions below are fixed
> - keymaps can be configured per morph instance too (not only per class, as the former version)
> - some little improvements and code cleaning
>
> But those things I remarked of TWM should be reviewed :)
>
> Or you can Use twm without keymappings and I'll have no more feedback :(
>
>
> thanks!
>
> Thank you :)
>
> Guille