[Qt-interest] why parent widget in constructor?

[Andreas Pakulat]

On 27.04.09 15:06:39, Luca Ferrari wrote:
> On Monday 27 April 2009 13:09:28 Andreas Pakulat's cat walking on the keyboard 
> wrote:
> > On 27.04.09 12:52:50, Luca Ferrari wrote:
> > > On Sunday 26 April 2009 14:12:44 Donal O'Connor's cat walking on the
> > > keyboard wrote:
> > There's no difference between these two creations.
> 
> Yes, sorry, I was thinking to stack allocation and not heap allocation. 
> For heap allocation there is no difference at all, why of course variable can 
> get out of scope when talking about stack allocation.

As I said, that is handled properly by Qt's object system.
 
> > > So, if the above is right there is not a real technological motivation
> > > behind having a parent pointer in the widget constructor, rather it is a
> > > mind-effort to keep memory safe. Please correct me if I'm wrong.
> >
> > The point in parent/child relationships is two-fold:
> >
> > a) a object hierarchy, that manages itself. If I delete an object in the
> > hierarchy the whole subtree is deleted, without me needing to do
> > anything. This is very nice for temporary windows/dialogs, I can create
> > the window on the stack and even if all its children are created on the
> > heap, they'll be deleted for me once the window goes out of scope.
> >
> > b) the parent/child relationship determines how widgets are layered in
> > z-order.
> 
> Of course, but there is no need to build z-order from top to bottom or vice 
> versa.

I don't follow you.
 
> > Well, usually you don't set a parent on the child widget explicitly.
> > setParent is for rare cases where you move widgets or objects around
> > yourself. The usual way is to add widgets to a layout, which will set a
> > proper parent behind the scenes.
> >
> > I agree though that if you want to add larger sets of objects to a
> > parent they haven't been created for then an add method would be useful.
> 
> As you pointed out, working with layouts is different. In particular you have 
> to add (thru and add method) a widget to a layout, and it is not clear (to me) 
> why I should add a widget to a layout instead of simply setting the layout of 
> a parent widget and keep adding the components to the parent widget.

Well, for some things you want a parent, but don't want that widget to
be put into that parent's layout. For example modal dialogs in Qt can be
"window modal", i.e. they only block input to their parent widget, not
to the whole application. There may be other use-cases, for example the
mdi support might need this. 

Also note that the Object-Hierarchy is part of QObject already, i.e. its
not just for widgets, also for other kind of objects. So in some cases,
the parent of a widget might not even have a layout (as you can set a
plain QObject as parent of a widget).

> I also remind that in the qt 2 (maybe) you had to add a widget to the
> layout and express its z-order (so placing the widget double).

Well, there's still both API, i.e. setLayout and
stackUnder()/raise()/lower() on QWidget. No idea how QWidget behaves
when using that though.

Andreas

-- 
Be security conscious -- National defense is at stake.