kicad-developers team mailing list archive
Mailing list archive
RFC: Unified Plugin Registry
Fellow KiCad developers,
A little while ago the topic of unifying the IO plugin mechanism came
up. I mentioned I'd be happy to work on that, and to that end, I'd like
to open up discussion on a few design ideas I have.
- Unifying abstract base class, IO_PLUGIN (or simply PLUGIN)
This interface would only expose very generic query methods (e.g. what's
your name, what kind of plugin are you, can you read this file). All
plugin types would inherit from it, in order to be stored together in a
- An enum defining plugin type
I think there might be only two values to start with, SCHEMATIC_PLUGIN
or BOARD_PLUGIN (or some such), and would indicate to what specific type
of plugin any given ABC pointer could be safely cast. If other sorts of
plugins get rolled into the registry, this enum could be expanded.
- Primary key of string instead of enum
At present, the plugins for both schematic and board plugins have their
own enums for identifying each plugin. I propose a shift to using
strings as the primary key, and allow the registry to assign ephemeral
integer keys at run-time (if such integer keys are even needed). I
think this is a useful step toward supporting DSO/DLL plugins in the
future (a DSO/DLL writer need not modify KiCad source, merely pick a
unique string, which the registry could even automatically de-collide if
This registry class would present a static interface by which plugins
could be enumerated by type, found by name, filename, etc., building on
the design presently implemented by pcbnew's IO_MGR.
I'm eager to get input from members of the core group of developers and
reach a consensus on a design I can start implementing.