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" :(
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."