Patch: FYI: Attempt to get xlib peers working again

["Scott Gilbertson" <scottg at mantatest dot com>]

I checked in (to trunk) this patch, which attempts to get the xlib peers
working with the latest AWT code.  Very simple applications (a Frame
containing a Panel on which some static text is painted) work on the xlib
peers with this patch.

The change involves getting the blocking mechanism to behave in the xlib
native queue, including addition of a timeout when waiting for events (as
was done on the GTK peers, so that non-native events can sneak in).  There
are still a couple of fairly serious problems:
 1. deadlocks happen trying to create AWT events from outside the dispatch
thread
     (from a java.util.Timer in the example I tried)
 2. addNotify doesn't get called for lightweights added to a CardLayout

Problem #1 does not seem to happen with GTK peers, so my patch is obviously
not a complete fix.

Problem #2 prevents the affected components from painting with the xlib
peers.  With GTK peers, the components paint OK, but I don't know why (If I
did, I could perhaps employ the same trick with xlib).  Since the peer is
created in addNotify, and addNotify isn't getting called, and a component
only returns true from isLightweight if it has a peer, and only lightweights
pass paint events to the (ultimately heavyweight) parent, and only
heavyweights can actually paint anything, nothing should be painted.  I'm
all ears for ideas on that front.

 * gnu/gcj/xlib/natXAnyEvent.cc (loadNext): Added timeout.
 * gnu/awt/xlib/XCanvasPeer.java (setBackground): Removed
    throw UnsupportedOperationException, fixed comments.
    (setFont, setForeground): Fixed comments.
 * gnu/awt/xlib/XEventLoop.java (postNextEvent): Changed
    return type to boolean.
    (getNextEvent): Fixed javadocs.
 * gnu/awt/xlib/XToolkit.java (interrupted): Removed field.
    (nativeQueueEmpty): Removed unused code.
    (iterateNativeQueue): Removed outer loop.

Attachment: 20050303_xlibfix.patch.txt
Description: Text document