|
From: Bernard B. <ber...@gm...> - 2007-04-28 08:47:46
|
>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 ;-) We're not working for museums anyway. ;-) This reminds me of the day my son took me to a friend's place to watch "System 7" on a "Mac II". It looked like visiting another planet. Alltogether, I don't think we should hesitate to impose minimum MacOS 9 if it becomes necessary for compatibility. Today, people who can't afford MacOS 9 are certainly missing other things more vital than BP2... > > 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. I should have said, except if we need to look at a soft synthesizer that is running behind it, as I do with Pianoteq at the moment. But because of the large monitor and the small default sizes of BP2 windows, I can see Pianoteq (an my email :-) while running BP2. > > To 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. BP2 users might use it as well if they need to shift to synthsizers and various settings in the background. >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). We said that the "Alphabet" shortcut is much less important because users don't do so many things in that window as they do in the Grammar, Script or Data windows. We have no left-over key in the English alphabet that could be used. "H" is actually the abbreviation of "homomorphism" because what the "Alphabet" window shows is homomorphisms between terminal symbols. Indeed, when there are no homomorphisms it only shows the symbols... This is a bit too theoretical, just to say that "H" was not a random choice. In the current version, Command-shit-H does the same as Command-H. This means that we could impose "shift H" as a shortcut to the alphabet window, for the ones who really want a shortcut. > >>> 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. Another way would be to suppress the shortcut to the Script window. I am not against it because a script is usually kept on the side of the screen while we are working with it. In this case, Command-hyphen and Command-option-hyphen would become available for settings. The hyphen (minus) sign is also available on numeric pads that are very popular on keyboard layouts (such as French) putting numbers on shift-keys. For fanatics of shortcuts, Command-shift-s could be assigned to the Script window. >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". Yes, this is never recorded as script, nor would it be interpreted as a script instruction. Therefore it is good to have this glyph that I was never able to handle in MacOS 9 for some reason. Bernard |
