[Pharo-dev] 13102

Guillermo Polito guillermopolito at gmail.com
Mon Apr 14 10:23:15 EDT 2014


On Mon, Apr 14, 2014 at 4:18 PM, Guillermo Polito <guillermopolito at gmail.com
> 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 <tudor at tudorgirba.com> 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 <thierry.goubier at cea.fr>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 [pharo-dev-bounces at lists.pharo.org] de la part de
>>> Tudor Girba [tudor at tudorgirba.com]
>>> *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 <thierry.goubier at cea.fr
>>> > 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 [pharo-dev-bounces at lists.pharo.org] de la part de
>>>> Esteban Lorenzano [estebanlm at gmail.com]
>>>> Envoyé : lundi 14 avril 2014 14:39
>>>> À : Pharo Development List
>>>> Objet : Re: [Pharo-dev] 13102
>>>>
>>>> On 14 Apr 2014, at 14:28, Marcus Denker <marcus.denker at inria.fr> wrote:
>>>>
>>>> >
>>>> > On 13 Apr 2014, at 11:26, Stephan Eggermont <stephan at stack.nl> 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"
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20140414/d92d6b69/attachment-0002.html>


More information about the Pharo-dev mailing list