← Back to team overview

kicad-developers team mailing list archive

On EESCHEMA symbol library plugins


Hello everyone,

tl;dr - hi, I'm new here and I'd like to suggest a couple small changes to make maintaining my private fork a little easier. Presuming I can present a concise patch that adheres to the coding standard, what's the right way to propose it?

I've been maintaining my own private fork of KiCad for a few years now, but only just now joined the developer list because I've just had to do a major rework on my fork due to large upstream changes (the reason this has only just now occurred is its own long story) in the area of EESCHEMA symbol library structure.

My fork exists to add the ability to use an RDBMS (e.g. MySQL) via ODBC as the backing store for symbol and footprint libraries.  I've done this because I maintain a parts inventory database in MySQL and having symbols / footprints tied to parts I actually have is a useful correlation.  Inside the database, symbols are serialized in the legacy EESCHEMA format.

At any rate, as one might guess, it's been a distinctly nontrivial endeavor, since the latest upstream code has rearranged the way symbol libraries are organized.  That's okay, I slogged through it and put it into the right shape to work in the new paradigm.  But along the way...

===Suggested Upstream Changes===
1. The current upstream code that "speaks" the old EESCHEMA symbol format is buried inside SCH_LEGACY_PLUGIN_CACHE.  In my fork, I have extracted it to its own class so that my plugin can make use of it, and that extraction uses base LINE_READER and OUTPUTFORMATTER in its interface so the caller has the freedom to use something other than a file. 2. There are a few places in upstream code where a plugin type of SCH_LEGACY is assumed, rather than asking SCH_IO_MGR what it actually should be (presumably because in upstream, there is only one plugin type).  I changed those to use SCH_IO_MGR's methods to actually get the correct plugin type.

On a slightly longer view, it might be nice if SCH_IO_MGR maintained a static registry of file extensions and plugins that other pieces (e.g. the library file browser) can use; for now, I use a different header inside a file named <something>.lib so that I don't need to touch the file browser filters.

My code isn't ready for prime-time, in no small part because it is unique to my particular database strategy and probably isn't useful to anyone else.  But it would be a significant advantage for my future maintenance efforts if these two changes made it into upstream.

This e-mail was wordy.  Thanks for reading it.
-Brian Henning

Follow ups