I play with the idea of introducing generic, device-dependent extension events (inspired by the X Input Extension - see http://capderec.udg.es:81/ebt-bin/nph-dweb/dynaweb/SGI_Developer/X11_LibSpc):
An extension device provides keys, buttons, and motion data.
There is a primitive to list all available extension devices with their parameters: - number of keys, min and max key code - number of buttons - number of axes, min and max value for each axe
Then there is another primitive to request events for a device ("open" the device). After this, device events would be fed into the main event queue: key press/release events, button press/release events, and motion events: - Each event: device id and timestamp - Key event: key code, pressed/released flag - Button: button number, pressed/released flag - Motion: current value of each axis This last event might be too large for the current 8 int array - there could be a "continuation flag" so two events get read.
This gives unified access to almost every input device there is. Some examples:
Keys:min..max But. Axes:min..max Keyboard 248:8..255 0 0 Mouse 0 3 2:0..1024,0..768 Tablet 32:8..39 4 5:0..30480,0..24060,0..1023,-64..64,-64..64 Joystick 0 2 2:-128..128,-128..128
(The first three are actual values from my setup - the tablet motion data is x, y, pressure, tilt x, tilt y, the buttons are on the stylus, the keys are regions on the tablet that can be clicked)
This achitecture would easily be supported in X, I guess Windows provides something similar with DirectInput, don't know about Mac.
How does that sound?
-- Bert
On Fri, Dec 01, 2000 at 02:19:09PM +0100, Bert Freudenberg wrote:
I play with the idea of introducing generic, device-dependent extension events (inspired by the X Input Extension - see http://capderec.udg.es:81/ebt-bin/nph-dweb/dynaweb/SGI_Developer/X11_LibSpc):
<snip>
How does that sound?
-- Bert
This sounds great to me. I would also like to suggest:
- Input events can be (and should be) generalized to represent any external event, most notably file and socket events. Tk/tcl provides a good example of how this is done (at least in concept; I have not really looked at the implementation). This is important because it would enable some nice simplification and clean-up of the Socket and FileStream hierarchies.
- Why not move more of this into the image instead of coding it in the VM? It would be a lot easier to adjust the design that way, and I don't think we've completely sorted out all the design issues yet. For example, hard-coding the representation of events to a certain number of bytes in the VM seems rather short-sighted. If performance is a problem (I doubt it), things can always be moved back out to the VM later on.
Dave
squeak-dev@lists.squeakfoundation.org