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
Cheers, Doru
right now spotter defines the shortcut on the spotter morph. This won' t work if rubtext components define the word-movement with the kmdispatcher. ( I already explained why).
Cheers, Doru
What do you think?
Doru
Cheers, Doru
On Jun 18, 2016, at 8:42 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-06-17 18:25 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi Nicolai,
On Jun 17, 2016, at 2:59 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-06-17 14:35 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi Nicolai,
I am a bit removed from the code details at the moment, and I think I need to step back a bit :).
If I understand correctly, you are saying that: 1. defining bindings with #alt does not work on Windows. This means that we should fix this one. Using Cmd should not be a solution here.
As far as I know, this is on purpose. A key pressed with windows (left) alt modified is mapped to "command"
from vm source:
* 3) The modifier keys are mapped as follows: * * Mac | Win32 * -------------------- * Shift -> Shift * Ctrl -> Ctrl * Command -> Left ALT * Option -> Right ALT
(but actually, the right ALT key does not generate any keystrokes (only key down/up) and it is treated as ctrl+alt (windows right Alt key is "Alt Grâ)
Hmm. I think we have to rethink this one because we need two layers of keys: 1. first we should have the raw ones, and
what are the "raw" ones? The events the OS generates or the events the VM send out to the image?
2. another layer that offers a more logical keys (like meta).
Can you explain this a bit more.
What do you think?
2. defining the bindings for Spotter can indeed be made to override the ones in the text editor if needed. But, I think we can start thinking about using #alt.
using alt+right on windows/linux and command + right on mac for dive-in or for text navigation?
Is there a default keycombination for word-moving in text components for mac ?
On Mac, typically Alt+Right/Left moves between words.
So, we would need a logical modifier that would mean: - Mac: Alt - Win: Ctrl - Linux: Ctrl
I though this is what Guillermo already did, but with "command"
- Mac: Command - Win/Linux: Ctrl
Why did we choose Command and not Alt in the first place, why is Alt now better?
What do you think?
Cheers, Doru
Does this make sense?
Cheers, Doru
On Jun 17, 2016, at 12:12 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-06-16 22:45 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
I think we are mixing the topics a bit. The #meta discussion is not specific to Spotter actions.
On windows, it is. Because on windows #meta is mapped to #ctrl, and you can use ctrl+left/right for moving by "words". This works in a browser, an editor, pharos text components but *not* in spotter because spotter redefines this keystrokes for dive in /out. Currently, both ctrl+left/right and alt+left/right (and shift for selection) are working in rubric for moving by "word". But only because the (old) shortcut (cmd/shiftcmd) action dispatcher explicitly allows both. If we want to remove this and use the KMDispatcher framework only, we *need* to define only one mapping, otherwise you won't be able to use dive in/out in spotter. (Or you could modify spotter to register(overwrite) the mapping on the textfield instead of the spotter morph).
The idea was to offer a uniform support of keybindings in Pharo, in general.
exactly, and using ctrl+left/right uniformly in editor and external tools would be great.
Then Guille etal added #meta to have a predictable mapping.
Yes, and to make this work, we have to remove the old keymapping implementation (cmd/shiftcmd action map) and use the KMDispatcher registration. But I can only continue with this if we have a decision what to use, (windows/linux: either ctrl+arrow or alt+arrow, mac: whatever is used on a mac for text navigation)
All #cmd places were changed to #meta, and since then we should not use explicitly #cmd anymore, except when we know we are on Mac. For a portable modifier, we should only use #meta.
At this point, both Rubric and Spotter use #meta. #meta maps on: - Mac: Command - Win: Control - Linus: Control
This means that #alt is now a portable modifier that will not conflict with #meta, so we can now think of using that one in combination with #meta.
You can not use #alt modifier on windows. A shortcut definition like $g alt is never recognized. You have to define it $g command to make it work with as "alt+g"-keycombination (on windows).
For text navigation, the situation is a bit complicated. On Win/Linux, Ctrl+Right/Left moves the cursor between words. On Mac, Cmd+Right/Left moves the cursor at the end/beginning of line. So, using #meta for text navigation between words is not entirely accurate. We should use #ctrl instead.
This would anyway mean that it would be an option to use #alt for Spotter now. But, if we are at it, would anyone be interested in working on revisiting the overall keybindings in Pharo?
Cheers, Doru
On Jun 16, 2016, at 10:22 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei@gmail.com>: We can, but I remember there were some discussions and it was decided to use meta everywhere.
Cheers, Andrei
If we don't change this, I'll use cmd+left cmd+right in rubric, but this is bad, because all other navigate/select+navigate shortcuts would use meta as shortcut modifier.
What are the arguments for using meta for dive-in/out shortcuts ?
On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei@gmail.com>: During Pharo 5 most shortcuts from tools were changed to use "meta" instead of cmd.
Cheers, Andrei
Can we change this for spotter ? cmd instead of meta
ctrl left/right is often used for text components to move to next/previous word.
On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com>:
Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <henrik.nergaard@uia.no>:
IIRC the shortcut is not changed, it still is meta+right(+shift). Only the tooltip was changed to display the system specific key instead of âcmdâ so for Windows/Linux this would be âctrlâ.
No, it changed
In #40624, for example, it was cmd (alt-key on windows ) right/shift right
Best regards,
Henrik
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess Sent: Tuesday, June 7, 2016 12:56 PM To: Pharo Development List <pharo-dev@lists.pharo.org> Subject: [Pharo-dev] GT-Spotter dive in shortcut
Why did the shortcut for dive-in element/category changed from
cmd+right
cmd+shift+right
to
ctrl+right ctrl+shift+right
I know there were some discussions about this and that the behavior changed some
time ago, but I don't know the rational behind this.
thanks
nicolai
-- www.tudorgirba.com www.feenk.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
-- www.tudorgirba.com www.feenk.com
"Quality cannot be an afterthought."
-- www.tudorgirba.com www.feenk.com
"Being happy is a matter of choice."
-- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
-- www.tudorgirba.com www.feenk.com
"Don't give to get. Just give."
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
-- www.tudorgirba.com www.feenk.com
"We cannot reach the flow of things unless we let go."
-- www.tudorgirba.com www.feenk.com
"It's not how it is, it is how we see it."
-- www.tudorgirba.com www.feenk.com "Beauty is where we see it."