Guillermo Polito wrote: > > - shallow reset. That resets the shortcuts but tries to remember the > customizations done in the settings. This one can be done every time you > modify a <keymap> annotated method. > Thinking about this further, one of the purposes of revamping shortcuts was to remove hard-coding, so e.g. I can use my own custom shortcut to open the system browser. So the annotated builder methods are all really just defaults, to be changed on the fly as desired. As such, I think the right move is do nothing when the <keymap>s are modified. Then, all that would be needed is the deep reset, which would reset everything in the system back to defaults.
Guillermo Polito wrote: > > Hmmm, If you load the #bleedingEdge (which is pretty stable right now), > there are several examples in the categories: > Okay, I see. All the class-side #buildXxx: methods annotated with <keymap> Guillermo Polito wrote: > > Hmm, mainly, to bind a shortcut to a setting. And nothing else by now... > So I use it as a kind of id :/. Maybe someone has a better approach... I > was about to review it with Mariano tomorrow. > I wasn't criticizing, just learning :) Guillermo Polito wrote: > > But this last (lets say) *annonimous* shortcut, can't be put into a > setting. > That seems to make sense. Guillermo Polito wrote: > > Hmm, strange. There are two implementations of this method in my image. > One in KMShortcut and one in KMNoShortcut, one does nothing (on purpose > with a comment :P) but the other has an implementation :/... > I may not be understanding correctly, but they seem backwards (i.e. NoShortcut is doing something and Shortcut is not). Although (see below)... Guillermo Polito wrote: > > Thanks for the feedback :) > Thanks for all your hard work on an essential feature. -- View this message in context: http://forum.world.st/Keymapping-Questions-tp3990667p3993554.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
