kdevelop component factories

Matthias Hölzer-Klüpfel mhk at kde.org
Sun Apr 7 23:45:05 UTC 2002


On Sunday 07 April 2002 20:19, Simon Hausmann wrote:

[long explanation skipped]

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

I hope you will read my comment as well ;)

I think that having all the plugins (part is really a bad term) being children 
of KDevApi is really an advantage. I start to see a need for plugins to find 
out if other plugins are present, and the child() mechanism sounds reasonable 
(especially if we add a little syntactic sugar around it to find other 
parts).


> The second point is a bit more difficult. 

[snip]

> 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?)
>
> And somehow I think that would make sense. The reason why
> KParts::Part as base interface exists is to implement the idea of
> graphical components, that can have a state like being active or
> inactive, with the activation being handled by a PartManager. By
> KDevPart design this is not the case for kdevelop components, as they
> don't have a widget. They still are GUI components in the sense that
> they provide menu/toolbar items though.

Again, I fully agree with your reasoning. What we call KDevParts are no parts 
at all (in fact, the code loading the KDevParts is called "PluginController" 
for exactly that reason ;), but plugins. The private widget() method is 
confusing. Plugins can have a UI, by providing SelectViews or OutputViews, 
but these views are different from the parts shown in the document area.

So if you can clean this up, and it will result in less code to write, I guess 
everyone would be happy.


Bye,
Matthias.




More information about the KDevelop-devel mailing list