On Mon, Apr 14, 2014 at 4:18 PM, Guillermo Polito <[email protected] > wrote:
> 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. > Just to complete my thoughts and provide my position about this issue. I would rather go for the first solution: favor local over global resolution because we will find less bugs. > > 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" >> > >
