kicad-developers team mailing list archive
Mailing list archive
Re: RFC: Unified Plugin Registry
On 3/19/2019 2:41 PM, Brian wrote:
> 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
It might not be a bad idea for derived plugins to specify if they
implement a feature or not, i.e. it should be possible to query the
schematic plugin to find out if schematic read/write and/or symbol
library read/write are implemented. Currently this defaults to raising
> - 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
You may want to check the library table edit dialogs in pcbnew and
eeschema. I think the ordinal (enum) number is used when selecting the
library type for the table row so you may have to provide some type of
plugin lookup strategy to replace this in the UI control.
> 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.
Static is fine. A singleton would work here as well.
> 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.
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp