[134] in java-interest
Three things Applets can't do w/ the current API (with proposed fixes)
daemon@ATHENA.MIT.EDU (Scott Hudson)
Sun May 28 20:07:46 1995
From: hudson@cc.gatech.edu (Scott Hudson)
To: java-interest@java.Eng.Sun.COM
Date: Sat, 27 May 1995 23:56:13 -0400 (EDT)
Here are three things that common interaction techniques need to
do, but which are impossible under the current Applet API (followed
by a relatively painless fix for each).
1) Using the modifier keys
Currently there is no way to write an Applet which responds differently
to a mouse click with the shift key down vs. one without. This is
typically used for example in extending vs. replacing the currently
selected object set. This is because the modifier information is not
passed in to any of the Applet input methods.
Proposed fix: pass the actual event as an additional final parameter to
each of the input routines. For example:
public void mouseDown(int x, int y)
becomes:
public void mouseDown(int x, int y, Event e)
The event exists in the caller and is easy to pass. Note for various
reasons (including #3 below) its easiest to pass the whole event, not just
the modifiers. This breaks existing code only to the extent of needing to
add the parameter to the method interface (and recompile) -- otherwise
the code can just ignore it.
2) No "meta" key
Most (all modern?) platforms have at least one additional modifier
key beyond shift and control (my Sun here has alt, meta, compose, and
altgraph, my Mac has option and command, PCs have alt). One of
these keys is typically used, for example, to indicate menu
shortcuts. However, these keys cannot be used by Applets (even if
Events are passed in as above) since they are not included in the
modifiers field of Events.
Proposed fix: add the constant
"public static final int META_DOWN = 4;"
after CTRL_DOWN in class Event, and propagate it up out of the underlying
native window system(s). This breaks nothing, but may require recompiles.
3) Double clicks
Its currently not possible to do a decent job with double clicks because
there is no timing information associated with inputs. (Timing information
is also very useful in other interactions techniques, but double clicks
are the most common.)
Proposed fix: add timestamps to events, and propagate these up from the
native window system. Specifically add something like:
public int when;
to Event. This would be a time in milliseconds, with actual granularity
platform dependent and not guaranteed. This would be a relative time such
that two events coming from the same window server could be compared, but
not necessarily such that it could be mapped back to an absolute time
(e.g. these numbers may not have any easy to determine relationship with
those returned by System.nowMillis() ). Note: whenever possible, this
time should reflect when the event occured rather than when it was processed,
or placed in a queue somewhere. This breaks nothing, but may require
recompiles.
Scott Hudson
http://www.cc.gatech.edu/gvu/people/Faculty/Scott.E.Hudson.html
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
