GtkComponentPeer realization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://developer.classpath.org/pipermail/classpath/attachments/20060219/f332559c/attachment.pgp

[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux