Hi Guillermo, nice work! I'm looking forward to compare your code against mine, and try to detect room for improvements/merging the approaches. Fernando On Thu, Feb 3, 2011 at 3:46 AM, Guillermo Polito <guillermopolito@gmail.com> wrote:

Hi!

I refactored a little widget Keymappings had to use it into Settings.  See screenshots attached.

The main idea is to "type" the shortcut once the widget has focus.  After that, doing a secondary clic there is a context menu to accept, clear or cancel the changes.

Actual version of Keymappings presents a shortcut for opening a browser, a monticello browser and a test runner just to show how it works.  I expect that in no more than 2 weeks I'll have Editors integration so we can configure the editor shortcuts :).

I would **REALLY LOVE** to have some feedback :).

Who wants to load actual version of Keymappings can evaluate:

Gofer it     squeaksource: 'Keymapping';     package: 'ConfigurationOfKeymapping';     load.

(ConfigurationOfKeymapping project version:'1.3') load.

Cheers, Guille

PS:  I've tested it only in Pharo 1.2 Core.

Hi Guillermo, really cool, thanks. I have few remarks bit here is the more important one for now (I'm very busy, i will give you more feedbacks later) The problem of your implementation is that the declaration of kmappings are all centralized in KMToolsDefaultSettings and that you introduce a dependency between tools and keymappings. Imagine i've my tool and I want to declare a key mapping for it, then I have to change KMToolsDefaultSetting class. If my package for my tool is removed, then, again KMToolsDefaultSetting must be changed. I think the key mappings should be declared by tool packages independently as it is for settings without any dependency with the Keymapping package. I would integrate more the declaration with the system settings I give only a possible declaration here: -------------- ToolSetKeyMapping class>>keyMappingsOn: aBuilder <systemsettings> ... with: [ (aBuilder shortcut: #openClassBrowser) target: ToolSet; default: 'alt t, alt b'; description: 'Open the class browser' translated. (aBuilder shortcut: #openMonticelloBrowser) target: ToolSet; default: 'alt t, alt m'; description: 'Open Monticello' translated] --------------- Then, SettingTreeBuilder could be improved in order to take into account the #shortcut: message. For the rest, I can help you /do with your help if you need :) Thanks again. Alain Le 03/02/2011 03:46, Guillermo Polito a écrit :

Hi!

I refactored a little widget Keymappings had to use it into Settings. See screenshots attached.

The main idea is to "type" the shortcut once the widget has focus. After that, doing a secondary clic there is a context menu to accept, clear or cancel the changes.

Actual version of Keymappings presents a shortcut for opening a browser, a monticello browser and a test runner just to show how it works. I expect that in no more than 2 weeks I'll have Editors integration so we can configure the editor shortcuts :).

I would **REALLY LOVE** to have some feedback :).

Who wants to load actual version of Keymappings can evaluate:

Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load.

(ConfigurationOfKeymapping project version:'1.3') load.

Cheers, Guille

PS: I've tested it only in Pharo 1.2 Core.

Feedback randomly generated :) - sixxContentOn: aStream indent: level context: dictionary ?? Do we want to rely on SIXX? No! - Please add one comment per class! - run SmallLint initialize categoryContainer ifNil: [ categoryContainer := KeymapManager default ] => should do a super initialize - move deprecated method to 'deprecated' category KMBuilder - Cant you remove KMCmd and KMMeta Looks to me that you could do the same with a sharedPool or moving the class methods somewhere else. - can you have morph/text specific bindings? I commited some simple changes Stef