[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:22:58
[Download RAW message or body]

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.

In KOffice the Document has a createView function which takes the
parent, so no reparent is needed.

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

Bye
Torben

> Ciao,
>  Simon
> 
> 

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