Hi! Sorry for the late response... I'm covered with stuff to do lately.
To my understanding we are mixing these different issues: 1) whether the global shortcuts should have or not priority over local shortcuts. To my understanding that's what operating systems do. You cannot override alt+tab and if you intend, it will just not work. If any application can override alt+tab, the system will feel inconsistent for the users. So global shortcuts have priority with this intend: Not let the tools mess with what Pharo has decided the global shortcuts should be. 2) which are the actions that should be available globally though a shortcut. This deserves for sure a different discussion than 1). Should we put all tools in there? The more we put, the more difficult is to put shortcuts locally in tools. In any case I think this is orthogonal to 1). 3) are the shortcuts we chose for the tools the right ones? I think the "prefixed" shortcuts chosen for the tools were thought as a kind of namespace for the shortcuts. Again, I find this orthogonal to 1). 4) About the collision issue. First, it is an issue that appeared when people started to use keymappings :). The original intent was to let the user manage the collisions, because I find there is not a perfect solution. - if we make first single, then complex matching only local to a morph, then a complex match from a child would override a single match from a parent. - if we make first single, then complex matching *all over the hierarchy*, we may find a single match from a parent overriding a complex shortcut of a child. A second issue, partially related to the resolution strategy, is the Set that should not be there because it provides a random ingredient. However, at the same time it makes you think about not creating collisions in the same morph :). Actually, if you remove the randomness and configure a morph with: cmd+a => do something cmd+a, cmd+b => do other something Either the first or the second will never be executed depending on the strategy you choose (first single then complex, or the opposite). So I find this a buggy configuration, randomness or not randomness. Cheers, Guille On Mon, Apr 14, 2014 at 3:31 PM, Tudor Girba <[email protected]> wrote: > Hi, > > I agree that the behavior is not ideal, but it only occurs when you have > collisions. And of course it would be great to have everything working > perfectly, but at this point it is more important to release. That is why, > in my book, it is more important to reduce the impact (fast) than it is to > solve it properly (slow). > > The problem was noticed in few cases. I for one only noticed it after the > global shortcuts were introduced in the image. Hence, it is very likely to > achieve a good enough state with little effort by removing the shortcuts. > > Of course, if someone else does have a better solution, he can propose it, > but it has to be concrete and doubled by the effort that comes with > developing and testing it :) > > Doru > > > On Mon, Apr 14, 2014 at 3:22 PM, GOUBIER Thierry > <[email protected]>wrote: > >> Tudor, >> >> an implementation which randomly determines which shortcut will match is >> a bug to me, and one worthy of being solved before release. >> >> Why wouldn't Moose alone desactivate the global shortcuts if that seems >> the solution? >> >> Thierry >> >> ------------------------------ >> *De :* Pharo-dev [[email protected]] de la part de Tudor >> Girba [[email protected]] >> *Envoyé :* lundi 14 avril 2014 15:15 >> >> *À :* Pharo Development List >> *Objet :* Re: [Pharo-dev] 13102 >> >> Hi, >> >> Sorry for not replying before but I was offline. This issue is not to >> fix Keymapping at this point. The current solution was designed with intent >> to work in the current way. We can certainly discuss about fixing it, but >> the solution is not for Pharo 3. >> >> The current discussion is about disabling the global shortcuts for >> opening the Workspace and other tools. In the Moose image, we disable those >> shortcuts because with the current implementation of Keymapping having >> complicated global keybindings simply leads to problems (for example, we >> cannot use Cmd+o for anything). Do not get me wrong: Keymapping is an >> excellent contribution that simplified a lot an important area. My >> suggestion is to remove the global mappings for Pharo 3.0, and then >> continue to work on getting Keymappings to an even better state. >> >> Doru >> >> >> On Mon, Apr 14, 2014 at 2:49 PM, GOUBIER Thierry >> <[email protected]>wrote: >> >>> Hi Esteban, Marcus, >>> >>> in that particular case, I would propose the following simple fix which >>> could solve the first impression. >>> - Document global shortcuts, ensure that they are single key. >>> - Document an overload (or not) effect when your app redefines a >>> global shortcut. >>> - Change a bit Keymapping so that single key shortcuts match first. >>> >>> This would solve the immediate problem and let us time to consider a >>> more complex solution for Pharo 4. >>> >>> Thierry >>> ________________________________________ >>> De : Pharo-dev [[email protected]] de la part de >>> Esteban Lorenzano [[email protected]] >>> Envoyé : lundi 14 avril 2014 14:39 >>> À : Pharo Development List >>> Objet : Re: [Pharo-dev] 13102 >>> >>> On 14 Apr 2014, at 14:28, Marcus Denker <[email protected]> wrote: >>> >>> > >>> > On 13 Apr 2014, at 11:26, Stephan Eggermont <[email protected]> wrote: >>> > >>> >> Hi Marcus, >>> >> >>> >> I think 13102 is a showstopper. Can’t explain this to new users. >>> >> >>> >>> sorry, but I have to disagree… this is an important problem, I agree. >>> But fix that will need (AFAIK) a lot of work and probably a revamp of >>> the keybindings in system. >>> Also… this problem was (again, AFAIK) present since pharo2 and we have >>> been able to continue working even with that annoyance. >>> >>> We will always have problems to fix. And we still have many *really >>> important* problem to fix. But if we do not release even with some bugs, we >>> will never release. >>> >>> "Show stopper” IMO, is a bug that prevents the system to continue >>> working. Explain to students an annoyance in the system is bad, but not >>> show stopper. >>> >>> so… I’m with Marcus. We can delay this fix. But I also believe this kind >>> of problems are a “shoot in the foot”, not good for attract newcomers. >>> That’s why we are suggesting that Pharo4 should centred on the tooling: >>> we have the feeling that out tools are one (or several) step(s) behind the >>> power that pharo has. >>> >>> Esteban >>> >>> > >>> > The question is do we hold up the release for it? >>> > That is: is not releasing better than releasing with this? >>> > >>> > How long do we stop releasing, considering that we will not find >>> > anyone to fix it? >>> > >>> > Marcus >>> > >>> > >>> >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >
