Resizing child windows

[Carsten Haitzler (The Rasterman)]

On Wed, 5 Sep 2007 15:50:58 +0100 Glynn Clements <glynn at gclements.plus.com>
babbled:

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

imho the gain from less events skipping motion notifies is moot when your
display system is complex enough - any widget or part of a widget can respond
to any and every mouse event - just as part of the theme and animation. i
capture all mouse events as a matter of course because it lets me marshall my
way on my end (i do things x can't like report mouse events to 2 overlayed
objects (eg 2 overlayed windows - and both get the mouse) for example. the only
way that works is if u do it yourself. in x the events go to the window that's
on top.

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

that overhead is really nothing to worry about. for every time u need to
reconfigure u need to not just draw but also move/resize a bunch of windows and
also handle their stacking when you have them overlap? for that matter
non-rectangular event regions - see how wonderfully efficient x gets with
window shapes having to be generated and set/reset from client to server side,
instead of simply handling it with much more efficiency client-side. once you
get sufficiently exotic - x's event stream breaks down and you DIY. since the
cost difference is really negligible (these days) you go for just 1 model for
simplicity. they are doing the right thing by their design and needs. zack
isn't dumb by any stretch of the imagination and he knows his way around x.

> -- 
> Glynn Clements <glynn at gclements.plus.com>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg

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