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

List:       kde-core-devel
Subject:    Re: klibfactory cleanup
From:       Bernd Gehrmann <bernd () physik ! hu-berlin ! de>
Date:       2001-09-24 19:46:14
[Download RAW message or body]

On Mon, 24 Sep 2001, Simon Hausmann wrote:
> On Mon, Sep 24, 2001 at 08:52:22PM +0200, Bernd Gehrmann wrote:
> > On Mon, 24 Sep 2001, Simon Hausmann wrote:
> > > 
> > > Unless there are further objections I'll add your KDE_EXPORT_COMPONENT_FACTORY macro 
> > > with two arguments to kcomponentfactory.h then (after renaming KLibFactory to 
> > > KComponentFactory - unless someone objects against it :)
> > 
> > I don't see the point. KLibFactory doesn't produce components (which would
> > mean return type QUnknownInterface), it produces QObjects. The notion of a
> > component is very precisely defined in the Qt documentation, so you
> > certainly do not help someone learning the API when you overload a term
> > with an additional meaning.
> 
> The recent qt snapshots show that QCom has been made private API. And I
> indeed speak of QObjects as components from which you can query pure interfaces
> for example using rtti ;)

Maybe I'm missing something, but I don't think that reduces the confusion.
Dynamically loaded QObjects in the latest rsync snapshots are called
'Plugin', not 'Component'. This is even consistent with KParts::Plugin,
which is derived from QObjects :-)

Bernd.

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