September 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] pharo-2.0-tests Â» win - Build # 341 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 12, 2012

[Pharo-project] [update 2.0] #20280

by Esteban Lorenzano

20280 ----- Issue 6654: Make one RPackage maps one PackageInfo http://code.google.com/p/pharo/issues/detail?id=6654 (pass 2) - introduce RPackageSet - test RPackageSet is polymorphic with PackageInfo in MC context WARNING: This is still NOT the solution... but we are a lot closer :)

Sept. 12, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 340 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 12, 2012

Re: [Pharo-project] Event smell...

by Benjamin

Thanks :) Ben On Sep 12, 2012, at 9:53 AM, Henrik Sperre Johansen wrote: > On 11.09.2012 18:27, Benjamin wrote: >> >> >> PS: Looking up an example WindowAnnouncement and ran across it; WTF does Nautilus need special NautilusWindowAnnouncement classes for? >> As long as your announcer is a Nautilus-specific one rather than the default announcer, that's all the separation that's needed... >> In other words; favour application-distinct announcers over duplicate Announcement types. >> I think it's just because I wasn't aware that this class existed :) >> >> I should fix that >> >> Ben >> > Great! > I made you an issue so you can't forget :) > > http://code.google.com/p/pharo/issues/detail?id=6659 > > Cheers, > Henry >

Sept. 12, 2012

Re: [Pharo-project] Event smell...

by Henrik Sperre Johansen

On 11.09.2012 18:27, Benjamin wrote: > > > PS: Looking up an example WindowAnnouncement and ran across it; WTF does Nautilus need special NautilusWindowAnnouncement classes for? > As long as your announcer is a Nautilus-specific one rather than the default announcer, that's all the separation that's needed... > In other words; favour application-distinct announcers over duplicate Announcement types. > I think it's just because I wasn't aware that this class existed :) > > I should fix that > > Ben > Great! I made you an issue so you can't forget :) http://code.google.com/p/pharo/issues/detail?id=6659 Cheers, Henry

Sept. 12, 2012

Re: [Pharo-project] RE : Keymapping KMShortcut combining

by Goubier Thierry

Le 12/09/2012 07:33, StÃ©phane Ducasse a Ã©crit : > if you have code that ease the replacement of hardcoded binding by key mapper, publish it so that we integrate > it like that everybody will benefit from it. > > Stef Ok, I'll start to provide slices under 6656, and describe what I plan to do. Update KMDispatcher to: - Ensure a specific ordering of targets (local first, then the rest). The current keymapObservers has a bug: it returns a Set of targets. -- Why is KMDispatcher>>staticTargets deprecated ? This is where all the shortcuts for Nautilus are defined, as well as some shortcuts for SmalltalkEditor / Spotlight / TextEditor / TextMorph (looks like an attempt at replacing the Morphic shortcuts). -- Someone is using the perInstanceTarget ? It's a lot easier to use on:do: and the directKeymap. - Ensure that all ctrl and cmd shorcuts are processed by KMDispatch so that they are not given to the Morphic shortcut processing code. -- legacy tracking and testing needed for that, please ! Do you think it's better to keep the staticTargets or should legacy shortcuts be moved to on:do: below ? How often is the staticTargets thing built (Oh, every time a method with pragma <keymap> is compiled) ? - Add a directKeymapOnly flag to restrict dispatch to the directKeymap (for users of on:do:) Update Morphic - Any idea about how to setup a link between a model and any Morph to give access to the keymap ? It's easy once you know the target Morphs, but how to build this knowledge and avoid code like : targetShortcutMorph "Get the real, lowest level morph we need to touch the key dispatch for. What a mess!" ^ self textModel widget submorphs first submorphs first Update Spec. - Easy. Remove unneeded key processing code in Morphic (shouldn't be called anymore except for non-ctrl, non-cmd key events), and complete the shortcuts (navigation keys, special keys for specific Morphs, like <space> for MorphButton). Your opinion ? Anything I missed ? Thierry > > > >> Yes, I was thinking of the $a cmd | $a cmd shift thing. >> >> Oh, the ugly code (the one that changes the KMDispatcher, right ?). It's patching the relevant Morphs. The solution you use when you want to hack Morphic without recoding it :( >> >> Anything better than that would do, a Spec or Morphic API for the application to be able to reset/recode shortcuts when needed :) a nice when: #keymapChange do: aBlock. >> >> Some of the work is to switch to hardcoded Keymappings... and to allow dynamic, instance-based control as well. >> >> What I tried is to remove all hardcoded shortcuts, and it works. I then merged my menus and shortcuts, and made sure my application could control which shortcuts were active. But, in the process, I desactivated for my instances the global Keymaps, the one Nautilus uses for its shortcuts. >> >> Thierry >> >> ________________________________________ >> De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [camillobruni(a)gmail.com] >> Date d'envoi : mardi 11 septembre 2012 22:48 >> Ã : Pharo-project(a)lists.gforge.inria.fr >> Objet : Re: [Pharo-project] RE : Keymapping KMShortcut combining >> >> On 2012-09-11, at 22:21, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> I've seen the combination and modifiers for Keymapper already; what I would like is the alternative : >>> >>> Either >>> Character tab >>> or >>> Character tab ctrl >>> >>> (because I've linked tab to nextFocus in a TreeModel, and ctrl + tab in a TextModel (since tab can't be used)) Ok, not much of a gain anyway, so no need to add this to Keymapper. >> >> I though once about this as well, so you can do something like >> $a cmd | $a cmd shift >> >> >>> Ben, Guillermo and StÃ©phane, in AltBrowser, all hard-coded shortcuts are desactivated and only the AltBrowser defined shortcuts are active (and those shortcuts are dependent on the selection and resetted on each selection change : it's mostly a recreation of the existing shortcuts, like doIt, copy/paste, navigation, etc...). It takes as code : >>> >>> - A subclass of KMDispatcher with two methods (keymapObservers and dispatchKeystroke:). >>> - The code to replace each necessary KMDispatcher by this subclass. >>> - The code to reset and add shortcuts to those KMDispatchers. >> >> As far as I remember I once had my own image which used KM shortcuts for all the default >> shortcuts with proper Settings entries (maybe I find the image somewhere so I can share >> the settings code (cause it's really only copy pasting...) >> >>> So, apart from a bit of incompatibility (ListModel shortcuts in Spec), for Spec it's really easy to push that once you review why I had to do that change to KMDispatcher. For the other parts (SmalltalkEditor), it's a matter of replacing some class configs by KMShortcuts. I believe someone with Nautilus knowledge would be nice : it is the heaviest user of shortcuts, and I really don't use shortcuts in the same way. A merge of both is probably necessary. >>> >>> For example, I have this method, called each time the selection changes : >>> >>> updateTextKeymap >>> "Update the text keymap. Change the key dispatcher if needed. Change all dispatchers to force and really force default shortcuts not to be used." >>> >>> | keyMorph | >>> keyMorph := self targetShortcutMorph. >>> (textModel widget kmDispatcher isKindOf: AltKMDispatcher) >>> ifFalse: [ textModel widget setProperty: #kmDispatcher toValue: (AltKMDispatcher target: textModel widget) ]. >>> (keyMorph kmDispatcher isKindOf: AltKMDispatcher) >>> ifFalse: [ keyMorph setProperty: #kmDispatcher toValue: (AltKMDispatcher target: keyMorph) ] >>> ifTrue: [ keyMorph kmDispatcher reset ]. >>> self selectedItem notNil >>> ifTrue: [ self selectedItem item buildTextShortcutsOn: keyMorph with: self ] >>> >>> And, in the select object side : >>> >>> buildTextShortcutsOn: aKMDispatcher with: aRequestor >>> "This is an attempt at handling shortcuts... Which works, with the help of a custom KMDispatcher." >>> >>> (Pragma allNamed: #textAreaCommand from: self class to: ABAbstractNode) >>> do: [ :e | >>> (self perform: e selector) >>> do: [ :c | >>> | command | >>> command := c on: aRequestor textModel for: aRequestor. >>> command buildShortcut: aKMDispatcher ] ] >>> >>> And then the shortcut itself in the Command object. >>> >>> buildShortcut: aKMDispatcher >>> "Add a shortcut to the keymap. Conditions : must have a keystroke, must wantsKeyboard and must be active." >>> >>> (self keystroke isNil or: [ self wantsKeyboard not or: [ self isActive not ] ]) >>> ifTrue: [ ^ self ]. >>> aKMDispatcher >>> on: self keystroke >>> do: [ self execute ] >>> >>> As you see, the use of KMDispatcher is dynamic and very simple, so I need your comments on how that would fit with Nautilus and the global keymaps, that I have disconnected in my case because they interfere in two ways : KMDispatch randomly chooses which will apply, and that disallows instance based overriding of shortcuts, and I don't want to have to mask all pre-existing shortcuts to avoid pass-through effect (a shortcut get applied because a global map has it and me, for my application, I don't want that to happen). >> >> given that I am a total ignorant :P, can you explain again in different words why you need >> the "ugly" code above? >> >> If you remove all the hardcoded shortcuts, is your dynamic KMDispatcher switch still necessary? >> >> I still remember a vague discussion with Guillermo about how to handle local >> overrides of keyboard shortcuts, wish I had made a picture of that draft back then :P >> >> But I think we need a bit more general solution for that problem >> (of course if yours works right now, we should definitely go for it now!) >> >> >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 12, 2012

Re: [Pharo-project] RE : Keymapping KMShortcut combining

by StÃ©phane Ducasse

if you have code that ease the replacement of hardcoded binding by key mapper, publish it so that we integrate it like that everybody will benefit from it. Stef > Yes, I was thinking of the $a cmd | $a cmd shift thing. > > Oh, the ugly code (the one that changes the KMDispatcher, right ?). It's patching the relevant Morphs. The solution you use when you want to hack Morphic without recoding it :( > > Anything better than that would do, a Spec or Morphic API for the application to be able to reset/recode shortcuts when needed :) a nice when: #keymapChange do: aBlock. > > Some of the work is to switch to hardcoded Keymappings... and to allow dynamic, instance-based control as well. > > What I tried is to remove all hardcoded shortcuts, and it works. I then merged my menus and shortcuts, and made sure my application could control which shortcuts were active. But, in the process, I desactivated for my instances the global Keymaps, the one Nautilus uses for its shortcuts. > > Thierry > > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [camillobruni(a)gmail.com] > Date d'envoi : mardi 11 septembre 2012 22:48 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : Re: [Pharo-project] RE : Keymapping KMShortcut combining > > On 2012-09-11, at 22:21, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > >> I've seen the combination and modifiers for Keymapper already; what I would like is the alternative : >> >> Either >> Character tab >> or >> Character tab ctrl >> >> (because I've linked tab to nextFocus in a TreeModel, and ctrl + tab in a TextModel (since tab can't be used)) Ok, not much of a gain anyway, so no need to add this to Keymapper. > > I though once about this as well, so you can do something like > $a cmd | $a cmd shift > > >> Ben, Guillermo and StÃ©phane, in AltBrowser, all hard-coded shortcuts are desactivated and only the AltBrowser defined shortcuts are active (and those shortcuts are dependent on the selection and resetted on each selection change : it's mostly a recreation of the existing shortcuts, like doIt, copy/paste, navigation, etc...). It takes as code : >> >> - A subclass of KMDispatcher with two methods (keymapObservers and dispatchKeystroke:). >> - The code to replace each necessary KMDispatcher by this subclass. >> - The code to reset and add shortcuts to those KMDispatchers. > > As far as I remember I once had my own image which used KM shortcuts for all the default > shortcuts with proper Settings entries (maybe I find the image somewhere so I can share > the settings code (cause it's really only copy pasting...) > >> So, apart from a bit of incompatibility (ListModel shortcuts in Spec), for Spec it's really easy to push that once you review why I had to do that change to KMDispatcher. For the other parts (SmalltalkEditor), it's a matter of replacing some class configs by KMShortcuts. I believe someone with Nautilus knowledge would be nice : it is the heaviest user of shortcuts, and I really don't use shortcuts in the same way. A merge of both is probably necessary. >> >> For example, I have this method, called each time the selection changes : >> >> updateTextKeymap >> "Update the text keymap. Change the key dispatcher if needed. Change all dispatchers to force and really force default shortcuts not to be used." >> >> | keyMorph | >> keyMorph := self targetShortcutMorph. >> (textModel widget kmDispatcher isKindOf: AltKMDispatcher) >> ifFalse: [ textModel widget setProperty: #kmDispatcher toValue: (AltKMDispatcher target: textModel widget) ]. >> (keyMorph kmDispatcher isKindOf: AltKMDispatcher) >> ifFalse: [ keyMorph setProperty: #kmDispatcher toValue: (AltKMDispatcher target: keyMorph) ] >> ifTrue: [ keyMorph kmDispatcher reset ]. >> self selectedItem notNil >> ifTrue: [ self selectedItem item buildTextShortcutsOn: keyMorph with: self ] >> >> And, in the select object side : >> >> buildTextShortcutsOn: aKMDispatcher with: aRequestor >> "This is an attempt at handling shortcuts... Which works, with the help of a custom KMDispatcher." >> >> (Pragma allNamed: #textAreaCommand from: self class to: ABAbstractNode) >> do: [ :e | >> (self perform: e selector) >> do: [ :c | >> | command | >> command := c on: aRequestor textModel for: aRequestor. >> command buildShortcut: aKMDispatcher ] ] >> >> And then the shortcut itself in the Command object. >> >> buildShortcut: aKMDispatcher >> "Add a shortcut to the keymap. Conditions : must have a keystroke, must wantsKeyboard and must be active." >> >> (self keystroke isNil or: [ self wantsKeyboard not or: [ self isActive not ] ]) >> ifTrue: [ ^ self ]. >> aKMDispatcher >> on: self keystroke >> do: [ self execute ] >> >> As you see, the use of KMDispatcher is dynamic and very simple, so I need your comments on how that would fit with Nautilus and the global keymaps, that I have disconnected in my case because they interfere in two ways : KMDispatch randomly chooses which will apply, and that disallows instance based overriding of shortcuts, and I don't want to have to mask all pre-existing shortcuts to avoid pass-through effect (a shortcut get applied because a global map has it and me, for my application, I don't want that to happen). > > given that I am a total ignorant :P, can you explain again in different words why you need > the "ugly" code above? > > If you remove all the hardcoded shortcuts, is your dynamic KMDispatcher switch still necessary? > > I still remember a vague discussion with Guillermo about how to handle local > overrides of keyboard shortcuts, wish I had made a picture of that draft back then :P > > But I think we need a bit more general solution for that problem > (of course if yours works right now, we should definitely go for it now!) > > >

Sept. 12, 2012

[Pharo-project] RE : RE : Keymapping KMShortcut combining

by GOUBIER Thierry

Yes, I was thinking of the $a cmd | $a cmd shift thing. Oh, the ugly code (the one that changes the KMDispatcher, right ?). It's patching the relevant Morphs. The solution you use when you want to hack Morphic without recoding it :( Anything better than that would do, a Spec or Morphic API for the application to be able to reset/recode shortcuts when needed :) a nice when: #keymapChange do: aBlock. Some of the work is to switch to hardcoded Keymappings... and to allow dynamic, instance-based control as well. What I tried is to remove all hardcoded shortcuts, and it works. I then merged my menus and shortcuts, and made sure my application could control which shortcuts were active. But, in the process, I desactivated for my instances the global Keymaps, the one Nautilus uses for its shortcuts. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [camillobruni(a)gmail.com] Date d'envoi : mardi 11 septembre 2012 22:48 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : Keymapping KMShortcut combining On 2012-09-11, at 22:21, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > I've seen the combination and modifiers for Keymapper already; what I would like is the alternative : > > Either > Character tab > or > Character tab ctrl > > (because I've linked tab to nextFocus in a TreeModel, and ctrl + tab in a TextModel (since tab can't be used)) Ok, not much of a gain anyway, so no need to add this to Keymapper. I though once about this as well, so you can do something like $a cmd | $a cmd shift > Ben, Guillermo and StÃ©phane, in AltBrowser, all hard-coded shortcuts are desactivated and only the AltBrowser defined shortcuts are active (and those shortcuts are dependent on the selection and resetted on each selection change : it's mostly a recreation of the existing shortcuts, like doIt, copy/paste, navigation, etc...). It takes as code : > > - A subclass of KMDispatcher with two methods (keymapObservers and dispatchKeystroke:). > - The code to replace each necessary KMDispatcher by this subclass. > - The code to reset and add shortcuts to those KMDispatchers. As far as I remember I once had my own image which used KM shortcuts for all the default shortcuts with proper Settings entries (maybe I find the image somewhere so I can share the settings code (cause it's really only copy pasting...) > So, apart from a bit of incompatibility (ListModel shortcuts in Spec), for Spec it's really easy to push that once you review why I had to do that change to KMDispatcher. For the other parts (SmalltalkEditor), it's a matter of replacing some class configs by KMShortcuts. I believe someone with Nautilus knowledge would be nice : it is the heaviest user of shortcuts, and I really don't use shortcuts in the same way. A merge of both is probably necessary. > > For example, I have this method, called each time the selection changes : > > updateTextKeymap > "Update the text keymap. Change the key dispatcher if needed. Change all dispatchers to force and really force default shortcuts not to be used." > > | keyMorph | > keyMorph := self targetShortcutMorph. > (textModel widget kmDispatcher isKindOf: AltKMDispatcher) > ifFalse: [ textModel widget setProperty: #kmDispatcher toValue: (AltKMDispatcher target: textModel widget) ]. > (keyMorph kmDispatcher isKindOf: AltKMDispatcher) > ifFalse: [ keyMorph setProperty: #kmDispatcher toValue: (AltKMDispatcher target: keyMorph) ] > ifTrue: [ keyMorph kmDispatcher reset ]. > self selectedItem notNil > ifTrue: [ self selectedItem item buildTextShortcutsOn: keyMorph with: self ] > > And, in the select object side : > > buildTextShortcutsOn: aKMDispatcher with: aRequestor > "This is an attempt at handling shortcuts... Which works, with the help of a custom KMDispatcher." > > (Pragma allNamed: #textAreaCommand from: self class to: ABAbstractNode) > do: [ :e | > (self perform: e selector) > do: [ :c | > | command | > command := c on: aRequestor textModel for: aRequestor. > command buildShortcut: aKMDispatcher ] ] > > And then the shortcut itself in the Command object. > > buildShortcut: aKMDispatcher > "Add a shortcut to the keymap. Conditions : must have a keystroke, must wantsKeyboard and must be active." > > (self keystroke isNil or: [ self wantsKeyboard not or: [ self isActive not ] ]) > ifTrue: [ ^ self ]. > aKMDispatcher > on: self keystroke > do: [ self execute ] > > As you see, the use of KMDispatcher is dynamic and very simple, so I need your comments on how that would fit with Nautilus and the global keymaps, that I have disconnected in my case because they interfere in two ways : KMDispatch randomly chooses which will apply, and that disallows instance based overriding of shortcuts, and I don't want to have to mask all pre-existing shortcuts to avoid pass-through effect (a shortcut get applied because a global map has it and me, for my application, I don't want that to happen). given that I am a total ignorant :P, can you explain again in different words why you need the "ugly" code above? If you remove all the hardcoded shortcuts, is your dynamic KMDispatcher switch still necessary? I still remember a vague discussion with Guillermo about how to handle local overrides of keyboard shortcuts, wish I had made a picture of that draft back then :P But I think we need a bit more general solution for that problem (of course if yours works right now, we should definitely go for it now!)

Sept. 11, 2012

Re: [Pharo-project] SmallLint and Manifest

by StÃ©phane Ducasse

On Sep 11, 2012, at 10:44 PM, Mariano Martinez Peck wrote: > Hi Simon. I have just run it in Tanker. It already help me to detect a couple of things :) > Some feedback: > > 1) Is there a way to set the package of the Manifest class? normally it should always go to the package automatically. > Because I don't like the default package where it goes.... > Now it is even worst because it goes to "UndefinedPackage": this is probably because of the shaking of rpackage. > > 2) I have a weird bug rendering some text. (look attached) > > Thanks! > > On Tue, Sep 11, 2012 at 7:19 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > I started to use it, and I will have suggestion on the GUI. > > Cheers, > Alexandre > > > On Sep 11, 2012, at 1:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > excellent! > > Simon what about producing a video so that the world can see your nice tool in action. > > > > Stef > > > > > > On Sep 11, 2012, at 4:21 PM, Simon Allier wrote: > > > >> I have fix the error found by Camillo, now it works with all packages and rules in the last pharo 2.0 image. > >> > >> On Sep 11, 2012, at 4:13 PM, Mariano Martinez Peck wrote: > >> > >>> > >>> > >>> On Mon, Sep 10, 2012 at 11:53 PM, Simon Allier <simon.allier(a)inria.fr> wrote: > >>> Hi, > >>> > >>> I have published a new version of the Critics Browser (menuWorld > Tool > CriticBrowser). > >>> The new version is > >>> - refactoring friendly. Yes we listened to you :). > >>> > >>> hehehe I felt touched by that ;( > >>> Thanks Simon, these are really great news because it doesn't mean we have to throw the manifiest away after a couple of refactors :) > >>> I will re-run everything with Fuel soon and give you any feedback I have. > >>> > >>> - the browser has been improved. It works with the latest Spec. > >>> > >>> With the Critics browser you can inspect violations of the SmallLint rules and mark them as false positive or true positive (ToDo) and see previous warnings flagged as false positives or toDo. > >>> In addition all the logic of the browser has been developed so that the manifest can be saved within the package without adding dependencies. > >>> > >>> In this new version the format of the manifest has changed to be compatible with tools refactoting, the rules are organized in a tree and itâs possible to adds comment when we mark a false positive or todo. > >>> > >>> We are writing a nice chapter on SmallLint, critics and other for the new book. Soon we will release it for reviews. > >>> > >>> Gofer > >>> new > >>> url: 'http://www.squeaksource.com/PharoTaskForces'; > >>> package: 'ConfigurationOfManifest'; > >>> load. > >>> ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load > >>> > >>> Simon > >>> > >>> > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >> > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > <Screen shot 2012-09-11 at 10.18.11 PM.png>

Sept. 11, 2012

Re: [Pharo-project] RE : Keymapping KMShortcut combining

by Camillo Bruni

On 2012-09-11, at 22:21, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > I've seen the combination and modifiers for Keymapper already; what I would like is the alternative : > > Either > Character tab > or > Character tab ctrl > > (because I've linked tab to nextFocus in a TreeModel, and ctrl + tab in a TextModel (since tab can't be used)) Ok, not much of a gain anyway, so no need to add this to Keymapper. I though once about this as well, so you can do something like $a cmd | $a cmd shift > Ben, Guillermo and StÃ©phane, in AltBrowser, all hard-coded shortcuts are desactivated and only the AltBrowser defined shortcuts are active (and those shortcuts are dependent on the selection and resetted on each selection change : it's mostly a recreation of the existing shortcuts, like doIt, copy/paste, navigation, etc...). It takes as code : > > - A subclass of KMDispatcher with two methods (keymapObservers and dispatchKeystroke:). > - The code to replace each necessary KMDispatcher by this subclass. > - The code to reset and add shortcuts to those KMDispatchers. As far as I remember I once had my own image which used KM shortcuts for all the default shortcuts with proper Settings entries (maybe I find the image somewhere so I can share the settings code (cause it's really only copy pasting...) > So, apart from a bit of incompatibility (ListModel shortcuts in Spec), for Spec it's really easy to push that once you review why I had to do that change to KMDispatcher. For the other parts (SmalltalkEditor), it's a matter of replacing some class configs by KMShortcuts. I believe someone with Nautilus knowledge would be nice : it is the heaviest user of shortcuts, and I really don't use shortcuts in the same way. A merge of both is probably necessary. > > For example, I have this method, called each time the selection changes : > > updateTextKeymap > "Update the text keymap. Change the key dispatcher if needed. Change all dispatchers to force and really force default shortcuts not to be used." > > | keyMorph | > keyMorph := self targetShortcutMorph. > (textModel widget kmDispatcher isKindOf: AltKMDispatcher) > ifFalse: [ textModel widget setProperty: #kmDispatcher toValue: (AltKMDispatcher target: textModel widget) ]. > (keyMorph kmDispatcher isKindOf: AltKMDispatcher) > ifFalse: [ keyMorph setProperty: #kmDispatcher toValue: (AltKMDispatcher target: keyMorph) ] > ifTrue: [ keyMorph kmDispatcher reset ]. > self selectedItem notNil > ifTrue: [ self selectedItem item buildTextShortcutsOn: keyMorph with: self ] > > And, in the select object side : > > buildTextShortcutsOn: aKMDispatcher with: aRequestor > "This is an attempt at handling shortcuts... Which works, with the help of a custom KMDispatcher." > > (Pragma allNamed: #textAreaCommand from: self class to: ABAbstractNode) > do: [ :e | > (self perform: e selector) > do: [ :c | > | command | > command := c on: aRequestor textModel for: aRequestor. > command buildShortcut: aKMDispatcher ] ] > > And then the shortcut itself in the Command object. > > buildShortcut: aKMDispatcher > "Add a shortcut to the keymap. Conditions : must have a keystroke, must wantsKeyboard and must be active." > > (self keystroke isNil or: [ self wantsKeyboard not or: [ self isActive not ] ]) > ifTrue: [ ^ self ]. > aKMDispatcher > on: self keystroke > do: [ self execute ] > > As you see, the use of KMDispatcher is dynamic and very simple, so I need your comments on how that would fit with Nautilus and the global keymaps, that I have disconnected in my case because they interfere in two ways : KMDispatch randomly chooses which will apply, and that disallows instance based overriding of shortcuts, and I don't want to have to mask all pre-existing shortcuts to avoid pass-through effect (a shortcut get applied because a global map has it and me, for my application, I don't want that to happen). given that I am a total ignorant :P, can you explain again in different words why you need the "ugly" code above? If you remove all the hardcoded shortcuts, is your dynamic KMDispatcher switch still necessary? I still remember a vague discussion with Guillermo about how to handle local overrides of keyboard shortcuts, wish I had made a picture of that draft back then :P But I think we need a bit more general solution for that problem (of course if yours works right now, we should definitely go for it now!)

Sept. 11, 2012