[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: kdenonbeta/kparts/lib
From:       weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-11-15 23:43:37
[Download RAW message or body]

Hi,

On Mon, 15 Nov 1999, David Faure wrote:

> On Tue, Nov 16, 1999 at 12:22:58AM +0100, weis wrote:
> > Hi,
> > 
> > On Mon, 15 Nov 1999, Simon Hausmann wrote:
> > 
> > > 
> > > 
> > > On Mon, 15 Nov 1999, weis wrote:
> > > 
> > > > Hi,
> > > > 
> > > > On Fri, 12 Nov 1999, CVS by dfaure wrote:
> > > > 
> > > > > 
> > > > > kdenonbeta/kparts/lib kpart.cpp,1.11,1.12 kpart.h,1.13,1.14
> > > > > Author: dfaure
> > > > > CVSROOT: /home/kde
> > > > > Fri Nov 12 16:04:18 MET 1999
> > > > > Update of /home/kde/kdenonbeta/kparts/lib
> > > > > In directory zeus:/tmp/cvs-serv3052/lib
> > > > > 
> > > > > Modified Files:
> > > > > 	kpart.cpp kpart.h 
> > > > > Log Message:
> > > > > more API improvement : KPart::embed(parentWidget) will do the reparent().
> > > > 
> > > > Grrr, reparent. The approach without the ::widget() function did not need
> > > > a reparent ....
> > > 
> > > Oh, well, I think it still did :) , because once you got the widget via
> > > ::widget() you still need to reparent it in order to insert it into your
> > > widget hierarchy :)
> > > 
> > > Or am I wrong?
> > > 
> > > > You want to find bugs in Qt, dont you :-)))
> > > 
> > > Hehe :-))
> > 
> > Of course, with widget() you need that. With the old approach you
> > did not, because you passed the parent at construction time of the
> > KPart.
> 
> I already changed the code to avoid reparent, passing the parent
> at the constructor of the KPart-inherited class (not KPart itself).
> 
> > In KOffice the Document has a createView function which takes the
> > parent, so no reparent is needed.
> This looks like it matches my fix.
> 
> > If we would have
> > 
> > class KPart
> > {
> >  // Returns the widget if already constructed
> >   QWidget* widget();
> >  // constructs the widget. On second call gives error and returns
> >  // pointer to already created widget.
> >   QWidget* createWidget( QWidget* parent, const char* name )
> > };
> > 
> > We would not need to reparent. I personally consider reparent bad
> > programming style, but perhaps thats just me ...
> I agree - but I don't see the need for the complex (a bit) API above.
> Passing the parent QWidget to the KPart constructor looks ok to me ?
> 
> (Have a look at kdenonbeta/kparts, it's already there. The ::embed
> call using reparent is still here but not used anymore).

Cool. Passing it in the constructor is fine with me!

Bye
Torben

> -- 
> David FAURE
> david@mandrakesoft.com, faure@kde.org
> http://home.clara.net/faure/
> KDE, Making The Future of Computing Available Today
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]