Resizing child windows

[Glynn Clements]

matthew.garman at gmail.com wrote:

> > the window hierarchy is irrelevant. it's the widget hierarchy that
> > counts. a widget may or may not map to a window. widget != window.
> 
> Yeah, I don't think I asked the question very clearly, but think I
> got the idea anway.
> 
> Even though window != widget, I was making the assumption that all
> (or at least most) widgets are implemented around an X11 Window (or
> at least Drawable).  So with that (incorrect) assumption in mind, I
> was trying to figure out if every single widget (and window by
> implication) needed to be tied to xevents.
> 
> So I think now the better way to look at this is to have generally
> only one "thing" (widget or some other construct) that can catch X
> events (at least dealing with resize), and from there dispatch
> instructions (or at least hints) to all other widgets in the
> collection.  How the "thing" communicates with the other widgets is
> a matter of implementation detail (and not necessarily dependant on
> X11).
> 
> If you can make sense of what I wrote... does that sound more
> accurate?

In terms of event handling, there are basically two cases:

1. The "shell" widget (aka top-level window) gets resized. The shell
widget gets a ConfigureNotify event, and resizes and/or repositions
its children (via e.g. XtConfigureWidget()) to fit in the space
available. If any of the children are themselves containers, they will
do the same to their children, with geometry propagating downwards.

Windows below the top-level are unlikely to be resized except as
directed by the widget to which they belong. The toolkit may not even
bother selecting for ConfigureNotify events for such windows. When a
widget is moved or resized, it will modify its window(s) (if it has
any), and expect them to stay put thereafter.

2. Something (e.g. user action) modifies the state of a widget such
that it's preferred size changes (e.g. appending rows to a list widget
causes its preferred height to increase). The widget notifies its
parent that its preferred size has changed. The parent may do nothing,
or it may resize the child. In the latter case, it may end up changing
its own preferred size, and so on, with notification propagating
upwards. If the shell ends up changing its preferred size, it will try
to resize itself accordingly, with the window manager having the final
say.

-- 
Glynn Clements <glynn at gclements.plus.com>