|
From: Anthony K. <ant...@sb...> - 2007-04-20 14:00:52
|
Thanks very much, Rainer, for bringing all of these issues to my attention!
There are other Mac programs that I work on as well that could be affected
by these problems.
Yesterday, I thoroughly investigated what happens when using other keyboard
layouts and some possible solutions. I tried various European and
English-speaking layouts and found that they all had problems with BP's
current shortcuts except for U.S. and French. (Which is how Bernard
designed the program).
The main existing issue is the shortcuts involving the Option key.
Currently, when the user presses Command-Option-E, for example, BP does not
receive the keypress expressed that way, it receives it as Command-=C2=B4 or
Command-=C3=AA, etc. depending on what character option-E produces with the
user's keyboard layout. And BP only has logic to map the U.S. and French
option characters to menu commands. In most cases, these shortcuts just do
not work for users of other keyboards, but in a couple of cases that I
noticed, pressing the shortcut for one menu command could actually invoke a
different command than expected!
There is a newer system function that we could call instead that is suppose=
d
to handle shortcuts involving shift, option, and control modifiers.
("newer" here means that it was actually introduced with MacOS 8 ;) I am
hoping that this will solve the problems with BP's existing Cmd-Option
shortcuts for all international users using the "Roman" character set.
However, I am now not sure that Command-; and Command-Option-; will be good
choices for the Settings command. Command-; seems to be type-able on all o=
f
the keyboard layouts that I tried although it sometimes requires use of the
shift key. (Which would make Command-shift-; a bad alternative). But
option-; produces a different character on many of these keyboards and I am
not yet sure whether the MacOS 8 solution will take care of this in all
cases (especially when shift is involved). I can experiment once I
implement the new code, but I am beginning to think that it may be best
practice to only use shortcuts involving alphabetic characters.
Thanks again -- I hope to have this all sorted out by the next release.
Anthony
Rainer Schuetz wrote on 4/17/07 4:59 AM:
> I would like to mention one general problem though, which I
> repeatedly bump into as a user of a german keyboard, where keys like
> {} [] | @ =E2=82=AC and particularly unpleasing the much used \ have to be
> accessed by means ot the option-key- (or worse:) option-shift-key-
> combination at some peripheral position of the keyboard.
[...]
> Somtimes we cannot use keyboard-shortcuts defined with a US-keyboard-
> logic in mind: This occurs when modifier-key-combinations are used,
> particularly common the shift-key-problem :-) I am not sure that the
> following list is complete, but it covers the common cases I often
> bump into:
[...]
> The shift/command/option/ctrl-state-problem is very a common for
> german-keyboard users, we are used to living with it in a state of
> constant semi-confusion and halph-knowledge :-). But I think because
> of these complications many users prefer to use a menu or toolbar-
> button instead of key-combinations, and in some "impossible" cases we
> really depend on an alternative means to be available.
[...]
|
