guillermopolito at gmail.com
Mon Apr 14 10:18:35 EDT 2014
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
- 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.
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
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.
On Mon, Apr 14, 2014 at 3:31 PM, Tudor Girba <tudor at tudorgirba.com> wrote:
> 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 :)
> On Mon, Apr 14, 2014 at 3:22 PM, GOUBIER Thierry <thierry.goubier at cea.fr>wrote:
>> 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?
>> *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
>> 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.
>> 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.
>>> 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.
>>> > 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
>> "Every thing has its own flow"
> "Every thing has its own flow"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev