[2197] in java-interest
Re: Function keys & arrow keys
daemon@ATHENA.MIT.EDU (Glen C. Perkins)
Tue Sep 26 18:56:31 1995
Date: Tue, 26 Sep 1995 13:02:43 -0700
To: java-interest@java.sun.com
From: Glen.Perkins@NativeGuide.com (Glen C. Perkins)
------------------
>
>From: Tako Schotanus <Tako.Schotanus@bouw.tno.nl>
>Date: Tue, 26 Sep 1995 15:44:52 +-100
>Subject: RE: Function keys
>
>>> If it is the intended action, is there any way I can extend
>>> the keyboard handler to let me process the function keys?
>>
>>We didn't add function keys yet because it is hard to come up
>>with a set of function keys that are on every keyboard! Maybe later.
>
>Hmmm, and what if you define the most common ones like f1 - f10 and
>cursor keys? If any of these doesn't exist for the platform you're using
>you could always map some other key(s) to act like function keys.
>
Yes, please define the function keys and the arrow keys. As a software
designer, I've had to write software that ran on multiple keyboards. It
wasn't that hard to do. You just have to write multiple paths to the same
methods.
I would write a method that was supposed to be executed when the up
arrowkey was pressed. Call it "goUp()". Then I would execute goUp() if the
up arrowkey were pressed. The fact that some of my users didn't have an up
arrowkey to press didn't break my code. It just meant that I would never
get a message from their up arrowkey. That would no more crash my code than
a user who had an up arrowkey but never pressed it.
Knowing that some users would never be able to press a non-existent up
arrowkey, I also designed my software so that the I,J,K, and L keys (and
the E,S,D, and F for lefties) also functioned identically as arrowkeys. (I
was fortunate that those keys didn't have to function as letter keys, but
if I had needed them for letter keys, I would have made it control-I,J,K,
and L or some other unused combo.) On keyboards with arrowkeys, the users
could use either the arrowkeys or the IJKL (or ESDF) keys (there's no
reason to turn off the substitutes on keyboards with real arrowkeys. In
fact, on laptops with the arrowkeys arranged stupidly in a row instead of
an inverted T, forcing you to look at them before hitting them, most users
preferred using the alternate keys anyway!)
Whether the user hit the up arrowkey or the I or E, the same goUp() method
was called. Most software designers who write consumer software are
accustomed to coding for diverse keyboards, mice, monitors, etc. Let us do
the same with Java.
If I forgot to provide an alternative for some users with no Fkeys,
monochrome monitor, etc., the users would let me know and I would fix it.
This happens all the time to those of us who also write HTML. (I have
parallel pages for table-challenged browsers.)
If Java intended to solve all of these problems by only including the
greatest common specifications (often ridiculously called "least common
denominator"), then color shouldn't be supported in Java either since
software that relies on color exclusively to make some distinction will not
work effectively on a one-bit monochrome monitor. That's absurd, of course.
Java should support human interface elements that are usually available
even if not universally available, and there should be a good designers'
guide to writing universally usable software to teach software designers
how to deal with the diversity of platforms out there. (I.e. don't use
color as the ONLY way to make a distinction, don't assume the user has
arrowkeys or Fkeys and create alternative key combos, use the control key
to simulate the second mouse button on a one-button mouse, etc.)
>Or you could have default key-bindings which will always be available,
>whether your platform/keyboard has function keys or not (eg F1 - F10
>might map to CTRL 1 - 0 and the cursor keys to CTRL u, d, l & r).
>
>- - Tako
No, please don't. You have no way of knowing which keys will be used for
what in my app. Nothing is "always available." Let me decide what keys mean
what. Java should just allow me to detect ALL of the keypresses, and how I
use them is a software design decision, not a language design decision.
__Glen__
http://www.nativeguide.com
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
