kicad-developers team mailing list archive
Mailing list archive
On EESCHEMA symbol library plugins
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
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.