2016-08-07 22:59 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
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
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.