Resizing child windows

[Carsten Haitzler (The Rasterman)]

On Tue, 4 Sep 2007 22:56:32 +0100 Glynn Clements <glynn at gclements.plus.com>
babbled:

> 
> 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.

the fun starts here when the wm says "no" :) watching widget sets cope with the
wm basically saying "bugger off" to a resize request can be fun :)

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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)