[Pharo-dev] 13102

Guillermo Polito guillermopolito at gmail.com
Wed Apr 16 05:46:52 EDT 2014


Bump :)


On Mon, Apr 14, 2014 at 4:30 PM, Guillermo Polito <guillermopolito at gmail.com
> wrote:

>
>
>
> On Mon, Apr 14, 2014 at 4:23 PM, Guillermo Polito <
> guillermopolito at gmail.com> wrote:
>
>>
>>
>>
>> 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.
>>>
>>
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 <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/20140416/2ac8fca8/attachment-0002.html>


More information about the Pharo-dev mailing list