Hi Nicolai, Did we clarify this issue? Is there something else I can help (or maybe to disturb/annoy :)) with ?
Cheers, Doru > On Aug 10, 2016, at 5:11 PM, Tudor Girba <[email protected]> wrote: > > 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 <[email protected]> wrote: >> >> >> >> 2016-08-09 23:36 GMT+02:00 Tudor Girba <[email protected]>: >> Hi, >> >>> On Aug 9, 2016, at 11:31 PM, Nicolai Hess <[email protected]> wrote: >>> >>> >>> >>> 2016-08-09 22:53 GMT+02:00 Tudor Girba <[email protected]>: >>> Hi, >>> >>>> On Aug 9, 2016, at 10:48 PM, Nicolai Hess <[email protected]> wrote: >>>> >>>> >>>> >>>> 2016-08-09 18:12 GMT+02:00 Tudor Girba <[email protected]>: >>>> 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." > > > > -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."
