Resizing child windows

[Glynn Clements]

Tomasz Torcz wrote:

> > > On Fri, Aug 31, 2007 at 07:58:49AM +0900, Carsten Haitzler 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.
> > 
> > definitely was incorrect to assume :) gtk and qt and motif and xt have child
> > windows - i can say for certain that ewl and etk have zero child windows -
> > nothing at all except the main window for the app window. you need events.
> > otherwise how do you know whjat the mouse or keyboard is doing - but how you
> > route and marshall events can vary from widget set to widget set.
> 
>  If I understand correctly, newest Qt do not have child windows anymore:
> http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/

I always suspected that the Qt devs don't "get" X; now I know for
sure.

If they wanted to avoid the drawing issues without globally enabling
MotionNotify, they could have drawn in the parent and created
InputOnly windows to capture {Enter,Leave}Notify. But this part
suggests that either they don't understand the issue or don't care:

	Needless to say, but apart from reducing flickering, an
	application with windowless child widgets is much more
	light-weight and resource friendly as we don-F’t allocate native-A
	windows for every single widget.

It's only "resource friendly" if you ignore the overhead of processing
(as well as transmitting) all of those MotionNotify events.

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