kicad-developers team mailing list archive

[Brian <lotharyx@xxxxxxxxx>]

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!
-Brian

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.
>
> Cheers!
> -Brian