Re: [bp-dev] Keyboard shortcuts

[Bernard B. <ber...@gm...>]

>Yes, I think that this is a good practice even if only designing for a
>single keyboard layout.  In general, I believe that the use of
>non-alphabetic keys for shortcuts should allow either the un-modified or the
>shifted character to invoke the command.  So, while the shortcut might be
>shown as Command-? in the menu, a U.S. user should not have to type
>Command-shift-/, Command-/ should work.

That would be Command-, (Command-comma) on French keyboards.

>The problem with this approach --
>that I now understand more clearly -- is that these characters are paired
>differently on other keyboard layouts and supporting every layout could be a
>headache or could be impossible.

There are so many keyboard layouts that figuring out universal Command keys is unthinkable beyond the 24-key English alphabet. Since we can't cover all the program's requirements using these 24 keys in a comprehensible way, it will be a safe compromise that several combinations of symbols outside this basic alphabet are used to launch the same process.

Experienced Mac users know that if they press the Command key a process is going to be launched; therefore there is no risk that they launch a process by mistake when they were trying to type the characters of non-English scripts.

>I have also found in my experiments that the Caps-lock key can cause more
>problems.  When it is on, _some_ of the characters produced with Option get
>changed to their shifted equivalents but others do not (generally seems to
>be when option-shift produces a capitalized version of the same character).
>So, currently, with the caps-lock key on, BP's shortcuts like
>Command-Option-A and Command-Option-O do not work.

Caps-lock is a headache for users unless they use it for filling uppercase-only forms.  We may therefore assume that BP2 users deactivated caps-lock before using the program. (No way to send them a warning, though, because caps-lock can't bee sensed as far as I remember.)

>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!)

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.

>This is exactly how I feel about toolbars with icons.  For all but the most
>commonly used toolbar commands, text labels are easier to understand in my
>opinion.  And I do not think that tool-tips helps this problem -- it reduces
>productivity to have to constantly mouse-over each toolbar icon to find the
>one that you want.

And tool-tips become annoying once you know the icons...
We have enough monitor space to allow for verbose buttons.

> > 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.
> > The semicolon is also a lowercase position on French keyboards, and if it
>> is uppercase in some other languages (which I doubt because it has
>> something to do with the case of the next word) either users will learn
> > using the key combination or they will use the menu command.  Be careful
>> that the option key also opens the 8 windows if launched from the menu.
>
>I have finished implementing this to work in this manner.  However, I would
>like to reconsider the choice of shortcuts since Command-Option-; may not
>work on many keyboards.

You may keep it for the time being.  As Rainer pointed out, Mac users who work with exotic scripts/keyboards often switch to US-English keyboard when using software that is not specific to their language.  Therefore it is not embarassing to cover only a limited number of keyboard setups.

> > Abandonning Command-H for the alphabet window is fair. In fact we might
>> drop the shortcut for the alphabet window because it is not one that is
>> often opened and closed, unlike the data and grammar windows.
>
>I have not changed this yet.  Should I do so?

You may leave it and see whether we get complains about it.

> > Command-Y might be reserved for "redo" if later implemented as the
>> "Trace" window does not really need a shortcut.
>
>Command-shift-Z is now usually used for a separate Redo command.

Then it is proper to implement it this way.

>In the future, we may even consider
>enlisting the help of some of our users to localize BP for several
>languages.

I already have a Chinese programmer in my team. ;-)

At a later stage, the multilingual text editor could be used for writing grammars/items in several scripts, though it is difficult to have a complete implementation of Unicode.  For instance, phpWiki supports Chinese script except for linked words.

Bernard Bel