> > > 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.
good > 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 :). we could push it inside and hook it and learn. > But it is difficult to make it evolve right now... why? > > Guille > > Like that we could remove the hardcoded way. > Stef > > > > > > On Sat, Oct 15, 2011 at 9:47 AM, Mariano Martinez Peck > > <[email protected]> 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 > > >
