Plugin design advice needed

[d_stranz]

If you are going to always load a plugin into the program (simply because it requires its functionality to work) then it is easier (development wise) to make it a library.

I think I agree with this, although QtCreator has adopted the approach of putting all the required bits into the Core module, which is a mandatory plugin. The QtCreator executable is little more than a plugin loader and manager, with Core the first (and required) plugin loaded. So I suppose if you wanted a reusable plugin-based framework where any kind of functionality could be provided by a Core-like required plugin, this would be a way to do it. I don't know if I need to be so generic, so I will probably move the basic functionality into the main program.

Eventually everything depended (=mandatory dependency) on everything else

That's another worry, but I think by careful segregation of functionality into a set of well-defined plugins, I can hopefully avoid this.

We also had another application system that was modeled after QtCreator -- i.e. it was composed of many small plugins that "pushed" functionality into a common pool of objects that other plugins (which those initial ones depended on) could pull from the pool throughout a known interface and use.

Yes, I like the "object pool" concept. I might get some significant advantage out of the pool and the objects in it signalling that they have been modified, and letting plugins decide if they are interested. This means creating QObject wrappers for my pure C++ computational classes, but that is not hard; more difficult is that many of my collections of object instances are based around boost smart pointers so management of wrapped object lifetimes will be a problem to be solved, probably by creating QObject smart pointers and eliminating QObject parent-child relations. (Or by designing collections such that the objects within them do not need to be wrapped).

The bright side was that adding new functionality was in total separation of existing functionality.

This is the hope, isn't it?

[wysota]

QtCreator has adopted the approach of putting all the required bits into the Core module, which is a mandatory plugin.

The Core plugin is different. It is being loaded by name before other plugins are loaded. It might have been a library instead.

That's another worry, but I think by careful segregation of functionality into a set of well-defined plugins, I can hopefully avoid this.

Sharing my experience (I wasn't responsible for this terrible architecture, nevertheless I couldn't find a way to untie this Gordian Knot without totally rewriting the system) I strongly advise you to decide apriori which functionality goes where and what depends on what and then stick to what you designed. Splitting or merging as you go will lead you exactly where we landed.

This is the hope, isn't it?

Well... it depends. My problem was that I was the only one fully understanding the plugin architecture so I was being asked a lot of questions how to do things with it.

[d_stranz]

I strongly advise you to decide apriori which functionality goes where and what depends on what

I typically do this; by the time I get to actually writing code it almost writes itself, it has been so thoroughly planned out. This helps me later, because I know exactly where everything is and which parts depend on something else when changes must be made. But it frustrates the people who keep asking, "When can you show me something?"

and then stick to what you designed.

And that's the hard part. Fortunately most of my efforts are one-person projects, so it is a bit easier to enforce my own design rules.