kicad-developers team mailing list archive

[Brian <lotharyx@xxxxxxxxx>]

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 
collection.

- 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 
necessary).

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.

Cheers,
-Brian