Reading java/awt/KeyEvt.java, it seems like only events in the java.awt.Defaults.RecycleEvents bitmap should be re-used, but I can't see anything in the Kaffe source that would set RecycleEvents to anything but zero. What's going on?
Thanks,
- Benja
Benja Fallenstein wrote:
Benja Fallenstein wrote:Not completely; it starts up, but something in our call hierarchy eats simple key events like single characters, spaces or returns; more complex things like function keys, Tab or PgUp/PgDn are processed correctly. We do recieve the events, apparently, but something eats them. I haven't seen this on the proprietary JVMs, so I guess there must be some kind of incompatibility (trying to process key events across Javas is **icky**). I'll tell if I find out what's causing this.
I have isolated the incompatibility: Kaffe re-uses KeyEvent objects; after issuing a KEY_PRESSED event, it issues a KEY_TYPED event which is the same object, with a field value changed inside. Interestingly, the KEY_RELEASED events seem to be separate objects. Gzz implements its own event queue to coordinate event processing with animation; this is implemented by putting the KeyEvent objects in a LinkedList. As it happens, Gzz by default only reacts to KEY_TYPED events, and as it happens, all three KEY_* events are usually queued before any of them is processed. This means that at the time we get around to processing the key events, we have two KEY_TYPED and one KEY_RELEASED event in the queue (because the original KEY_PRESSED event was changed to KEY_TYPED by Kaffe).
Gzz might be able to work around this, but I suggest that Kaffe not re-use KeyEvent objects, as code like the above works fine on the proprietary Javas and breaks on Kaffe in nonobvious ways. (Caching by using weak references might be an option, but I wouldn't think it's worth it...)
- Benja
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
