The Trunk: Morphic-cmm.409.mcz
Locked
 
|
Chris Muller uploaded a new version of Morphic to project The Trunk:
http://source.squeak.org/trunk/Morphic-cmm.409.mcz ==================== Summary ==================== Name: Morphic-cmm.409 Author: cmm Time: 4 April 2010, 7:38:12.513 pm UUID: fccf6217-a81a-4ebc-94be-ec0e36a05b7a Ancestors: Morphic-ar.408 Changed hot-key for search-bar activation to Control+7 instead of Control+7, 8, or 9. Control+9 was already taken for a very useful, legacy function (surround with parenthesis). This is also consistent with the other hot-keys on the DockingBar since the search-bar is the 7th item over, not the 9th. There are a limited number of shortcut keys still available on the keyboard, so no function deserves three separate hot-keys. =============== Diff against Morphic-ar.408 =============== Item was changed: ----- Method: DockingBarMorph>>handleListenEvent: (in category 'events-processing') ----- handleListenEvent: anEvent " I am registered as a keyboardListener of the ActiveHand, watching for ctrl-<n> keystrokes, and upon them if I have an nth menu item, I'll activate myself and select it. " (anEvent controlKeyPressed and: [ anEvent keyValue between: 48 " $0 asciiValue " + and: 55 " $7 asciiValue " ]) ifTrue: [ - and: 57 " $9 asciiValue " ]) ifTrue: [ | index itemToSelect | index := anEvent keyValue - 48. itemToSelect := (submorphs select: [ :each | each isKindOf: DockingBarItemMorph ]) at: index ifAbsent: [ ^self searchBarMorph ifNotNil: [ :searchBar | searchBar activate: anEvent ] ]. self activate: anEvent. self selectItem: itemToSelect event: anEvent ]! |
Re: The Trunk: Morphic-cmm.409.mcz
|
|
On Mon, 5 Apr 2010, [hidden email] wrote:
> Chris Muller uploaded a new version of Morphic to project The Trunk: > http://source.squeak.org/trunk/Morphic-cmm.409.mcz > > ==================== Summary ==================== > > Name: Morphic-cmm.409 > Author: cmm > Time: 4 April 2010, 7:38:12.513 pm > UUID: fccf6217-a81a-4ebc-94be-ec0e36a05b7a > Ancestors: Morphic-ar.408 > > Changed hot-key for search-bar activation to Control+7 instead of Control+7, 8, or 9. Control+9 was already taken for a very useful, legacy function (surround with parenthesis). This is also consistent with the other hot-keys on the DockingBar since the search-bar is the 7th item over, not the 9th. There are a limited number of shortcut keys still available on the keyboard, so no function deserves three separate hot-keys. The intention was Ctrl+0, but we decided to add it to 7-8-9 too, because some keyboard layouts don't have 0 without other modifiers. Ctrl+9 was unused, Ctrl+( (which is Ctrl+Shift+9) is used for surrounding with (). There's no guarantee that the Search Bar will be always the 7th item in the docking bar, therefore 0 is a better choice IMHO, since 0 is usuall on the right side of the keyboard, just like the Search Bar is on the right side of the screen (if the docking bar is up or down). Levente > > =============== Diff against Morphic-ar.408 =============== > > Item was changed: > ----- Method: DockingBarMorph>>handleListenEvent: (in category 'events-processing') ----- > handleListenEvent: anEvent > " I am registered as a keyboardListener of the ActiveHand, > watching for ctrl-<n> keystrokes, and upon them if I have > an nth menu item, I'll activate myself and select it. " > > (anEvent controlKeyPressed and: [ > anEvent keyValue > between: 48 " $0 asciiValue " > + and: 55 " $7 asciiValue " ]) ifTrue: [ > - and: 57 " $9 asciiValue " ]) ifTrue: [ > | index itemToSelect | > index := anEvent keyValue - 48. > itemToSelect := (submorphs select: [ :each | > each isKindOf: DockingBarItemMorph ]) > at: index > ifAbsent: [ > ^self searchBarMorph ifNotNil: [ :searchBar | > searchBar activate: anEvent ] ]. > self activate: anEvent. > self > selectItem: itemToSelect > event: anEvent ]! > > > |
Re: The Trunk: Morphic-cmm.409.mcz
|
|
> The intention was Ctrl+0, but we decided to add it to 7-8-9 too, because
> some keyboard layouts don't have 0 without other modifiers. We cannot be wasting so many keys. Other applications want to be written in Squeak that make use of hot-keys, and so we don't want 7, 8, 9, and 0 to be all used up by one function. Under the "keyboard" category of Preferences, there are various settings; duplicateAllControlAndAltKeys, etc. These ideas do not make the situation any easier to understand, and ended up consuming tons of extra keys just because there was this idea years ago that we need to cater to newbies demanding to use Control key for cut and paste. So now we have to support this shit, "dup all Alt and Control keys" and, unfortuntaely, Squeak is still does not look-and-feel enough like MS-Excel for the newbies to be happy... Sorry, I was off on rant there.. > Ctrl+9 was unused, Ctrl+( (which is Ctrl+Shift+9) is used for surrounding > with (). That wasn't working, and it is *very* important to me. I use it many times per day. Also, Control+9 is consistent with the other "shifted" enclosers, which do not require a Shift+Control modifier.. > There's no guarantee that the Search Bar will be always the 7th item in the > docking bar, Sure there is. Have a look at TheWorldMainDockingBar>>#menusOn:. Each of the menus is hard-coded, along with the search-bar. There is no variance, therefore, currently, the search bar will always be the 7th item. You might be saying, "There's no guarantee *in the future*, that the Search Bar will be always the 7th item in the docking bar..." and, if so, I argue that there is no guarantee that "Projects" menu will always be Control+2, or that "Tools" will be Control+3. I doubt we will be adding many more menus in the future, but we have to accept, when using these numerical / positional hot-keys that they *might* change in the future. > therefore 0 is a better choice IMHO, since 0 is usuall on the > right side of the keyboard, just like the Search Bar is on the right side of > the screen (if the docking bar is up or down). What about left or right? :) To me, positional consistency valuable, but less important than the parenthetical enclosing. If you can find a way to have it be Control+0 without breaking Control+9 for parenthetical enclosure, I would support that (but I still think Control+7 is more consistent). - Chris >> =============== Diff against Morphic-ar.408 =============== >> >> Item was changed: >> ----- Method: DockingBarMorph>>handleListenEvent: (in category >> 'events-processing') ----- >> handleListenEvent: anEvent >> " I am registered as a keyboardListener of the ActiveHand, >> watching for ctrl-<n> keystrokes, and upon them if I have >> an nth menu item, I'll activate myself and select it. " >> >> (anEvent controlKeyPressed and: [ >> anEvent keyValue >> between: 48 " $0 asciiValue " >> + and: 55 " $7 asciiValue " ]) ifTrue: [ >> - and: 57 " $9 asciiValue " ]) ifTrue: [ >> | index itemToSelect | >> index := anEvent keyValue - 48. >> itemToSelect := (submorphs select: [ :each | >> each isKindOf: DockingBarItemMorph ]) >> at: index >> ifAbsent: [ >> ^self searchBarMorph ifNotNil: [ >> :searchBar | >> searchBar activate: anEvent >> ] ]. >> self activate: anEvent. >> self >> selectItem: itemToSelect >> event: anEvent ]! >> >> >> > > |
Re: The Trunk: Morphic-cmm.409.mcz
|
|
On Mon, 5 Apr 2010, Chris Muller wrote:
>> The intention was Ctrl+0, but we decided to add it to 7-8-9 too, because >> some keyboard layouts don't have 0 without other modifiers. > > We cannot be wasting so many keys. Other applications want to be > written in Squeak that make use of hot-keys, and so we don't want 7, > 8, 9, and 0 to be all used up by one function. It's still 7 and 0. > > Under the "keyboard" category of Preferences, there are various > settings; duplicateAllControlAndAltKeys, etc. These ideas do not make > the situation any easier to understand, and ended up consuming tons of > extra keys just because there was this idea years ago that we need to > cater to newbies demanding to use Control key for cut and paste. So > now we have to support this shit, "dup all Alt and Control keys" and, > unfortuntaely, Squeak is still does not look-and-feel enough like > MS-Excel for the newbies to be happy... > > Sorry, I was off on rant there.. > >> Ctrl+9 was unused, Ctrl+( (which is Ctrl+Shift+9) is used for surrounding >> with (). > > That wasn't working, and it is *very* important to me. I use it many > times per day. Also, Control+9 is consistent with the other "shifted" > enclosers, which do not require a Shift+Control modifier.. > >> There's no guarantee that the Search Bar will be always the 7th item in the >> docking bar, > > Sure there is. Have a look at TheWorldMainDockingBar>>#menusOn:. > Each of the menus is hard-coded, along with the search-bar. There is > no variance, therefore, currently, the search bar will always be the > 7th item. > > You might be saying, "There's no guarantee *in the future*, that the > Search Bar will be always the 7th item in the docking bar..." and, if > so, I argue that there is no guarantee that "Projects" menu will > always be Control+2, or that "Tools" will be Control+3. I doubt we > will be adding many more menus in the future, but we have to accept, > when using these numerical / positional hot-keys that they *might* > change in the future. > >> therefore 0 is a better choice IMHO, since 0 is usuall on the >> right side of the keyboard, just like the Search Bar is on the right side of >> the screen (if the docking bar is up or down). > > What about left or right? :) it, that's why I noted that it only works is the bar is up or down. Also the docking bar menus don't work as expected if the docking bar is positioned down. > > To me, positional consistency valuable, but less important than the > parenthetical enclosing. If you can find a way to have it be > Control+0 without breaking Control+9 for parenthetical enclosure, I If Ctrl+9 prints () for you, then it's a bug IMHO. Levente > would support that (but I still think Control+7 is more consistent). > > - Chris > > >>> =============== Diff against Morphic-ar.408 =============== >>> >>> Item was changed: >>> ----- Method: DockingBarMorph>>handleListenEvent: (in category >>> 'events-processing') ----- >>> handleListenEvent: anEvent >>> " I am registered as a keyboardListener of the ActiveHand, >>> watching for ctrl-<n> keystrokes, and upon them if I have >>> an nth menu item, I'll activate myself and select it. " >>> >>> (anEvent controlKeyPressed and: [ >>> anEvent keyValue >>> between: 48 " $0 asciiValue " >>> + and: 55 " $7 asciiValue " ]) ifTrue: [ >>> - and: 57 " $9 asciiValue " ]) ifTrue: [ >>> | index itemToSelect | >>> index := anEvent keyValue - 48. >>> itemToSelect := (submorphs select: [ :each | >>> each isKindOf: DockingBarItemMorph ]) >>> at: index >>> ifAbsent: [ >>> ^self searchBarMorph ifNotNil: [ >>> :searchBar | >>> searchBar activate: anEvent >>> ] ]. >>> self activate: anEvent. >>> self >>> selectItem: itemToSelect >>> event: anEvent ]! >>> >>> >>> >> >> > > |
Re: The Trunk: Morphic-cmm.409.mcz
|
|
In reply to this post by Chris Muller-3
2010/4/5 Chris Muller <[hidden email]>:
>> The intention was Ctrl+0, but we decided to add it to 7-8-9 too, because >> some keyboard layouts don't have 0 without other modifiers. > > We cannot be wasting so many keys. Other applications want to be > written in Squeak that make use of hot-keys, and so we don't want 7, > 8, 9, and 0 to be all used up by one function. > > Under the "keyboard" category of Preferences, there are various > settings; duplicateAllControlAndAltKeys, etc. These ideas do not make > the situation any easier to understand, and ended up consuming tons of > extra keys just because there was this idea years ago that we need to > cater to newbies demanding to use Control key for cut and paste. So > now we have to support this shit, "dup all Alt and Control keys" and, > unfortuntaely, Squeak is still does not look-and-feel enough like > MS-Excel for the newbies to be happy... > > Sorry, I was off on rant there.. > Hi Chris, You certainly are on a Mac, so you like your cmd+c because it's uniform thru all apps. It simply respects platforms feels. Switching between ctrl+c and alt+c on other platforms is a pain, not only for newbies. I would say this is a REALLY usefull feature. Of course it's not enough... >> Ctrl+9 was unused, Ctrl+( (which is Ctrl+Shift+9) is used for surrounding >> with (). > > That wasn't working, and it is *very* important to me. I use it many > times per day. Also, Control+9 is consistent with the other "shifted" > enclosers, which do not require a Shift+Control modifier.. > >> There's no guarantee that the Search Bar will be always the 7th item in the >> docking bar, > > Sure there is. Have a look at TheWorldMainDockingBar>>#menusOn:. > Each of the menus is hard-coded, along with the search-bar. There is > no variance, therefore, currently, the search bar will always be the > 7th item. > > You might be saying, "There's no guarantee *in the future*, that the > Search Bar will be always the 7th item in the docking bar..." and, if > so, I argue that there is no guarantee that "Projects" menu will > always be Control+2, or that "Tools" will be Control+3. I doubt we > will be adding many more menus in the future, but we have to accept, > when using these numerical / positional hot-keys that they *might* > change in the future. > >> therefore 0 is a better choice IMHO, since 0 is usuall on the >> right side of the keyboard, just like the Search Bar is on the right side of >> the screen (if the docking bar is up or down). > > What about left or right? :) > > To me, positional consistency valuable, but less important than the > parenthetical enclosing. If you can find a way to have it be > Control+0 without breaking Control+9 for parenthetical enclosure, I > would support that (but I still think Control+7 is more consistent). > > - Chris > > >>> =============== Diff against Morphic-ar.408 =============== >>> >>> Item was changed: >>> ----- Method: DockingBarMorph>>handleListenEvent: (in category >>> 'events-processing') ----- >>> handleListenEvent: anEvent >>> " I am registered as a keyboardListener of the ActiveHand, >>> watching for ctrl-<n> keystrokes, and upon them if I have >>> an nth menu item, I'll activate myself and select it. " >>> >>> (anEvent controlKeyPressed and: [ >>> anEvent keyValue >>> between: 48 " $0 asciiValue " >>> + and: 55 " $7 asciiValue " ]) ifTrue: [ >>> - and: 57 " $9 asciiValue " ]) ifTrue: [ >>> | index itemToSelect | >>> index := anEvent keyValue - 48. >>> itemToSelect := (submorphs select: [ :each | >>> each isKindOf: DockingBarItemMorph ]) >>> at: index >>> ifAbsent: [ >>> ^self searchBarMorph ifNotNil: [ >>> :searchBar | >>> searchBar activate: anEvent >>> ] ]. >>> self activate: anEvent. >>> self >>> selectItem: itemToSelect >>> event: anEvent ]! >>> >>> >>> >> >> > > |
Re: The Trunk: Morphic-cmm.409.mcz
|
|
What we need us an easy way to configure key bindings. The "duplicate" option makes control and alt mean the same thing, and reduces the total number of keyboard shortcuts available (Chris, this is more or less your point right?)
The problem of which keys to use as command/alt and control is I think orthogonal. There's a pref for swapping them, so it's not hard to get the main cut copy paste stuff right for your platform.
On Mon, Apr 5, 2010 at 1:45 PM, Nicolas Cellier <[hidden email]> wrote: 2010/4/5 Chris Muller <[hidden email]>: |
Re: The Trunk: Morphic-cmm.409.mcz
|
|
In reply to this post by Nicolas Cellier
I've never used a Mac in my life, not even once to play around with.
These days, I'm 99% Linux, 1% Windows (just for SOB meetings). Keys between different apps are generally pretty different (e.g., inconsistent). C&P is so bad on Linux that it is almost always a cerebral action anyway (vs. cerebellum). Now, for Windows, I can appreciate your argument the most, because C&P is very consistent there. So that must be the platform *you* are running on.. :) On Mon, Apr 5, 2010 at 3:45 PM, Nicolas Cellier <[hidden email]> wrote: > 2010/4/5 Chris Muller <[hidden email]>: >>> The intention was Ctrl+0, but we decided to add it to 7-8-9 too, because >>> some keyboard layouts don't have 0 without other modifiers. >> >> We cannot be wasting so many keys. Other applications want to be >> written in Squeak that make use of hot-keys, and so we don't want 7, >> 8, 9, and 0 to be all used up by one function. >> >> Under the "keyboard" category of Preferences, there are various >> settings; duplicateAllControlAndAltKeys, etc. These ideas do not make >> the situation any easier to understand, and ended up consuming tons of >> extra keys just because there was this idea years ago that we need to >> cater to newbies demanding to use Control key for cut and paste. So >> now we have to support this shit, "dup all Alt and Control keys" and, >> unfortuntaely, Squeak is still does not look-and-feel enough like >> MS-Excel for the newbies to be happy... >> >> Sorry, I was off on rant there.. >> > > Hi Chris, > You certainly are on a Mac, so you like your cmd+c because it's > uniform thru all apps. > It simply respects platforms feels. > Switching between ctrl+c and alt+c on other platforms is a pain, not > only for newbies. > I would say this is a REALLY usefull feature. > Of course it's not enough... > >>> Ctrl+9 was unused, Ctrl+( (which is Ctrl+Shift+9) is used for surrounding >>> with (). >> >> That wasn't working, and it is *very* important to me. I use it many >> times per day. Also, Control+9 is consistent with the other "shifted" >> enclosers, which do not require a Shift+Control modifier.. >> >>> There's no guarantee that the Search Bar will be always the 7th item in the >>> docking bar, >> >> Sure there is. Have a look at TheWorldMainDockingBar>>#menusOn:. >> Each of the menus is hard-coded, along with the search-bar. There is >> no variance, therefore, currently, the search bar will always be the >> 7th item. >> >> You might be saying, "There's no guarantee *in the future*, that the >> Search Bar will be always the 7th item in the docking bar..." and, if >> so, I argue that there is no guarantee that "Projects" menu will >> always be Control+2, or that "Tools" will be Control+3. I doubt we >> will be adding many more menus in the future, but we have to accept, >> when using these numerical / positional hot-keys that they *might* >> change in the future. >> >>> therefore 0 is a better choice IMHO, since 0 is usuall on the >>> right side of the keyboard, just like the Search Bar is on the right side of >>> the screen (if the docking bar is up or down). >> >> What about left or right? :) >> >> To me, positional consistency valuable, but less important than the >> parenthetical enclosing. If you can find a way to have it be >> Control+0 without breaking Control+9 for parenthetical enclosure, I >> would support that (but I still think Control+7 is more consistent). >> >> - Chris >> >> >>>> =============== Diff against Morphic-ar.408 =============== >>>> >>>> Item was changed: >>>> ----- Method: DockingBarMorph>>handleListenEvent: (in category >>>> 'events-processing') ----- >>>> handleListenEvent: anEvent >>>> " I am registered as a keyboardListener of the ActiveHand, >>>> watching for ctrl-<n> keystrokes, and upon them if I have >>>> an nth menu item, I'll activate myself and select it. " >>>> >>>> (anEvent controlKeyPressed and: [ >>>> anEvent keyValue >>>> between: 48 " $0 asciiValue " >>>> + and: 55 " $7 asciiValue " ]) ifTrue: [ >>>> - and: 57 " $9 asciiValue " ]) ifTrue: [ >>>> | index itemToSelect | >>>> index := anEvent keyValue - 48. >>>> itemToSelect := (submorphs select: [ :each | >>>> each isKindOf: DockingBarItemMorph ]) >>>> at: index >>>> ifAbsent: [ >>>> ^self searchBarMorph ifNotNil: [ >>>> :searchBar | >>>> searchBar activate: anEvent >>>> ] ]. >>>> self activate: anEvent. >>>> self >>>> selectItem: itemToSelect >>>> event: anEvent ]! >>>> >>>> >>>> >>> >>> >> >> > > |
Re: The Trunk: Morphic-cmm.409.mcz
|
|
2010/4/7 Chris Muller <[hidden email]>:
> I've never used a Mac in my life, not even once to play around with. > These days, I'm 99% Linux, 1% Windows (just for SOB meetings). > > Keys between different apps are generally pretty different (e.g., > inconsistent). C&P is so bad on Linux that it is almost always a > cerebral action anyway (vs. cerebellum). > > Now, for Windows, I can appreciate your argument the most, because C&P > is very consistent there. So that must be the platform *you* are > running on.. :) > Well, given I'm currently 50% windows, 30% mac, 20% linux, "the" configuration i'm running on is quite an exercize for brain. But never mind, I'm getting older, I need some brain exercize ;) I perfectly understand why squeakers would prefer mac though. Nicolas > > On Mon, Apr 5, 2010 at 3:45 PM, Nicolas Cellier > <[hidden email]> wrote: >> 2010/4/5 Chris Muller <[hidden email]>: >>>> The intention was Ctrl+0, but we decided to add it to 7-8-9 too, because >>>> some keyboard layouts don't have 0 without other modifiers. >>> >>> We cannot be wasting so many keys. Other applications want to be >>> written in Squeak that make use of hot-keys, and so we don't want 7, >>> 8, 9, and 0 to be all used up by one function. >>> >>> Under the "keyboard" category of Preferences, there are various >>> settings; duplicateAllControlAndAltKeys, etc. These ideas do not make >>> the situation any easier to understand, and ended up consuming tons of >>> extra keys just because there was this idea years ago that we need to >>> cater to newbies demanding to use Control key for cut and paste. So >>> now we have to support this shit, "dup all Alt and Control keys" and, >>> unfortuntaely, Squeak is still does not look-and-feel enough like >>> MS-Excel for the newbies to be happy... >>> >>> Sorry, I was off on rant there.. >>> >> >> Hi Chris, >> You certainly are on a Mac, so you like your cmd+c because it's >> uniform thru all apps. >> It simply respects platforms feels. >> Switching between ctrl+c and alt+c on other platforms is a pain, not >> only for newbies. >> I would say this is a REALLY usefull feature. >> Of course it's not enough... >> >>>> Ctrl+9 was unused, Ctrl+( (which is Ctrl+Shift+9) is used for surrounding >>>> with (). >>> >>> That wasn't working, and it is *very* important to me. I use it many >>> times per day. Also, Control+9 is consistent with the other "shifted" >>> enclosers, which do not require a Shift+Control modifier.. >>> >>>> There's no guarantee that the Search Bar will be always the 7th item in the >>>> docking bar, >>> >>> Sure there is. Have a look at TheWorldMainDockingBar>>#menusOn:. >>> Each of the menus is hard-coded, along with the search-bar. There is >>> no variance, therefore, currently, the search bar will always be the >>> 7th item. >>> >>> You might be saying, "There's no guarantee *in the future*, that the >>> Search Bar will be always the 7th item in the docking bar..." and, if >>> so, I argue that there is no guarantee that "Projects" menu will >>> always be Control+2, or that "Tools" will be Control+3. I doubt we >>> will be adding many more menus in the future, but we have to accept, >>> when using these numerical / positional hot-keys that they *might* >>> change in the future. >>> >>>> therefore 0 is a better choice IMHO, since 0 is usuall on the >>>> right side of the keyboard, just like the Search Bar is on the right side of >>>> the screen (if the docking bar is up or down). >>> >>> What about left or right? :) >>> >>> To me, positional consistency valuable, but less important than the >>> parenthetical enclosing. If you can find a way to have it be >>> Control+0 without breaking Control+9 for parenthetical enclosure, I >>> would support that (but I still think Control+7 is more consistent). >>> >>> - Chris >>> >>> >>>>> =============== Diff against Morphic-ar.408 =============== >>>>> >>>>> Item was changed: >>>>> ----- Method: DockingBarMorph>>handleListenEvent: (in category >>>>> 'events-processing') ----- >>>>> handleListenEvent: anEvent >>>>> " I am registered as a keyboardListener of the ActiveHand, >>>>> watching for ctrl-<n> keystrokes, and upon them if I have >>>>> an nth menu item, I'll activate myself and select it. " >>>>> >>>>> (anEvent controlKeyPressed and: [ >>>>> anEvent keyValue >>>>> between: 48 " $0 asciiValue " >>>>> + and: 55 " $7 asciiValue " ]) ifTrue: [ >>>>> - and: 57 " $9 asciiValue " ]) ifTrue: [ >>>>> | index itemToSelect | >>>>> index := anEvent keyValue - 48. >>>>> itemToSelect := (submorphs select: [ :each | >>>>> each isKindOf: DockingBarItemMorph ]) >>>>> at: index >>>>> ifAbsent: [ >>>>> ^self searchBarMorph ifNotNil: [ >>>>> :searchBar | >>>>> searchBar activate: anEvent >>>>> ] ]. >>>>> self activate: anEvent. >>>>> self >>>>> selectItem: itemToSelect >>>>> event: anEvent ]! >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |