kdevelop component factories

[Simon Hausmann]

On Tue, Apr 09, 2002 at 10:38:16AM +0200, Bernd Gehrmann wrote:
> On Sunday 07 April 2002 20:19, you wrote:
> > With this instantiation FooPlugin needs to provide the following
> > constructor:
> >
> > FooPlugin( KDevApi *parent, const char *name, const QStringList &args );
> >
> > The factory will call it, if the passed classname in the create call
> > is 'FooPlugin' and if the parent Qt object inherits from KDevApi,
> > allowing a safe cast. The args string list is just passed on from
> > create() .
> 
> That means that in order to instantiate the template, the class KDevApi
> must be defined? This is in contrast to the old behavior, where KDevApi
> is a completely opaque class and its header file is not needed by the
> plugins.

I was afraid of that first, too, but then I realized that there's a
much simpler solution: We just keep a QObject pointer as parent and
perform a safe cast to KDevApi in the KDevPlugin constructor.

> > Applying this feature to kdevelop would solve the first mentioned
> > point, but it would also mean that kdevelop parts are always child
> > objects of the KDevApi object. I don't think that's necessarily a
> > bad thing, because it makes it easy for other plugins to look for
> > other plugins by just using QObject::child() on the devapi object.
> > But then again, I might overlook something and maybe it's a bad
> > idea. Bernd, what do you think?
> 
> Maybe then it would make sense to merge KDevApi and KDevPartController?

Maybe :)

> > The only solution that comes to my mind is to change the inheritance
> > of KDevPart, to make it not inherit from KParts::Part anymore, but
> > to make it multiply inherit from QObject and KXMLGUIClient. (maybe
> > it should be called KDevPlugin then?)
> 
> About 20 months ago its name was KDevComponent and it was
> inheriting KParts::Plugin. The times they are-a changin :-)
 
:)

> BTW, we have a directory parts and a directory plugins, and they contain
> very different things. So just renaming classes will not necessarily
> reduce the confusion.

Sounds like it might be worth to merge those. Should be possible by
copying on the server. Given that parts contains more subdirectories
I'd suggest to copy plugins/* to parts/ .


Simon