Hi,

> On Aug 7, 2016, at 9:15 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
>
>
>
> 2016-08-07 19:58 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
>
> > On Aug 7, 2016, at 6:24 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
> >
> >
> >
> > 2016-08-07 16:23 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
> > Hi,
> >
> > > On Aug 7, 2016, at 4:13 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
> > >
> > >
> > >
> > > 2016-08-07 15:23 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
> > > Hi,
> > >
> > >
> > > > On Aug 3, 2016, at 11:16 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
> > > >
> > > >
> > > >
> > > > 2016-08-03 10:02 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
> > > > Hi,
> > > >
> > > > > On Aug 3, 2016, at 9:16 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > 2016-06-18 23:34 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
> > > > >
> > > > >
> > > > > 2016-06-18 20:55 GMT+02:00 Tudor Girba <tudor@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