Re: [bp-dev] Keyboard shortcuts

[Anthony K. <ant...@sb...>]

Yesterday, I finished updating the keyboard shortcut code.  Using the "new"
functionality introduced with MacOS 8, BP2's shortcuts like Cmd-Option-E,
Cmd-Option-O, etc. should now work with EVERY keyboard layout that uses the
Roman script system.  I have tested it with numerous layouts (French,
German, Swiss Fr/Ger, Canadian, Italian, Spanish, etc.) and did not find any
problems yet.

Also, the new Command-Option-; shortcut for Settings works on all of the
layouts that I tried (including the ones that require shift to be typed).
You simply type ';' however you would normally do so while holding down the
Command and Option modifiers.

On systems without the Appearance manager (only pre-MacOS 8 without the
Appearance extension), BP2 will automatically revert to using the old code
that maps U.S. and French option-generated characters to menu commands.  So
System 7 users are out of luck in this regard but I do not see that as a
significant problem ;-)

A few more notes are below, but the gist of this message is "it all works
now" :)

Anthony


>> I have also found in my experiments that the Caps-lock key can cause more
>> problems.
>> So, currently, with the caps-lock key on, BP's shortcuts like
>> Command-Option-A and Command-Option-O do not work.

The new functions used in BP2 correctly ignore Caps-lock as far as I can
tell when interpreting Command key combinations.

>> I discovered yesterday that while OS X will yield Command-H
>> to BP, it will not yield Command-Option-H (used for displaying the tokenized
>> alphabet) the first time that it is pressed.  It initially steals this
>> keypress to hide all other applications.  If they are already hidden, then
>> it will pass the keypress to BP.  (Confusing!)

Actually, I found out that if BP2 explicitly marks one of its menu commands
as using Command-Option-H using the OS functions available with MacOS 8,
then OS X will yield that combination to us as well.

> Command-Option-H should remain a Finder command. Nowadays it is used a lot (I
> use it a lot!) because there are often other applications (email, web
> browsing) open in the background.
> 
> Keeping Command-H for displaying the alphabet window is not a bad idea because
> it is not of great interest to hide BP2 when it is in front. Do hide a front
> application I generally click one in the back (including the Finder) and then
> Command-Option-H.

I suppose this will always be a matter of individual preference.  I
personally usually use the menus for hiding applications because I am not
yet used to using Command-H and because several programs that I use on OS X
override this shortcut.  Some users (like my wife) rely very heavily on
using Command-H though.

Eventually, I think we could make this a user preference item.  For now, it
does not make sense to me to have a menu item with shortcut Command-H
(Alphabet) that changes when the Option key is down (to Tokenised Alphabet)
but for which Command-Option-H does nothing (or something else).  I would
prefer a consistent "all or nothing" approach (or the use of the Shift key).

>>> I agree with Anthony's suggestion to make Command-; open all 8 setup
>>> windows, and Command-option-; to open only the Top and Bottom settings.

>> However, I would
>> like to reconsider the choice of shortcuts since Command-Option-; may not
>> work on many keyboards.

I've left the Settings shortcuts as Command-; and Command-Option-; at this
time.  They seem to be type-able and work on all of the keyboard layouts
that I have tried.  I wish that we could make it work without the Shift key
on those keyboards where ';' is a shifted character but the MacOS 8
functions for interpreting key commands do not work that way.

(This means I had to leave in the special code for interpreting Command-/
and Command-?).

By the way, with the new way of assigning keyboard shortcuts, the menu items
now automatically display the standard "Option glyph" on the right side of
the menu;  so, I stopped BP2 from printing "Cmd-Option-A", etc. in the menu
text.  This could be an incompatible change if one of those menu commands is
used in a BP2 script, but it seems unlikely to me that anyone will be using
those particular items in a script.  The affected items are "Enter... find",
"Find again", and "Type tokens".

Anthony