kdevelop component factories

[Bernd Gehrmann]

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.

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

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

Bernd.