On Mon, Apr 14, 2014 at 4:23 PM, Guillermo Polito <[email protected] > wrote:
> > > > 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. > And here I meant by global resolution = *all over the hierarchy*, silly me, I'm hungry. > > >> >> 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" >>> >> >> >
