[PATCH] kcmoduleinfo [WAS] Plugin linking problem

[Rafael Fernández López]

> Anyway, by deriving from a KCModuleFactory type of class it could look like
> this:

In the best case I'd check not the name of the desktop file (well
that's just a detail of implementation, nothing important), but the
Type [KCModule, Plugin]...

Sure it can work, but for me it sounds a bit "disorganized". Probably
is cleaner and less error-prone having a factory per class, and more
than one factory per library, than having a factory per library, and a
factory for more than one class.

> The reason why I like to have one factory instead of many is that IMHO it's
> more transparent what's happening, or perhaps you can ignore the details of
> how the entry symbol is constructed: no need to know about X-KDE-FactoryName
> and you can use Q_EXPORT_PLUGIN2.

On the other hand, yeah it would be nice using Q_EXPORT_PLUGIN2.

> Also with this approach the number of classes that can be instantiated is
> variable which is what is needed for implementing plugins using scripting
> languages without having to implement a C++ factory for every single
> plugin...

Creating a factory is harmless. You only need to write 1-line-of-code
for each service (the macro magic line).


Bye,
Rafael Fernández López.