June 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Nicolai Hess

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

June 18, 2016

Re: [Pharo-dev] Better #haltOnce: per haltOnce state, auto-enable

by Eliot Miranda

On Sat, Jun 18, 2016 at 12:17 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 18 Jun 2016, at 06:55, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 18 Jun 2016, at 05:29, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Marcus, > > >> Marcus >> > > Yes, but using the byte code pc is a much much cheaper key, and just as > unique. > > > But why would I care to make this efficient? Itâs a debug featureâ¦ > > And doing it on the AST is very nice for other reasons, e.g. as I next > step I will > add icons in the Editor for all the halt sends. For haltOnce, this will > show the state > and toggle the haltOnce to be âonâ again. > > > So, first version (to be improved)â¦ could this be implemented in term of > byte code offset. Of course. > Would it be nice? I doubt. > Alas, poor Occam. I knew him well. > > -- _,,,^..^,,,_ best, Eliot

June 18, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Henrik Sperre Johansen

Nicolai Hess-3-2 wrote > 2016-06-17 18:25 GMT+02:00 Tudor Girba < > tudor@ > >: > >> So, we would need a logical modifier that would mean: >> - Mac: Alt >> - Win: Ctrl >> - Linux: Ctrl >> > > I though this is what Guillermo already did, but with "command" > > - Mac: Command > - Win/Linux: Ctrl > > Why did we choose Command and not Alt in the first place, why is Alt now > better? Not better, just different. In the general case, shortcuts with ctrl use cmd on Mac (like ctrl-c, ctrl-v, etc), but some navigation shortcuts (like previous / next word) use alt on osx where windows use ctrl. So having both meta and alt-meta bindings as I described, lets you represent both, but, due to the nature of alt, some care/restrictions would need to be applied to alt-meta that are not necessary for meta. -- View this message in context: http://forum.world.st/GT-Spotter-dive-in-shortcut-tp4899612p4901704.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 18, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Tudor Girba

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

June 18, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Nicolai Hess

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

June 18, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Nicolai Hess

2016-06-18 20:19 GMT+02:00 Nicolas Passerini <npasserini(a)gmail.com>: > > On Sat, Jun 18, 2016 at 4:39 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> Yet >> there are probably a small number of shortcuts with cross platform >> conflicts where hardcoded values are still required, and for those it >> even be useful to hardcode >> > > I agree to that. For example I miss that normally in my computer (with > Linux) I every program I can do Ctrl+Backspace to delete the word before > the cursor, which in Pharo does not work, and I think it is related to mac > keyboards not having two different keys for backspace/delete as it is > common in other keyboards. > You can use shift+backspace for backword-delete-word. This works on windows and linux. Cleaning up the shortcut handling, would make it easy to change this to ctrl+backspace (there is already an issue about this, for windows, but this applies to linux as well: 13882 <https://pharo.fogbugz.com/f/cases/13882/Under-Windows-the-key-to-remove-a-w…> Under Windows the key to remove a word is not SHIFT+Backspace but CTRL + Backspace)

June 18, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Nicolas Passerini

On Sat, Jun 18, 2016 at 4:39 PM, Ben Coman <btc(a)openinworld.com> wrote: > Yet > there are probably a small number of shortcuts with cross platform > conflicts where hardcoded values are still required, and for those it > even be useful to hardcode > I agree to that. For example I miss that normally in my computer (with Linux) I every program I can do Ctrl+Backspace to delete the word before the cursor, which in Pharo does not work, and I think it is related to mac keyboards not having two different keys for backspace/delete as it is common in other keyboards.

June 18, 2016

Re: [Pharo-dev] PharoLauncher Hanging

by serge.stinckwich＠gmail.com

I have same behavior from time to time. Sent from my iPhone > On 18 juin 2016, at 14:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I just had Launcher hang (Mac's spinning beach ball of death) twice in a row > after launching a 5.0 image with "quit on launch" disabled. > > Let me know if you need any other information. > > OS X 10.10.5 > Image > ----- > Pharo5.0 > Latest update: #50760 > > Virtual Machine > --------------- > /Applications/Pharo.app/Contents/MacOS/Pharo > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > https://github.com/pharo-project/pharo-vm.git Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > > Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< > VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: > b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: > Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > CoInterpreter VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > StackToRegisterMappingCogit VMMaker.oscog-eem.1855 uuid: > d8e4a3c2-a3bf-4adc-b224-8012903a1ef4 May 4 2016 > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/PharoLauncher-Hanging-tp4901674.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 18, 2016

Re: [Pharo-dev] Error While Browsing

by Yuriy Tymchuk

Good to know. This shouldnât happen in the latest pharo 6, I will also back port the solution to pharo 5 > On 18 Jun 2016, at 18:06, Max Leske <maxleske(a)gmail.com> wrote: > > Thatâs about critiques (ccâing Yuriy). > > >> On 18 Jun 2016, at 15:25, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> This happened when I scrolled to the selected menu in Nautilus... >> >> <http://forum.world.st/file/n4901675/Screenshot_2016-06-18_10.png> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Error-While-Browsing-tp4901675.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

June 18, 2016

AthensCairoSurface not getting garbage collected

by J.F. Rick

I'm using Athens rendering for my multi-touch applications on Pharo5. As part of that, I create a surface: surface := AthensCairoSurface extent: bounds extent asIntegerPoint. Though the object creating that surface is deleted, the surface sticks around. So, each time I run the app, I get another instance of AthensCairoSurface hanging around. That means all the forms stick around as well. So my image can quickly grow towards the 1GB size. Is there anything I can do about that? Can I manually get the surface to delete itself? Cheers, Jeff

June 18, 2016