[Kst] New way to build plugins ?

[Adam Treat]

On Friday 11 May 2007, Brisset, Nicolas wrote:
> Hi,
>
> a colleague jsut came up to me and asked about plugins... When I fired
> up my editor to show him how simple it was (I was still thinking about
> the .xml / .c(pp) times) I saw something much more complicated than the
> old C style plugins. Sure, it is still feasible but:
> 1) the docs in devel-docs are outdated

I've updated them a bit now, but please let me know if you see any more 
shortcomings...

> 2) while a lot of people know enough C to write a small algorithm for a
> plugin, far less know enough C++ to understand what to do here

Well, the good thing is that for the most part they'll only need to know 
enough to implement one method:

	virtual bool algorithm();

It is true they are going to need to know enough C++ to navigate around how to 
use KstVectorPtr for instance, but I don't see any way around that.

> 3) it used to be possible to write plugins without having a KDE/kst
> installation and pulling development headers (now at least
> kgenericfactory.h is required)

Again, I think this is necessary.  You are building a plugin that is loaded 
via a KDE subsystem and therefore KDE's (and Qt's) headers are necessary.

> 4) a .moc file is autogenerated but for people not familiar with Qt/KDE
> development that may look like black magic, and they will most likely
> give up, at least without clear and up-to-date explanations

For now I've gone ahead and pointed to the relevant docs on trolltech.com.
Truth be told, the majority of the plugins are not going to require 
signals/slots, but I think KDE's plugin loading system needs these to have
the Q_OBJECT macro which implies moc.

> 5) memory allocation is done via calls to resize() which wasn't the case
> before and there may be other important differences worth mentioning

The best way to see how this is done is to look at the existing plugins.  The 
same was true for the C plugins from what I understand.

> 6) I am not sure it is still possible to build C-style plugins or
> out-of-source-tree plugins

It is still possible, but this is deprecated.

> Having been a very active supporter of the move to the new plugin
> architecture (for the custom dialogs possibility it offers) I won't
> complain too much now, but I think a few words of explanation on how to
> build a custom plugin would be good. 

Unfortunately, the move to real C++ plugins requires the need for plugin 
developers to have some C++ knowledge.  It also becomes necessary to use 
autoconf/automake tools (at least for KDE3.x).  I've tried to minimize the 
complications and it seems straightforward to me, but then I have more 
experience with these tools then perhaps the average plugin developer.  
Anything we can do to simplify this would be good so if you have any 
suggestions, please let me know.

Thanks,

Adam