Bump :)
On Mon, Apr 14, 2014 at 4:30 PM, Guillermo Polito <[email protected] > wrote: > > > > 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. >>> >> So, any points against or in favor to this? > >>> 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). >>> >> Do we open a new thread to discuss this? I think it's important to discuss what is available globally through a shortcut and what's not, and what such shortcuts should be. The only thing I need is: - Spotlight - Finder? - Workspace? - The main menu? The browser I don't really need it because I use spotlight. The finder can cover almost all stuff I search normally trough a workspace :). Even if this is not for Pharo3, it's important for Pharo4. > >>> 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" >>>> >>> >>> >> >
