kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 3/12/2019 2:27 PM, Seth Hillbrand wrote:
> Am 2019-03-12 13:49, schrieb Wayne Stambaugh:
>> Hey Seth,
>>
>> On 3/11/2019 6:12 PM, Seth Hillbrand wrote:
>>> Why make new plugin registry that is different from the plugin registry
>>> that is used in pcbnew?  And if we do need a new version for schematic
>>> type plugins, can we unify them to avoid having to debug/maintain two
>>> different code bases that serve approximately the same purpose?  For
>>> reference, I am referring to pcbnew/io_mgr.cpp
>>>
>>> -S
>>
>> I don't think this is possible until all of the source files that are
>> compiled multiple times on a per "application" basis are factored out.
>> The units are the primary issue but there may be other lurking in there
>> as well.  Any unified I/O manager will have to be able to manage board
>> and schematic units in a common shared library.
> 
> Hi Wayne-
> 
> I was only referring to the plugin registry mechanism.  IO_MGR has it
> but SCH_IO_MGR does not.  Since they do the exact same thing, having
> them live in common seems to make sense (not the file loading, just the
> plugin registry).
> 
> In io_mgr.cpp, the 6 static lines at the bottom would stay in the pcbnew
> directory (probably in files.cpp).  The rest could move to common where
> eeschema could use the class to register its file types instead of using
> the separate sch_io_mgr.
> 
> If you prefer to wait before unifying them, I'd still like Brian to
> avoid making a new paradigm for registering plugins.  He could instead
> make a copy of PLUGIN_REGISTRY from io_mgr.h and paste it into
> sch_io_mgr.h and use that.  Either of these options sound viable?
> 
> -S

Using the existing PLUGIN_REGISTRY for SCH_PLUGINs makes a lot more
sense than creating a new paradigm.  I'm assuming your going to create
separate SCH_PLUGIN variant of the registry because the PLUGIN_REGISTRY
creates a PLUGIN object which will not be compatible with the
SCH_PLUGIN.  Ideally you would factor out the common code of IO_MGR and
SCH_IO_MGR and PLUGIN and SCH_PLUGIN to create a common base object and
then create the SCH and PCB derivations of PLUGIN and PLUGIN_REGISTRY.

I still have to finish reviewing the original patch so please do not
merge it.  For the few simple changes required to access the symbol
library parser and formatter that Brian requested, it seems like an
excessively large change set.

Wayne