kicad-developers team mailing list archive
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
-- 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
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:
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