← Back to team overview

kicad-developers team mailing list archive

Re: Patch: Legacy symbol read/write extraction; SCH_PLUGIN registry mechanism


My apologies; I realize I didn't do a very good job of describing my changes.  So:

-- Legacy read/write extraction:

This one's rather straight-forward.  I pretty much just yanked all the code from SCH_LEGACY_PLUGIN_CACHE specific to parsing / writing legacy symbol format and stuffed it into two static classes called LEGACY_PART_READER and LEGACY_PART_WRITER, found in legacy_part_serializer.h/cpp.  SCH_LEGACY_PLUGIN_CACHE now calls the static methods on those classes instead of having the code inside itself.

-- Registry mechanism

This one's a bit more involved and I welcome comment and discussion.

Refer to eeschema/sch_io_plugin_registry.h/cpp.

A new class called SCH_IO_PLUGIN_REGISTRY is a singleton which maintains a few indices of plugins.  In order to register plugins, each plugin class now exposes a static method called "create" which returns the base type SCH_PLUGIN *.  A pointer to this static method is provided to one of a few helper classes which lead to index entries created for the file extension and a string name.

When a plugin is registered, the registry assigns it an ID number. This ID number replaces the SCH_IO_MGR::SCH_FILE_T enumeration. When a plugin is needed, the registry can be searched by name or extension, and has additional methods which expose the ID number for those places in the code that expected an integral value (for example, the symbol library table).

All of SCH_IO_MGR's plugin-finding methods (FindPlugin, EnumFromStr, etc) are now pass-throughs to methods on SCH_IO_PLUGIN_REGISTRY.

One area that does cause some concern for me is the conflation of libraries vs schematics.  I understand the reasoning, but it presents opportunities for extra complication when the same "plugin" handles reading both an entire schematic (with embedded symbols) and a library.  For now, SCH_IO_PLUGIN_REGISTRY addresses this by allowing the same plugin type to be registered for multiple file extensions.

A related area of concern is the collision of KiCad and EAGLE's schematic file extensions.  It isn't possible to differentiate them without looking inside, meaning that blindly passing the file extension to the registry to find the right plugin wouldn't work. Reading EAGLE schematics is pretty well encapsulated, though, so maybe it's fine to take a less-generic approach in that circumstance (e.g. we know it's EAGLE so use EAGLE plugin, rather than "finding" a plugin for ".sch").

Anyway, there's the description.  Cheers!

On 3/11/19 5:31 PM, Brian wrote:
Hello everyone,

Thank you for the kind, informative, and speedy responses to my previous message about schematic library code.

Attached please find a gzipped patch generated by `git format-patch` for initial review and comment at your ("y'all's") leisure.  This patch both extracts legacy symbol serialization into a complementary pair of classes, and implements a plugin registry mechanism that handles things like telling the file browser a set of filters (in addition to providing the means of finding plugins by extension, type name, or numeric ID).

I look forward to feedback.  I know there are some places that I felt a little dirty about, and welcome the opportunity to discuss them whenever a responsible party (e.g. the upstream author, maybe) has some time.


Follow ups