kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Hi Brian,

I don't have any immediate comments on your technical suggestions, but I do
want to say that having a database-backed library is a very nice feature to
have and it's been on my idea list for a while (I miss this feature from
commercial software).  So I did want to say that your idea is likely useful
to lots of people even if you say your code is not useful to anyone else.
I would encourage you to think about getting the whole feature to the point
where you'd feel OK about proposing it to merge into mainline KiCad.  While
I don't have time in the short term to help with this, I would be happy to
work with you on it in the long term if that would be useful (code review,
testing, etc).

If you prepare a patch, the right way to propose it is to just attach it to
an email to this list, with some explanation.

Best,
Jon

On Mon, Mar 11, 2019 at 9:59 AM Brian <lotharyx@xxxxxxxxx> wrote:

> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>