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

List:       kde-commits
Subject:    Re: kdenonbeta/kparts/lib
From:       David Faure <faure () kde ! org>
Date:       1999-11-15 23:31:05
[Download RAW message or body]

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

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