2016-08-07 22:59 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > Hi, > > > On Aug 7, 2016, at 9:15 PM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > > > > > > 2016-08-07 19:58 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > > > > > On Aug 7, 2016, at 6:24 PM, Nicolai Hess <nicolaih...@gmail.com> > wrote: > > > > > > > > > > > > 2016-08-07 16:23 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > > > Hi, > > > > > > > On Aug 7, 2016, at 4:13 PM, Nicolai Hess <nicolaih...@gmail.com> > wrote: > > > > > > > > > > > > > > > > 2016-08-07 15:23 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > > > > Hi, > > > > > > > > > > > > > On Aug 3, 2016, at 11:16 AM, Nicolai Hess <nicolaih...@gmail.com> > wrote: > > > > > > > > > > > > > > > > > > > > 2016-08-03 10:02 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > > > > > Hi, > > > > > > > > > > > On Aug 3, 2016, at 9:16 AM, Nicolai Hess <nicolaih...@gmail.com> > wrote: > > > > > > > > > > > > > > > > > > > > > > > > 2016-06-18 23:34 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>: > > > > > > > > > > > > > > > > > > 2016-06-18 20:55 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: > > > > > > Hi, > > > > > > > > > > > > Command is an actual key on Mac next to Option(which is Alt) and > Control. So, Command is a concrete key and mapping it logically to another > key on another platform is mixing semantics. > > > > > > > > > > > > I propose to have two distinct layers in the image: > > > > > > 1. the raw layer is about having a distinct selector for each > concrete key that is found on the keyboard. Right now, it seems to me that > the VM does a bit of interpretation and mapping, and if it does, I think it > should just provide a distinct code for each distinct key. > > > > > > 2. the portable layer is about having a couple of selectors > (e.g., #meta, #secondaryMeta) that provide consistent mappings to the raw > keys. > > > > > > > > > > > > So, in this way, #command/#control/#alt would belong to layer 1. > and #meta/#secondaryMeta (we could find a better name) would belong to > layer 2. > > > > > > > > > > > > Does this make sense? > > > > > > > > > > > > > > > > > > So, what does that mean for the text navigation mapping in > Rubric. Which shortcut should I use? > > > > > > > > > > > > Any way to take a decision? > > > > > > > > > > > > I don't really want to wait until we implement a new layer. > > > > > > > > > > Thanks for the ping. > > > > > > > > > > I think that you cannot use now properly a uniform shortcut if we > do not introduce these “layers”. I also think that we are talking about a > couple of methods, so the effort is only in making the decision. I think > that given that nobody disagreed, we can go ahead with it. > > > > > > > > > > For the specific question related to text navigation in Rubric, > you could use #meta. > > > > > > > > > > But how? > > > > > If I add this to RubTextEditor class>>#buildShortcutsOn: aBuilder > > > > > > > > > > > > > > > (aBuilder shortcut: #nextWord) > > > > > category: RubTextEditor name > > > > > default: Character arrowRight meta > > > > > do: [ :target :morph :event | target editor cursorRight: > event] > > > > > description: 'move to next word'. > > > > > > > > > > > > > > > > > > > > (aBuilder shortcut: #previousWord) > > > > > category: RubTextEditor name > > > > > default: Character arrowLeft meta > > > > > do: [ :target :morph :event | target editor cursorLeft: > event] > > > > > description: 'move to the previous word'. > > > > > > > > > > > > > > > we can not dive in/out in spotter. > > > > > > > > > > This is why I asked: > > > > > > > > > > Why did the shortcut for dive-in element/category changed from > > > > > cmd+right > > > > > cmd+shift+right > > > > > to > > > > > ctrl+right > > > > > ctrl+shift+right > > > > > > > > Oh, I see now! > > > > > > > > The change was made from cmd+right to meta+right in the move of > Guille to make all keybindings uniform. > > > > > > > > If a keybinding would be problematic in Spotter, we could also > override the keybinding directly in the Spotter editor, I think. What do > you think? > > > > > > > > what is Spotter editor? if it is the text input field, yes, but you > have to overwrite it on this morph > > > > > > That is what I meant, to define the keys for diving twice, once in the > spotter morph and once in the text input field. This should solve the > problem, right? > > > > > > twice ? > > > > On a second thought, this is probably not needed because the focus > should always be in the text input morph :). > > > > Still, we would only do that after we introduce the “layering”. > > > > Would this be Ok with you? > > > > Cheers, > > Doru > > > > Oh well .... > > Please take a look at the current implementation of event handling, just > 10 minutes or so. > > how we use different (shortcut) event registration > > shortcut handling > > event handling > > some are defined in code, some shortcuts handled by the editor , some by > the morph > > some shortcuts are defined on the morph that gets the events, some are > defined on other morphs. > > some event (shortcuts spotters dive in / dive out) only works *because* > we have the two shortcut handlers (handleKeystroke: / dispatchKeystroke:) > > > > and tell me that it is a good idea to just start introducing something > new > > > > I really think we should clean up what we have now or at least finish > the move to the kmdispatcher event handling. > > Sure, but I think the two issues are independent from each other. > > I think that we can add the “layers” that I mentioned on top of what we > have right now to offer tools built on top a choice of platform-independent > modifiers, and then we can still continue cleaning underneath. > > I mean, if we change #meta and add #secondaryMeta it should work, not? Or > do I miss something? > > Cheers, > Doru > > 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.
