No, not really. You can have inline methods. And others as well but then you need to link the plugin against the implementation of the interface which defeats the purpose of calling it an interface.
Are you sure about that since the docs say something else:
Making an application extensible through plugins involves the following steps:

1. Define a set of interfaces (classes with only pure virtual functions) used to talk to the plugins.
2. Use the Q_DECLARE_INTERFACE() macro to tell Qt's meta-object system about the interface.
3. Use QPluginLoader in the application to load the plugins.
4. Use qobject_cast() to test whether a plugin implements a given interface.
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.

You can do that, that's ok. Recently I'm leaning more and more towards the design Qt Creator has - with a dumb plugin infrastructure, clever plugins and linking plugins to plugins (as in dynamic linking). Then it's just a matter of exposing proper interfaces by the plugins and you can build whatever application you want on top of it by changing the set of plugins that get loaded into the app. If you want plugins for one specific thing though, it'd certainly be an overkill.
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" ;-)
But in truth, its also a kind of exercise for me - this is a private project, so I can take the time to play with overkill designs ;-)
Even though, I am not sure its an overl kill, since any other way seems just wrong.
This way I will have my logger, and it will always do its job (with out the need to change it), and yet, it will be expandable to new formats if such will come in the future.

Thanks for helping me jugging this in my head!