Hi,
Ok. What should I do?
> On Aug 9, 2016, at 11:31 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
>
>
>
> 2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
> Hi,
>
> > On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
> >
> >
> >
> > 2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
> > Hi,
> >
> > >
> > > Hey Doru,
> > > about what "two issues" are we talking? My only issue for now is,
> > > what shortcut shold we use for moving the cursor forward/backward word. Even if we introduce a new layer, at some point in time you need to
> > > define: If�� the user types the CTRL+LEFT -key, even if we call it differently, some action happens, dive-out or move-backward-word ?
> > > At the moment (on windows) you can use both to move word-by-word:
> > > ctrl+left/right and alt+left/right, because this is how it is defined in rubrics action/cmdaction map.
> > >
> > > If we want to clean this up and use the kmdispatcher registration, I think we don't want to use both ctr and alt again, right?
> > > So, someone has to take the decision.
> > > I myself would prefer
> > > ctrl+left/right because this is what (all) many other programs are using on windows. Fine. But recently Spotter changed its
> > > dive in / dive out shortcut to use ctrl+left/right.
> > > Therefor I am asking you, why, and whether we want to keep it or not. If we want to keep it, we may
> > > - just overwrite the binding for the textfield -> not good, I think, you wouldn't be able to do word-by-word movements in the textfield anymore
> > > - overwrite the binding and use another binding for word-by-word moving, but just in spotters text field
> > > Or we revert that change and use the old shortcuts again.
> > > (And what to use for mac and linux?)
> > >
> > > but I am getting really tired of asking, and will do something else instead.
> >
> > The short answer: we will override the keybinding in the text morph for now. This will mean that we cannot move word by word in the text field using #control, but it will be consistent with all other platforms. Could you open an issue for this, please?
> >
> >
> > consistens on all platforms may not be the expectation for all users. Some users only working on a windows platform may want to have consistent behavior for all tools (applications).
>
> Well, you wanted a decision :).
>
>
> > On top of that, we will externalize all GTSpotter shortcuts through settings:
> > https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts- should-be-externalized-as- settings
> >
> > I really don't know why that.
>
> Because we do not have a generic KMDispatcher mechanism :).
>
> yes and it does not make much sense as not all shortcuts are handled by the kmdispatcher, thats why cleaning this
> up and I think it would be better to do this instead of implementing yet another only-for-this-tool solution.
> > We don't need a way to make Spotter shortcuts configurable, but *all* shortcuts.
> > That is why I try to move all shortcut definitions to the kmdispatcher, but it yet again took 2 month just to discuss what shortcut to use for cursor movement.
>
> I am not sure I understand. Was this me that stalled the discussion? If yes, it was not intentional. Is there anything I can do about this subject?
>
> The whole discussion, the me: "hey, what shortcut to use?" you:"hey we have a great idea, just let us add some new layers" :(
I think I miss something because I do not see how the layers have anything to do with the cursor movement. Or do you mean for diving in Spotter? I still think that the layers idea is a relevant one and does not conflict with anything we talked about here.
In any case, I did not mean to confuse anyone. Please take the lead concerning the KMDispatcher and I can review if you want.
Doru
> Cheers,
> Doru
>
>
> >
> > Long answer: As explained before, the shortcut changed in the process of making all shortcuts uniform when Guille introduced #meta instead of #command (like it was before). The thing is that currently:
> > - #command means #alt on Win and #command on Mac, and
> > - #meta means #control on Win and #command on Mac.
> >
> > But, #command should be a low level key, not a portable one. It should not have a meaning on Windows, because the key does not exist on that platform.
> >
> > Moving to make keybindings uniform is a good thing, but only having #meta is not enough for situation like the one you mention. That is why I am proposing to introduce a #secondaryMeta as a platform-independent modifier that would mean #alt on Win and #control on Mac. We could use that one more consistently. Is this a better explanation?
> >
> > Cheers,
> > Doru
> >
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Presenting is storytelling."
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "One cannot do more than one can do."
--
www.tudorgirba.com
www.feenk.com
"When people care, great things can happen."