On Sun, Jun 19, 2016 at 2:55 AM, Tudor Girba <tu...@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 <nicolaih...@gmail.com> wrote: >> >> 2016-06-17 18:25 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>: >> >> > On Jun 17, 2016, at 2:59 PM, Nicolai Hess <nicolaih...@gmail.com> wrote: >> > >> > 2016-06-17 14:35 GMT+02:00 Tudor Girba <tu...@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 <nicolaih...@gmail.com> wrote: >> > > >> > > 2016-06-16 22:45 GMT+02:00 Tudor Girba <tu...@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 <nicolaih...@gmail.com> >> > > > wrote: >> > > > >> > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileand...@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 <nicolaih...@gmail.com> >> > > > wrote: >> > > > >> > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileand...@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 <nicolaih...@gmail.com> >> > > > wrote: >> > > > >> > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>: >> > > > >> > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" >> > > > <henrik.nerga...@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.
