GT-Spotter dive in shortcut

On Sat, Jun 18, 2016 at 4:39 PM, Ben Coman <[hidden email]> 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.

Hi Nicolai,

> On Jun 17, 2016, at 2:59 PM, Nicolai Hess <[hidden email]> wrote:
>
>
>
> 2016-06-17 14:35 GMT+02:00 Tudor Girba <[hidden email]>:
> 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 <[hidden email]> wrote:
> >
> >
> >
> > 2016-06-16 22:45 GMT+02:00 Tudor Girba <[hidden email]>:
> > 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 <[hidden email]> wrote:
> > >
> > >
> > >
> > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <[hidden email]>:
> > > 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 <[hidden email]> wrote:
> > >
> > >
> > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <[hidden email]>:
> > > 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 <[hidden email]> wrote:
> > >
> > >
> > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <[hidden email]>:
> > >
> > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <[hidden email]>:
> > > >
> > > > 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:[hidden email]] On Behalf Of Nicolai Hess
> > > > Sent: Tuesday, June 7, 2016 12:56 PM
> > > > To: Pharo Development List <[hidden email]>
> > > > 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 <[hidden email]> wrote:
>
>
>
> 2016-06-17 18:25 GMT+02:00 Tudor Girba <[hidden email]>:
> Hi Nicolai,
>
> > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <[hidden email]> wrote:
> >
> >
> >
> > 2016-06-17 14:35 GMT+02:00 Tudor Girba <[hidden email]>:
> > 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 <[hidden email]> wrote:
> > >
> > >
> > >
> > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <[hidden email]>:
> > > 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 <[hidden email]> wrote:
> > > >
> > > >
> > > >
> > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > 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 <[hidden email]> wrote:
> > > >
> > > >
> > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > 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 <[hidden email]> wrote:
> > > >
> > > >
> > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <[hidden email]>:
> > > >
> > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <[hidden email]>:
> > > > >
> > > > > 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:[hidden email]] On Behalf Of Nicolai Hess
> > > > > Sent: Tuesday, June 7, 2016 12:56 PM
> > > > > To: Pharo Development List <[hidden email]>
> > > > > 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 <[hidden email]>:

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 <[hidden email]> wrote:
>
>
>
> 2016-06-17 18:25 GMT+02:00 Tudor Girba <[hidden email]>:
> Hi Nicolai,
>
> > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <[hidden email]> wrote:
> >
> >
> >
> > 2016-06-17 14:35 GMT+02:00 Tudor Girba <[hidden email]>:
> > 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 <[hidden email]> wrote:
> > >
> > >
> > >
> > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <[hidden email]>:
> > > 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 <[hidden email]> wrote:
> > > >
> > > >
> > > >
> > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > 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 <[hidden email]> wrote:
> > > >
> > > >
> > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > 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 <[hidden email]> wrote:
> > > >
> > > >
> > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <[hidden email]>:
> > > >
> > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <[hidden email]>:
> > > > >
> > > > > 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:[hidden email]] On Behalf Of Nicolai Hess
> > > > > Sent: Tuesday, June 7, 2016 12:56 PM
> > > > > To: Pharo Development List <[hidden email]>
> > > > > 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 <[hidden email]> wrote:
>
>
>
> 2016-06-18 23:34 GMT+02:00 Nicolai Hess <[hidden email]>:
>
>
> 2016-06-18 20:55 GMT+02:00 Tudor Girba <[hidden email]>:
> 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 <[hidden email]> wrote:
> >
> >
> >
> > 2016-06-17 18:25 GMT+02:00 Tudor Girba <[hidden email]>:
> > Hi Nicolai,
> >
> > > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <[hidden email]> wrote:
> > >
> > >
> > >
> > > 2016-06-17 14:35 GMT+02:00 Tudor Girba <[hidden email]>:
> > > 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 <[hidden email]> wrote:
> > > >
> > > >
> > > >
> > > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > 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 <[hidden email]> wrote:
> > > > >
> > > > >
> > > > >
> > > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > > 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 <[hidden email]> wrote:
> > > > >
> > > > >
> > > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > > 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 <[hidden email]> wrote:
> > > > >
> > > > >
> > > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <[hidden email]>:
> > > > >
> > > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <[hidden email]>:
> > > > > >
> > > > > > 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:[hidden email]] On Behalf Of Nicolai Hess
> > > > > > Sent: Tuesday, June 7, 2016 12:56 PM
> > > > > > To: Pharo Development List <[hidden email]>
> > > > > > 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 <[hidden email]> wrote:
>
>
>
> 2016-08-03 10:02 GMT+02:00 Tudor Girba <[hidden email]>:
> Hi,
>
> > On Aug 3, 2016, at 9:16 AM, Nicolai Hess <[hidden email]> wrote:
> >
> >
> >
> > 2016-06-18 23:34 GMT+02:00 Nicolai Hess <[hidden email]>:
> >
> >
> > 2016-06-18 20:55 GMT+02:00 Tudor Girba <[hidden email]>:
> > 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 <[hidden email]> wrote:
> > >
> > >
> > >
> > > 2016-06-17 18:25 GMT+02:00 Tudor Girba <[hidden email]>:
> > > Hi Nicolai,
> > >
> > > > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <[hidden email]> wrote:
> > > >
> > > >
> > > >
> > > > 2016-06-17 14:35 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > 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 <[hidden email]> wrote:
> > > > >
> > > > >
> > > > >
> > > > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > > 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 <[hidden email]> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > > > 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 <[hidden email]> wrote:
> > > > > >
> > > > > >
> > > > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > > > 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 <[hidden email]> wrote:
> > > > > >
> > > > > >
> > > > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <[hidden email]>:
> > > > > >
> > > > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <[hidden email]>:
> > > > > > >
> > > > > > > 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:[hidden email]] On Behalf Of Nicolai Hess
> > > > > > > Sent: Tuesday, June 7, 2016 12:56 PM
> > > > > > > To: Pharo Development List <[hidden email]>
> > > > > > > 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 <[hidden email]> wrote:
>
>
>
> 2016-08-07 15:23 GMT+02:00 Tudor Girba <[hidden email]>:
> Hi,
>
>
> > On Aug 3, 2016, at 11:16 AM, Nicolai Hess <[hidden email]> wrote:
> >
> >
> >
> > 2016-08-03 10:02 GMT+02:00 Tudor Girba <[hidden email]>:
> > Hi,
> >
> > > On Aug 3, 2016, at 9:16 AM, Nicolai Hess <[hidden email]> wrote:
> > >
> > >
> > >
> > > 2016-06-18 23:34 GMT+02:00 Nicolai Hess <[hidden email]>:
> > >
> > >
> > > 2016-06-18 20:55 GMT+02:00 Tudor Girba <[hidden email]>:
> > > 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 <[hidden email]> wrote:
> > > >
> > > >
> > > >
> > > > 2016-06-17 18:25 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > Hi Nicolai,
> > > >
> > > > > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <[hidden email]> wrote:
> > > > >
> > > > >
> > > > >
> > > > > 2016-06-17 14:35 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > > 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 <[hidden email]> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > > > 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 <[hidden email]> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > > > > 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 <[hidden email]> wrote:
> > > > > > >
> > > > > > >
> > > > > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > > > > 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 <[hidden email]> wrote:
> > > > > > >
> > > > > > >
> > > > > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <[hidden email]>:
> > > > > > >
> > > > > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <[hidden email]>:
> > > > > > > >
> > > > > > > > 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:[hidden email]] On Behalf Of Nicolai Hess
> > > > > > > > Sent: Tuesday, June 7, 2016 12:56 PM
> > > > > > > > To: Pharo Development List <[hidden email]>
> > > > > > > > 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 <[hidden email]> wrote:
>
>
>
> 2016-08-07 16:23 GMT+02:00 Tudor Girba <[hidden email]>:
> Hi,
>
> > On Aug 7, 2016, at 4:13 PM, Nicolai Hess <[hidden email]> wrote:
> >
> >
> >
> > 2016-08-07 15:23 GMT+02:00 Tudor Girba <[hidden email]>:
> > Hi,
> >
> >
> > > On Aug 3, 2016, at 11:16 AM, Nicolai Hess <[hidden email]> wrote:
> > >
> > >
> > >
> > > 2016-08-03 10:02 GMT+02:00 Tudor Girba <[hidden email]>:
> > > Hi,
> > >
> > > > On Aug 3, 2016, at 9:16 AM, Nicolai Hess <[hidden email]> wrote:
> > > >
> > > >
> > > >
> > > > 2016-06-18 23:34 GMT+02:00 Nicolai Hess <[hidden email]>:
> > > >
> > > >
> > > > 2016-06-18 20:55 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > 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 <[hidden email]> wrote:
> > > > >
> > > > >
> > > > >
> > > > > 2016-06-17 18:25 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > > Hi Nicolai,
> > > > >
> > > > > > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <[hidden email]> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2016-06-17 14:35 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > > > 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 <[hidden email]> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <[hidden email]>:
> > > > > > > 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 <[hidden email]> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > > > > > 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 <[hidden email]> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <[hidden email]>:
> > > > > > > > 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 <[hidden email]> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <[hidden email]>:
> > > > > > > >
> > > > > > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" <[hidden email]>:
> > > > > > > > >
> > > > > > > > > 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:[hidden email]] On Behalf Of Nicolai Hess
> > > > > > > > > Sent: Tuesday, June 7, 2016 12:56 PM
> > > > > > > > > To: Pharo Development List <[hidden email]>
> > > > > > > > > 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."