jhs@MITRE-BEDFORD.ARPA (04/18/88)
Steve Klassen's suggestions (latching the keypad on, having multiple keypad definitions available, etc.) sound useful to me. For a single keypad, it occurred to me that (assuming it can be read by the software) SHIFT-SELECT could be used to lock the keypad mode, while SELECT plus a keypad key could act the way OmniCome does now, i.e. keypad mode is activated only while the SELECT key is held. This would be a true "upward compatible" upgrade from the OmniCom convention. With this convention, touching the SELECT button would unlock the SELECT mode. This very much in the spirit of the way the SHIFT and CAPS keys work, or the SHIFT and SHIFT LOCK keys on a normal typewriter. Because of this, I think it would instantly feel completely natural to current users of OmniCom, as well as to those who had not previously used it. I believe KERMIT65 will get a key definition capability soon, but probaby will use the OPTION key to perform the function that OmniCom uses the SELECT key for, since SELECT has been assigned a function already in KERMIT65. (Of course, John Dunning might decide to reverse the convention for compatibility, since KERMIT is still not finalized.) As for the multiple keypad definitions, John D. is mulling over ideas like this right now (I hope!). If he chooses to support several different keypad maps simultaneously, I'd suggest something like a CONTROL key pressed while in keypad mode, e.g. SELECT-CTRL-1 for keyboard definition 1, SELECT-CTRL-2 for defintion 2 etc. (Using the SELECT key for consistency with the above -- it might all use the OPTION key if John keeps it that way.) In this framework, SHIFT-SELECT (or OPTION) would put the terminal in keypad mode, CTRL-1 would select definition 1, and SELECT (or OPTION) would drop back out of keypad mode but retain the definition 1 layout. Anybody else have suggestions for vt100 emulator standards or conventions? -John Sangster / jhs@mitre-bedford.arpa