Re: Bug (possibly only with xlib, but I doubt it):addNotifynotalways called for AWT components

[Thomas Fitzsimmons <fitzsim at redhat dot com>]

On Fri, 2005-02-25 at 15:19 -0500, Scott Gilbertson wrote:
>I tried the test again with the "merge from java-gui-20050128-branch to
>trunk" code (main branch from 2005-02-17), with both xlib and gtk.
>
>Running the GTK version, I now get almost the same problem I had before with
>xlib - addNotify doesn't get called for the second and subsequent Component
>added to the CardLayout.  For some reason, with GTK, the things still paint
>properly.  I don't understand that, because they have isLightWeight()=false,
>so you'd think they'd be treated as heavyweights, sending a paint event to
>the peer rather than painting on the parent container.  Since the peer is
>only created from addNotify, there shouldn't be a peer, so like I say,
>I don't see why it works.
>

I'm still not sure I understand the problem -- maybe I'll have to build
the xlib peers and investigate.

>It seems to me that there are two possible explanations for these symptoms:
>either there's a bug in the addNotify thing, but GTK peers somehow work
>around it, or XLIB peers are supposed to somehow work even if
>addNotify isn't called.
>
>What am I missing?
>
>The xlib side needs some work, as events don't go where they're supposed to
>at the moment.  I have a partial fix for that, but it's not right yet.  FYI:
>the partial fix consists of getting XToolkit.iterateNativeQueue to
>return when an event comes in, rather than continuing to loop.  At
>the moment, I'm finding that XEventLoop deadlocks when I call an
>event-posting Component method from the timer run function.  I am
>wondering if iterateNativeQueue is supposed to return after a little
>while even if there are no native events.
>

Yes, that's required.  In the GTK peers we do our own scheduling.  See
the within_human_latency_tolerance function in
gnu_java_awt_peer_gtk_GtkToolkit.c.

Tom