[squeak-dev] The Trunk: Morphic-cmm.409.mcz
Levente Uzonyi
leves at elte.hu
Mon Apr 5 18:59:24 UTC 2010
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? :)
Left and right doesn't work well with the search bar concept, just try
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 ]!
>>>
>>>
>>>
>>
>>
>
>
More information about the Squeak-dev
mailing list
|