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. Screenshot.1.png (69K) Download Attachment Screenshot2.png (187K) Download Attachment Screenshot3.png (190K) Download Attachment |
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 <[hidden email]> 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. > |
In reply to this post by Guillermo Polito
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. |
In reply to this post by Fernando olivero-2
excellent idea
On Feb 3, 2011, at 9:23 AM, Fernando Olivero wrote: > 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 > <[hidden email]> 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. >> > |
In reply to this post by Alain Plantec-3
+ 1
On Feb 3, 2011, at 10:27 AM, Alain Plantec wrote: > 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. > > |
In reply to this post by Guillermo Polito
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 |
Free forum by Nabble | Edit this page |