2016-06-17 14:35 GMT+02:00 Tudor Girba <[email protected]>:

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

Reply via email to