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
is most probably an error :S
On 07 Jun 2016, at 12:55, Nicolai Hess <nicolaihess@gmail.com> wrote:
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
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â. 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
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
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
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
During Pharo 5 most shortcuts from tools were changed to use "meta" instead of cmd. Cheers, Andrei 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
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
We can, but I remember there were some discussions and it was decided to use meta everywhere. Cheers, Andrei 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
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.
but using meta everywhere does not help if there are conflicts with other shortcuts.
Cheers, Andrei
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
For coherence, the vast majority of shortcuts should follow the standard in all applications. Most shortcuts use cmd in mac, and ctrl in unix/win. Then there are exceptions of course. I'd like exceptions to be that, exceptions, and well documented. I'm not against using #alt for particular cases (for example, it is often used in windows/linux for menu navigation). Also, I'd like shortcuts that are meant to be used with #alt to use #alt and not #command. Because #command means the windows key in windows. That said, If the problem are shortcut conflicts, I think it would be nice at some moment to make a step back, look at the big picture and design shortcuts for the entire system instead of patching place over place :). Guille -------- Original Message --------
2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>>:
We can, but I remember there were some discussions and it was decided to use meta everywhere.
but using meta everywhere does not help if there are conflicts with other shortcuts.
Cheers, Andrei
On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei@gmail.com <mailto: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 <mailto:nicolaihess@gmail.com>> wrote:
2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <henrik.nergaard@uia.no <mailto: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 <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 <mailto: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 > >
Le 7/6/16 à 16:33, Guille Polito a écrit :
For coherence, the vast majority of shortcuts should follow the standard in all applications. Most shortcuts use cmd in mac, and ctrl in unix/win.
Then there are exceptions of course. I'd like exceptions to be that, exceptions, and well documented. I'm not against using #alt for particular cases (for example, it is often used in windows/linux for menu navigation).
Also, I'd like shortcuts that are meant to be used with #alt to use #alt and not #command. Because #command means the windows key in windows.
That said, If the problem are shortcut conflicts, I think it would be nice at some moment to make a step back, look at the big picture and design shortcuts for the entire system instead of patching place over place :). Yes and we should experiment with a hierarchy of command.
and I would love to have cmd k cmd e end of line and others from emacs (of course in my own shortcut bindings preferences :)
Guille -------- Original Message --------
2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>>:
We can, but I remember there were some discussions and it was decided to use meta everywhere.
but using meta everywhere does not help if there are conflicts with other shortcuts.
Cheers, Andrei
On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei@gmail.com <mailto: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 <mailto:nicolaihess@gmail.com>> wrote:
2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>>:
Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <henrik.nergaard@uia.no <mailto: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 <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 <mailto: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 > >
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
Hi, I think we are mixing the topics a bit. The #meta discussion is not specific to Spotter actions. The idea was to offer a uniform support of keybindings in Pharo, in general. Then Guille etal added #meta to have a predictable mapping. 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. 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."
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."
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. 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. 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."
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")
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 ?
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."
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 2. another layer that offers a more logical keys (like meta). 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 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."
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."
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? 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."
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?
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."
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.
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."
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. 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."
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
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."
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? 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?"
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, 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?"
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? 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."
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 ?
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."
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
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."
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.
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."
Hi nicolai I can tell that I'm sad about the state of this part of the system. I do not know how I can help fixing this. What is really important is that we protect future brick from this mess. I think that we should have a structure so that people writing code can follow this structure. I worked a lot trying to clean HandMorph (and my code was obsolete because I was too slow to finish it and SDL arrived :) May be one way would be to remove all the old hardcoded bindings. Stef Le 7/8/16 à 21:15, Nicolai Hess a écrit :
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.
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."
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.
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? On top of that, we will externalize all GTSpotter shortcuts through settings: https://pharo.fogbugz.com/f/cases/18455/Spotter-shortcuts-should-be-external... 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."
2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
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).
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. 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.
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."
Hi,
On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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-external...
I really don't know why that.
Because we do not have a generic KMDispatcher mechanism :).
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? 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."
2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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.
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" :(
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."
Hi,
On Aug 9, 2016, at 11:31 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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-external...
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. 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."
2016-08-09 23:36 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 9, 2016, at 11:31 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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 <https://pharo.fogbugz.com/f/cases/18432/Add-a-RubTextFieldEditor>) 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."
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 <nicolaihess@gmail.com> wrote:
2016-08-09 23:36 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 9, 2016, at 11:31 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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-external...
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."
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 <tudor@tudorgirba.com> 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 <nicolaihess@gmail.com> wrote:
2016-08-09 23:36 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 9, 2016, at 11:31 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 22:53 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 9, 2016, at 10:48 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-09 18:12 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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-external...
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."
On Sun, Jun 19, 2016 at 2:55 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
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.
+1000. We should avoid our abstract shortcut key modifiers overlaping concrete keys.
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.
Sounds good.
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.
Historical alternatives: hyper, super But super looks to already be associated with a concrete key, so that would leave hyper. http://askubuntu.com/questions/19558/what-are-the-meta-super-and-hyper-keys btw, Emacs uses these names https://www.gnu.org/software/emacs/manual/html_node/emacs/Modifier-Keys.html Or, just brainstorming a unique alternative... If meta is thought of as met-a, we could use: metb, meti, meto, metu, mety, metz, mota, miti, moti. I think I like meti or miti for the diminutive / secondary feel of them. p.s. I like this article I bumped into with tips on physical exercises... http://ergoemacs.org/emacs/emacs_pinky.html
Does this make sense?
Very much. In addition, to help the layering (and also to encourage not-using ctrl, alt directly), maybe require a modifier like 'exception' or 'exceptionDirect' or just 'direct' for access to those concrete keys. e.g. f exception ctrl, f exceptionDirect dtrl, f direct ctrl cheers -ben
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>:
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?
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.
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. 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
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.
i,
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. +1000. We should avoid our abstract shortcut key modifiers overlaping concrete keys.
yes it seems like a good idea.
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. Sounds good.
what is secondaryMeta?
Nicolai Hess-3-2 wrote
2016-06-17 18:25 GMT+02:00 Tudor Girba <
tudor@
>:
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?
Not better, just different. In the general case, shortcuts with ctrl use cmd on Mac (like ctrl-c, ctrl-v, etc), but some navigation shortcuts (like previous / next word) use alt on osx where windows use ctrl. So having both meta and alt-meta bindings as I described, lets you represent both, but, due to the nature of alt, some care/restrictions would need to be applied to alt-meta that are not necessary for meta. -- View this message in context: http://forum.world.st/GT-Spotter-dive-in-shortcut-tp4899612p4901704.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
#alt_meta ? - Maps to alt on OSX, ctrl on Win/Linux. - Can only bind either #meta or #alt_meta + key, or both must bind to same action. - Can only be applied to a very limited set of keys, (usually those employed in navigation). (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later) Cheers, Henry
On 17 Jun 2016, at 2:35 , Tudor Girba <tudor@tudorgirba.com> wrote:
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. 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.
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."
Hi,
On Jun 17, 2016, at 6:04 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
#alt_meta ? - Maps to alt on OSX, ctrl on Win/Linux. - Can only bind either #meta or #alt_meta + key, or both must bind to same action. - Can only be applied to a very limited set of keys, (usually those employed in navigation). (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later)
Thanks for the input! Indeed, using Alt for Mac for anything else than text is not so nice. However, on Mac we could use Ctrl. To this end, we could introduce a secondaryMeta that maps like this: - Mac: Ctrl - Win: Alt - Linux: Alt What do you think? Doru
Cheers, Henry
On 17 Jun 2016, at 2:35 , Tudor Girba <tudor@tudorgirba.com> wrote:
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. 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.
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 âLive like you mean it."
On Sat, Jun 18, 2016 at 12:20 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jun 17, 2016, at 6:04 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
#alt_meta ? - Maps to alt on OSX, ctrl on Win/Linux. - Can only bind either #meta or #alt_meta + key, or both must bind to same action. - Can only be applied to a very limited set of keys, (usually those employed in navigation). (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later)
Thanks for the input!
Indeed, using Alt for Mac for anything else than text is not so nice. However, on Mac we could use Ctrl. To this end, we could introduce a secondaryMeta that maps like this: - Mac: Ctrl - Win: Alt - Linux: Alt
What do you think?
I like this, to further minimise hard coding of alt, & ctrl. Yet there are probably a small number of shortcuts with cross platform conflicts where hardcoded values are still required, and for those it even be useful to hardcode AltException & CtrlException rather than Alt & Ctrl - to make this clear to anyone using the system code as an example - but maybe that would be taking it too far. cheers -
Doru
Cheers, Henry
On 17 Jun 2016, at 2:35 , Tudor Girba <tudor@tudorgirba.com> wrote:
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. 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.
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
âLive like you mean it."
On Sat, Jun 18, 2016 at 4:39 PM, Ben Coman <btc@openinworld.com> wrote:
Yet there are probably a small number of shortcuts with cross platform conflicts where hardcoded values are still required, and for those it even be useful to hardcode
I agree to that. For example I miss that normally in my computer (with Linux) I every program I can do Ctrl+Backspace to delete the word before the cursor, which in Pharo does not work, and I think it is related to mac keyboards not having two different keys for backspace/delete as it is common in other keyboards.
2016-06-18 20:19 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>:
On Sat, Jun 18, 2016 at 4:39 PM, Ben Coman <btc@openinworld.com> wrote:
Yet there are probably a small number of shortcuts with cross platform conflicts where hardcoded values are still required, and for those it even be useful to hardcode
I agree to that. For example I miss that normally in my computer (with Linux) I every program I can do Ctrl+Backspace to delete the word before the cursor, which in Pharo does not work, and I think it is related to mac keyboards not having two different keys for backspace/delete as it is common in other keyboards.
You can use shift+backspace for backword-delete-word. This works on windows and linux. Cleaning up the shortcut handling, would make it easy to change this to ctrl+backspace (there is already an issue about this, for windows, but this applies to linux as well: 13882 <https://pharo.fogbugz.com/f/cases/13882/Under-Windows-the-key-to-remove-a-wo...> Under Windows the key to remove a word is not SHIFT+Backspace but CTRL + Backspace)
On Jun 17, 2016, at 6:04 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
#alt_meta ? - Maps to alt on OSX, ctrl on Win/Linux. - Can only bind either #meta or #alt_meta + key, or both must bind to same action. - Can only be applied to a very limited set of keys, (usually those employed in navigation). (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later) Thanks for the input!
Indeed, using Alt for Mac for anything else than text is not so nice. However, on Mac we could use Ctrl. To this end, we could introduce a secondaryMeta that maps like this: - Mac: Ctrl - Win: Alt - Linux: Alt
What do you think?
Would be ok but why do we need secondary meta? Stef
Hi,
On Aug 7, 2016, at 9:16 PM, stepharo <stepharo@free.fr> wrote:
On Jun 17, 2016, at 6:04 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
#alt_meta ? - Maps to alt on OSX, ctrl on Win/Linux. - Can only bind either #meta or #alt_meta + key, or both must bind to same action. - Can only be applied to a very limited set of keys, (usually those employed in navigation). (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later) Thanks for the input!
Indeed, using Alt for Mac for anything else than text is not so nice. However, on Mac we could use Ctrl. To this end, we could introduce a secondaryMeta that maps like this: - Mac: Ctrl - Win: Alt - Linux: Alt
What do you think?
Would be ok but why do we need secondary meta?
Having only one platform-independent modifier would likely not be enough to handle all key combinations we would want. I think that if we would have a second platform-independent modifier would not hurt. Cheers, Doru
Stef
-- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."
Le 7/8/16 à 21:27, Tudor Girba a écrit :
Hi,
On Aug 7, 2016, at 9:16 PM, stepharo <stepharo@free.fr> wrote:
On Jun 17, 2016, at 6:04 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
#alt_meta ? - Maps to alt on OSX, ctrl on Win/Linux. - Can only bind either #meta or #alt_meta + key, or both must bind to same action. - Can only be applied to a very limited set of keys, (usually those employed in navigation). (here are *alot* of different keyboard layouts on Mac using alt + key to generate crucial characters, allowing alt + key as shortcut in general is bound to end in disaster sooner or later) Thanks for the input!
Indeed, using Alt for Mac for anything else than text is not so nice. However, on Mac we could use Ctrl. To this end, we could introduce a secondaryMeta that maps like this: - Mac: Ctrl - Win: Alt - Linux: Alt
What do you think? Would be ok but why do we need secondary meta? Having only one platform-independent modifier would likely not be enough to handle all key combinations we would want. I think that if we would have a second platform-independent modifier would not hurt.
ok I see.
Cheers, Doru
Stef
-- www.tudorgirba.com www.feenk.com
"Obvious things are difficult to teach."
Le 16/6/16 à 22:45, Tudor Girba a écrit :
Hi,
I think we are mixing the topics a bit. The #meta discussion is not specific to Spotter actions.
The idea was to offer a uniform support of keybindings in Pharo, in general. Then Guille etal added #meta to have a predictable mapping. 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.
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?
It would be good. I would really like to have an agreement on nautilus and non nautilus - implementors - senders - references Now this is not easy. In addition, having on implementors falling back on class browse and the inverse too is really nice to have like that we do not have to think "ok this piece of text represent a class so that I should browse)" or "this piece of text is a method so I have to ask implementor (browse should bring implementor) we could also get back on binding. We could do the same for senders/references (that are the same concept). I already fixed that and it was lost two times. Stef
participants (11)
-
Andrei Chis -
Ben Coman -
Esteban Lorenzano -
Guille Polito -
Henrik Johansen -
Henrik Nergaard -
Henrik Sperre Johansen
-
Nicolai Hess -
Nicolas Passerini -
stepharo -
Tudor Girba