Quote Originally Posted by high_flyer View Post
Are you sure about that since the docs say something else:
Yes, I'm sure. The part in brackets expands the definition of an interface not the C++ requirements for using such an architecture. Since the concept of interface doesn't exist in C++ it is emulated by the use of pure abstract classes with only pure virtual methods in them but nobody says it will suddenly stop working if you implement some of the methods.

Ok, I guess inline would work - and which was the base of my problem - implementing requires linking, which makes one plugin dependent on another, which to me is a principal (definition) conflict.
Not with inline methods. They don't require linking as they are inlined in the code fragment that calls the method not the one that defines it.

Yes this may be an overkill - but watch out that nroberts wont blow you away with "small project is no excuse to non proper design" ;-)
It's by no means improper. It's just simpler. Creator's plugin infrastructure is quite complicated with an object pool (which is really not very proper when talking about C++ principles), plugin dependency resolving, versioning and stuff like that. You don't need it if all you want is to have a single interface exposing two methods.

Even though, I am not sure its an overl kill, since any other way seems just wrong.
Then maybe I didn't explain it clear enough. Creator doesn't use a plain QPluginLoader approach, it builds upon it. You don't need the extra part unless you want your plugins to do something more than just implement one interface. Plain QPluginLoader approach is about "pulling" functionality from plugins (which are dumb) to the main app, Creator works the other way round - the plugins (which are aware of what the main app exposes) "push" functionality to the mainstream.