kicad-developers team mailing list archive

[Brian <lotharyx@xxxxxxxxx>]

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?

===Background===
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.
Cheers,
-Brian Henning
https://github.com/lotharyx