|
From: Rainer S. <rai...@ku...> - 2007-04-17 08:59:52
|
Hi all,
whether going as Mac'ish or BP'ish as possible with the keyboard is a =20=
question of program-culture which rests well in the hand of the =20
original author and the old user-community of the program. I guess =20
most newcomers like me would opt for Macishness, but of course there =20
are the ones that have the older rights.
I would like to mention one general problem though, which I =20
repeatedly bump into as a user of a german keyboard, where keys like =20
{} [] | @ =80 and particularly unpleasing the much used \ have to be =20
accessed by means ot the option-key- (or worse:) option-shift-key-=20
combination at some peripheral position of the keyboard. This is done =20=
to allow for Umlaut-vowels (I hope you see them, ASCII is another =20
problem for us:) =F6=E4=FC=D6=C4=DC and "sharp-s" =DF (this letter has =
no capital, =20
so shift-state is not reserved) in the main keyboard region. Of =20
course this goes back to typewriter-days which didn't care much about =20=
mathematicians and programmers - but it is true that even german =20
mathematicians and programmers need the Umlaute (although ASCII =20
requires them to replace them by something, usually ae, oe and ue).
Somtimes we cannot use keyboard-shortcuts defined with a US-keyboard-=20
logic in mind: This occurs when modifier-key-combinations are used, =20
particularly common the shift-key-problem :-) I am not sure that the =20
following list is complete, but it covers the common cases I often =20
bump into:
- As \ requires a german to type option-shift-7, we can neither =20
reproduce a key thought as shift-\, nor the one thought as option-\ =20
let alone the one thought as option-shift\ in american logic :-)
- "non-shiftable" on a german keyboard are ;=3D'/ which are simple base-=20=
state on an american keyboard and simple shift-state on a german =20
keyboard.
- "non-optionable" or "allready-option" are: []|. American simple =20
shift-state-keys which require option (without shift) are: @{} On =20
german keyboards + and # are base-state, *we* :-) could shift =20
them :-) (but see the problem below):
- We can reproduce the logic inherent in shift-[]| by typing option-=20
shift instead of just shift, but those keycombinations could lead to =20
unexpected results, because the base- to shift-state-mapping isn't =20
necessarily the same on any key except letters aA, bB to zZ. I expect =20=
an equivalent problem for the mapping between command, option and =20
control-keys and their respective shift-state-counterparts, but I =20
haven't tested that systematically. It's just good to keep in mind =20
that any (friendly) logic thinking something like: if [ means 'add 5' =20=
it is easy to memorize that shift-[ means 'subtract 5' can break =20
(actually is bound to break on one of the non-american keyboards). =20
(Middle-east and east-asian keyboard users here sort of have an =20
advantage over europeans, as they wouldn't ever dream of using their =20
own keyboard for this type of work. They switch to English - and they =20=
definitely need a coherent, simple and quick way to switch keyboards, =20=
ideally on OS-level)
The shift/command/option/ctrl-state-problem is very a common for =20
german-keyboard users, we are used to living with it in a state of =20
constant semi-confusion and halph-knowledge :-). But I think because =20
of these complications many users prefer to use a menu or toolbar-=20
button instead of key-combinations, and in some "impossible" cases we =20=
really depend on an alternative means to be available. (Or the king-=20
solution: an option to define custom keyboard-shortcuts which allows =20
to enter the shortcut as key-combinations. But this must be very =20
complicated - even dedicated keyboard-tools have problems recognizing =20=
awkward keycombinations like command-option-ctrl-shift-# and knowing =20
which key-combinations they have to block because they are reserved =20
by the system. Winword, to be heroically fair towards *the* arch-=20
enemy, does a reasonably good job on that :-))
Lovely to see bP continuing to progress
All the best
Rainer
On 17.04.2007, at 04:50, Anthony Kozar wrote:
> Hello Bernard (and list),
>
> I was working on revising some keyboard shortcuts today for OS X =20
> and wanted
> to get feedback on what the best choices would be. The problem is =20
> that OS X
> reserves several shortcuts that BP2 was already using on OS 9. =20
> Some of
> these we can continue to use and some we cannot.
>
> The Command-Option-Space shortcut for displaying all of the =20
> settings windows
> is now unusable by applications. It (and all key combinations =20
> involving
> Command-Space) are used for switching among keyboard layouts and =20
> script
> systems or they are reserved for future use by Apple. OS X will =20
> not send
> any of these combinations to BP2.
>
> BP2 was also using Command-Space for muting Midi output with OMS =20
> and for
> playing a Sound-object in the Edit Prototypes window. This =20
> shortcut fails
> to work under OS X as well.
>
> The mute command is obsolete, and for playing a sound-object, I =20
> think that
> we could use Command-P. This is already used for playing the current
> selection in text windows, so this just extends its meaning to =20
> apply to the
> Edit Prototypes window. I could even make the menu item text =20
> change from
> "Play selection" to "Play prototype" or "Play sound-object" when =20
> that window
> is in front to make the meaning clear. Does this sound like a good
> substitute for Cmd-space?
>
> For the Settings menu item, I have been considering a substitute of
> Command-; (semicolon). (The colon : on the same key -- at least on =20=
> U.S.
> keyboards -- is reminiscent of the BP2 settings file icon :)
>
> Also, since this command opens about 8 windows -- 6 of which can be =20=
> opened
> by other menu commands but two of which cannot -- I was thinking about
> modifying it to only open the two "Top" and "Botton" settings =20
> windows (these
> have the titles "Input-output settings" and "Computation =20
> settings"). This
> would make for fewer windows to close when all that you want to do =20
> is change
> one of these settings. However, if the option key is down, the =20
> command
> could open all 8 windows (so the shortcut would be Command-Option-; =20=
> and the
> menu item could change to "Settings (all)" or something like that).
>
> One thing that I want to be sure of is that whatever choice is =20
> made, that it
> can be typed on all (or most) international keyboards. I've =20
> already made
> these changes today to test that it works but I can change them =20
> again in a
> heartbeat. Another possibility would be to make Command-; open all 8
> windows, and Command-option-; to open only the Top and Bottom =20
> settings. A
> third alternative is to use Command-, (comma) but Apple recommends =20
> using
> this for the 'Preferences' item in the application's menu (and I =20
> think we
> will soon have a need for creating a global preferences dialog that is
> separate from the information stored in "project" settings files (-=20
> se)).
>
> Two other conflicts exist in BP2's keyboard shortcuts but they are =20
> not as
> much of a problem. BP2 uses Command-H for opening the Alphabet =20
> window and
> Command-M opens the Metronome window. Command-H (and Cmd-Opt-H) =20
> are used on
> MacOS X for hiding the current (or other) applications. Command-M is
> recommended to be used for minimizing windows. It is possible for
> applications to override either of these though and the OS =20
> gracefully does
> not show Cmd-H next to the 'Hide Bol Processor' menu command. Indeed,
> several text editors override Command-H for 'Find =20
> selection' (BBEdit and
> Codewarrior). So, I do not think it is necessary to change these.
>
> Finally, Command-left-arrow and Command-right-arrow are also used =20
> by the OS
> but only when more than one script system is active (or something like
> that). So, BP2 can still receive these events if the system is not =20=
> using
> them. I personally find it obnoxious for Apple to take over =20
> commonly used
> text editing shortcuts such as these! But we can't stop them :) =20
> These two
> shortcuts will work for most users though.
>
> Lists of all shortcuts used by BP2 and those reserved by the System =20=
> are
> given below for reference. I will be out-of-town the next two =20
> days, but wil
> reply to your suggestions when I get back.
>
> Thanks
>
> Anthony
>
> BP2's shortcuts in use: (Command combined with all of the following)
>
> A B C D E F G H I J K L M N O P Q R S T U V W X Y Z / ? - =3D .
> Opt-A Opt-E Opt-T (was using Cmd-Opt-Spc and Cmd-Spc)
>
> Keys available for use by BP2 (on my keyboard):
>
> ; , ' [ ] \ 1 2 3 4 5 6 7 8 9 0
>
>
> Reserved by the System:
>
> Cmd-H Cmd-Opt-H Cmd-Opt-D Cmd-Shift-Q Cmd-Opt-Shift-Q
> Cmd-~ Cmd-` Cmd-Shift-~ Cmd-Opt-+ Cmd-Opt-hyphen
> Cmd-Opt-* Cmd-Opt-/ Cmd-Opt-Escape Cmd-left/right-arrow
> Cmd-anything-Space Cmd-anything-Tab
> Control combined with various keys (without Cmd)
> using function keys on 10.3 and later also seems like a bad idea
>
>
> ----------------------------------------------------------------------=20=
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> bolprocessor-devel mailing list
> bol...@li...
> https://lists.sourceforge.net/lists/listinfo/bolprocessor-devel
>
>
|
