How can a widget react to a parent's resize? - Motif

This is a discussion on How can a widget react to a parent's resize? - Motif ; I'm writing a composite widget (actually a subclass of XmManager) that should span the entire width of its parent, unless a resource in the composite widget itself says otherwise. The problem is at Initialize time. The parent is doing its ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: How can a widget react to a parent's resize?

  1. How can a widget react to a parent's resize?

    I'm writing a composite widget (actually a subclass of XmManager) that
    should span the entire width of its parent, unless a resource in the
    composite widget itself says otherwise.

    The problem is at Initialize time. The parent is doing its initial
    geometry negotiations, so its core.width resource is 0. This is
    obviously the right answer (or at least not the wrong answer) since
    it's trying to determine how wide it needs to be. By the time the
    parent knows how wide it wants to be, though, its children (including
    my widget) isn't allowed to change its size.

    I really don't want to put a StructureNotify event handler on the
    parent, and setting up a zero-time timeout or workproc isn't all that
    favorable, either. So far, though, those are the only solutions I can
    come up with. I *don't* want to depend on the parent doing the heavy
    lifting (e.g., forcing the parent to be an XmForm with my widget's
    XmNrightAttachment constraint set to XmATTACH_FORM), though that may
    be the most palatable solution.

    Any suggestions other than those?

  2. Re: How can a widget react to a parent's resize?

    On Jul 29, 11:20*am, Joe Sewell wrote:
    > I'm writing a composite widget (actually a subclass of XmManager) that
    > should span the entire width of its parent, unless a resource in the
    > composite widget itself says otherwise.
    >
    > The problem is at Initialize time. The parent is doing its initial
    > geometry negotiations, so its core.width resource is 0. This is
    > obviously the right answer (or at least not the wrong answer) since
    > it's trying to determine how wide it needs to be. By the time the
    > parent knows how wide it wants to be, though, its children (including
    > my widget) isn't allowed to change its size.
    >
    > I really don't want to put a StructureNotify event handler on the
    > parent, and setting up a zero-time timeout or workproc isn't all that
    > favorable, either. So far, though, those are the only solutions I can
    > come up with. I *don't* want to depend on the parent doing the heavy
    > lifting (e.g., forcing the parent to be an XmForm with my widget's
    > XmNrightAttachment constraint set to XmATTACH_FORM), though that may
    > be the most palatable solution.
    >
    > Any suggestions other than those?


    You don't do size negotiations in your Initialize method. Here's what
    you need:

    1. Create a QueryGeometry method (core class part's query_geometry
    field) that is
    called by your parent when the parent wants to know your preferred
    size.

    2. In your ChangeManaged method (composite class part's
    change_managed field)
    that is invoked whenever a child of yours is managed or unmanaged, you
    re-calculate
    your desired size and call XtMakeResizeRequest to tell your parent you
    want a
    new size.

    3. IN your Realize method (core class part's realize field), you do
    the same as
    #2 above.

    4. In youyr GeometryManager method (composite class part's
    geometry_manager
    field), which is called when a child wants to change size, you also do
    the same
    as #2 above after re-determining your desired size.

    --
    Fred Kleinschmidt

  3. Re: How can a widget react to a parent's resize?

    On Jul 30, 10:44*am, Fred wrote:
    > On Jul 29, 11:20*am, Joe Sewell wrote:
    >
    >
    >
    >
    >
    > > I'm writing a composite widget (actually a subclass of XmManager) that
    > > should span the entire width of its parent, unless a resource in the
    > > composite widget itself says otherwise.

    >
    > > The problem is at Initialize time. The parent is doing its initial
    > > geometry negotiations, so its core.width resource is 0. This is
    > > obviously the right answer (or at least not the wrong answer) since
    > > it's trying to determine how wide it needs to be. By the time the
    > > parent knows how wide it wants to be, though, its children (including
    > > my widget) isn't allowed to change its size.

    >
    > > I really don't want to put a StructureNotify event handler on the
    > > parent, and setting up a zero-time timeout or workproc isn't all that
    > > favorable, either. So far, though, those are the only solutions I can
    > > come up with. I *don't* want to depend on the parent doing the heavy
    > > lifting (e.g., forcing the parent to be an XmForm with my widget's
    > > XmNrightAttachment constraint set to XmATTACH_FORM), though that may
    > > be the most palatable solution.

    >
    > > Any suggestions other than those?

    >
    > You don't do size negotiations in your Initialize method. Here's what
    > you need:
    >
    > 1. Create a QueryGeometry method (core class part's query_geometry
    > field) that is
    > called by your parent when the parent wants to know your preferred
    > size.
    >
    > 2. In your ChangeManaged method (composite class part's
    > change_managed *field)
    > that is invoked whenever a child of yours is managed or unmanaged, you
    > re-calculate
    > your desired size and call XtMakeResizeRequest to tell your parent you
    > want a
    > new size.
    >
    > 3. IN your Realize method (core class part's realize field), you do
    > the same as
    > #2 above.
    >
    > 4. In youyr GeometryManager method (composite class part's
    > geometry_manager
    > field), which is called when a child wants to change size, you also do
    > the same
    > as #2 above after re-determining your desired size.
    >
    > --
    > Fred Kleinschmidt


    I'm doing all this now (courtesy of Alestair Gourlay's XmpGeometry
    widget, which I'm subclassing) ... well, *except* for the Realize
    part. That's probably where I need to put it to catch the initial
    size, with subsequent size changes of my widget's parent invoking
    QueryGeometry.

  4. Re: How can a widget react to a parent's resize?

    On Jul 30, 10:44*am, Fred wrote:
    > On Jul 29, 11:20*am, Joe Sewell wrote:
    >
    >
    >
    >
    >
    > > I'm writing a composite widget (actually a subclass of XmManager) that
    > > should span the entire width of its parent, unless a resource in the
    > > composite widget itself says otherwise.

    >
    > > The problem is at Initialize time. The parent is doing its initial
    > > geometry negotiations, so its core.width resource is 0. This is
    > > obviously the right answer (or at least not the wrong answer) since
    > > it's trying to determine how wide it needs to be. By the time the
    > > parent knows how wide it wants to be, though, its children (including
    > > my widget) isn't allowed to change its size.

    >
    > > I really don't want to put a StructureNotify event handler on the
    > > parent, and setting up a zero-time timeout or workproc isn't all that
    > > favorable, either. So far, though, those are the only solutions I can
    > > come up with. I *don't* want to depend on the parent doing the heavy
    > > lifting (e.g., forcing the parent to be an XmForm with my widget's
    > > XmNrightAttachment constraint set to XmATTACH_FORM), though that may
    > > be the most palatable solution.

    >
    > > Any suggestions other than those?

    >
    > You don't do size negotiations in your Initialize method. Here's what
    > you need:
    >
    > 1. Create a QueryGeometry method (core class part's query_geometry
    > field) that is
    > called by your parent when the parent wants to know your preferred
    > size.
    >
    > 2. In your ChangeManaged method (composite class part's
    > change_managed *field)
    > that is invoked whenever a child of yours is managed or unmanaged, you
    > re-calculate
    > your desired size and call XtMakeResizeRequest to tell your parent you
    > want a
    > new size.
    >
    > 3. IN your Realize method (core class part's realize field), you do
    > the same as
    > #2 above.
    >
    > 4. In youyr GeometryManager method (composite class part's
    > geometry_manager
    > field), which is called when a child wants to change size, you also do
    > the same
    > as #2 above after re-determining your desired size.
    >
    > --
    > Fred Kleinschmidt


    Adding the Realize method did the trick ... a little sleazy, if you
    ask me, but it works. Thanks!

  5. Re: How can a widget react to a parent's resize?

    On Jul 31, 7:13*am, Joe Sewell wrote:
    > On Jul 30, 10:44*am, Fred wrote:
    >
    >
    >
    >
    >
    > > On Jul 29, 11:20*am, Joe Sewell wrote:

    >
    > > > I'm writing a composite widget (actually a subclass of XmManager) that
    > > > should span the entire width of its parent, unless a resource in the
    > > > composite widget itself says otherwise.

    >
    > > > The problem is at Initialize time. The parent is doing its initial
    > > > geometry negotiations, so its core.width resource is 0. This is
    > > > obviously the right answer (or at least not the wrong answer) since
    > > > it's trying to determine how wide it needs to be. By the time the
    > > > parent knows how wide it wants to be, though, its children (including
    > > > my widget) isn't allowed to change its size.

    >
    > > > I really don't want to put a StructureNotify event handler on the
    > > > parent, and setting up a zero-time timeout or workproc isn't all that
    > > > favorable, either. So far, though, those are the only solutions I can
    > > > come up with. I *don't* want to depend on the parent doing the heavy
    > > > lifting (e.g., forcing the parent to be an XmForm with my widget's
    > > > XmNrightAttachment constraint set to XmATTACH_FORM), though that may
    > > > be the most palatable solution.

    >
    > > > Any suggestions other than those?

    >
    > > You don't do size negotiations in your Initialize method. Here's what
    > > you need:

    >
    > > 1. Create a QueryGeometry method (core class part's query_geometry
    > > field) that is
    > > called by your parent when the parent wants to know your preferred
    > > size.

    >
    > > 2. In your ChangeManaged method (composite class part's
    > > change_managed *field)
    > > that is invoked whenever a child of yours is managed or unmanaged, you
    > > re-calculate
    > > your desired size and call XtMakeResizeRequest to tell your parent you
    > > want a
    > > new size.

    >
    > > 3. IN your Realize method (core class part's realize field), you do
    > > the same as
    > > #2 above.

    >
    > > 4. In youyr GeometryManager method (composite class part's
    > > geometry_manager
    > > field), which is called when a child wants to change size, you also do
    > > the same
    > > as #2 above after re-determining your desired size.

    >
    > > --
    > > Fred Kleinschmidt

    >
    > Adding the Realize method did the trick ... a little sleazy, if you
    > ask me, but it works. Thanks!- Hide quoted text -
    >
    > - Show quoted text -


    The reason for doing this in the Realize method is to reduce the
    amount
    of work that needs to be done.
    .
    Consider what happens when you create your widget, then sequentially
    create 10 children of that widget, then manage your widget. It only
    has to
    do the size negotiations once. If it were done before being realized,
    the
    negotiations would have been done eleven times, a substantial waste
    of CPU cycles.
    --
    Fred Kleinschmidt

+ Reply to Thread