Hi Tom, On Thu, 2006-02-09 at 09:53 -0500, Thomas Fitzsimmons wrote: > An unrealized GtkComponentPeer is a GtkWidget that has an > uninitialized X window field. In other words, the X server doesn't > have a window data structure allocated for it. We used to > force-realize every GtkComponentPeer on construction but that lead to > strange behaviour when adding a hierarchy of components to an > already-shown container (all components would be shown first at > 0,0-1x1 then layed out after that). > Delayed realization makes the peer code much more complicated, and > adding a container to an already-shown container is rare so I'm > thinking it may be acceptable to switch the code back to > force-realization-on-creation. It would simplify GtkComponentPeer > GdkGraphics and would probably eliminate these situations that you're > describing.
OK, I see now where the trouble comes from. In GtkComponentPeer
constructor we have:
// Only set our parent on the GTK side if our parent on the AWT
// side is not showing. Otherwise the gtk peer will be shown
// before we've had a chance to position and size it properly.
if (awtComponent instanceof Window
|| (parent != null && ! parent.isShowing ()))
setParentAndBounds ();
So if a component is added to an already showing Container its parent is
not set. We try to set it later in GtkContainerPeer.endValidate(). But
1) There is a small bug that doesn't setParentAndBounds for direct
children of a Window. (That is easily fixed though.)
2) That only works if the Container is actually revalidated before the
just added Component is painted.
I don't see how/if 2) ever happens/should happen after a
Container.add(Component). The Container is invalid after an add().
When/Where should validate[Tree]() be called after a new component has
been added?
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
