Oh man :). Ok I think got it now. Thanks for the patience. I see the confusion: the agreement was that we will override the shortcut in the Spotter text-input. So, let’s go for this.
The layering thing was supposed to be a separate issue. Cheers, Doru > On Aug 10, 2016, at 12:05 AM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > 2016-08-09 23:36 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > Hi, > > > On Aug 9, 2016, at 11:31 PM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > > > > > 2016-08-09 22:53 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > > Hi, > > > > > On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > > > > > > > > > 2016-08-09 18:12 GMT+02:00 Tudor Girba <tu...@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. > > Ok. What should I do? > > > > > 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. > > Ok once again. > ctrl+arrow and meta+arrow both do cursor movements in rubrik, but it is > registered on the action/cmd-map (RubTextEditor>>defaultCommandKeymapping) > ctrl+arrow do dive-in/dive-out in spotter, this is registered on spotters > window, and this takes precedence over rubrics crtrl+Arrow handling because : > > 1. kmdispatcher looks in rubrics editor kmregistry -> no action > 2. kmdispatcher looks in rubrics morph kmregistry -> no action > .... up the morphs owner chain until it reaches spotter > x. kmdispatcher looks in spotters window morph kmregistry -> Action! Dive-in > / Dive-out > > Now! If I move ctrl+Arrow shortcut registration for cursor movement from > rubrics action/-cmd-map to its kmdispatcher registration, the following > happens > 1. kmdispatcher looks in rubrics editor kmregistry -> Action ! move the cursor > > -> no spotter dive-in/dive-out anymore :-( > > two solutions: > use a different shortcut for cursor movement (that is what I aksed in this > thread, and why I opened issue 18432) > use a different shortcut for spotter (this is why I started this thread and > asked why this was changed at all) > overwrite spotters shortcut registration (just like now, but not on spotters > window, but on the text field (I opened now a fogbugz issue 18900)) > > anyway, you said, you want to wait with changing spotters shortcut > registration until we have the new layers, therefore I can only wait until > that > happens. > > > > > 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." -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."
