Hi Andre, I think it would be best to have two different discussions here, first about the idea and concept, and second about your proposed implementation. I wanted to lead with this because I think there is a tendency in discussions to mix the two together unnecessarily.
This is a real need and something that we've already started working on related things for, although in a slightly different direction than you describe. There are two different but related concepts here: 1) Storing part metadata in a private database -- I have started working on this feature (#7436 <https://gitlab.com/kicad/code/kicad/-/issues/7436>). The scope of this one is that the database is SQL-like and ODBC-compatible. 2) Retrieving live part metadata from a public data source (Mouser/Digi-Key/Octopart/JLC/etc) and applying it to already-placed symbols (or newly-placed). (1) can obviously be built into KiCad and so it will be. (2) is more challenging -- most of these data providers would be unhappy with KiCad providing an easy way for users to scrape their data, as it could cost them a lot of money. There have been discussions with various data vendors about an integration approach, but in general this is something that needs to be negotiated per-vendor. Because of this, I agree that the right approach is to build a framework rather than an implementation, which leaves e.g. Digi-Key open to providing their own KiCad data plugin if they wish to make their data available to KiCad users in this way. This leads me to the implementation -- I'm not sure that creating a new binary plugin interface is the approach we should take for this. We have been investing in the Python plugin ecosystem elsewhere, and this seems like an ideal fit for Python: people creating datasource plugins can distribute a single plugin that runs on any platform KiCad is supported in, and there are fewer stability and security concerns with loading an arbitrary Python plugin than with an arbitrary compiled binary. For the workflow you describe: this makes sense in the use-case of adding metadata from an external source to parts that were already placed. The Database Libraries workflow will be oriented more about placing symbols with all their metadata from the start. Perhaps it would be possible to have this proposed metadata plugins interface work either at initial placement or afterwards? Best, -Jon On Mon, Jul 18, 2022 at 6:53 PM Andre Iwers <iwer...@gmail.com> wrote: > Hi There! > > I constantly run into issues where I need to add all sorts of metadata to > my sometimes 100+ parts schematics which are saved in an external > inventory system. Initially doing it by hand I grew tired of it and decided > to whip up a slightly less laborious way using a plugin approach which is > quite flexible in terms of datasources. Also updating those is even worse. > > I was interested if this is something Kicad would be interested in taking > over for the broader public. I hooked it into the 'Symbol Properties' or > 'Symbol Fields Table' dialog for ease of use and touched that existing code > only marginally. > > <https://mail.google.com/mail/u/1/#m_-4237403401938012105_expected-behavior>Quick > Overview: > > When I have selected a schematic symbol from the standard library, I'd > like to be able to open the 'Symbol Properties' or 'Symbol Fields Table' to > fetch part information from an external source. > > Idea: Eeschema would simply provide a framework which connects to one or > more plugins and the plugins themselves would be provided by the community > as .dll or .so which then are saved somewhere on the computer and simply > loaded when needed. The plugin can be programmed in any language such as > python, java, c# etc. and would only need to honour the defined C wrapper > interface. Plugins which don't adhere to that are simply ignored. > > I have created a first draft of that framework to solve a laborious task I > face once in a while and am wondering if this is something that is > generally useful for the broader public. I also programmed a plugin for > Inventree which is used here as part database. > > In general: the framework is intended to use multiple plugins at the same > time so that a user could potentially query for example Mouser, Digikey, > Navision and Inventree at the same time. > <https://mail.google.com/mail/u/1/#m_-4237403401938012105_the-workflow>The > workflow: > <https://mail.google.com/mail/u/1/#m_-4237403401938012105_a-brand-new-project-would-be-to>A > brand new project would be to: > > - select a symbol from the standard kicad library > - open plugin search and search for the specific part > - transfer all metadata automatically into your schematic > > <https://mail.google.com/mail/u/1/#m_-4237403401938012105_existing-project>Existing > project: > > - Open fields editor and bulk apply metadata using the above mentioned > approach. > > -- > You received this message because you are subscribed to the Google Groups > "KiCad Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to devlist+unsubscr...@kicad.org. > To view this discussion on the web visit > https://groups.google.com/a/kicad.org/d/msgid/devlist/CABQVKmKZAQtXZ-gdQOJiHGH_vJmwfU5Ho%3DCAaMtM_YD2PbZteQ%40mail.gmail.com > <https://groups.google.com/a/kicad.org/d/msgid/devlist/CABQVKmKZAQtXZ-gdQOJiHGH_vJmwfU5Ho%3DCAaMtM_YD2PbZteQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "KiCad Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to devlist+unsubscr...@kicad.org. To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCBOVz_8CJLG5spNgg%3D%3D6RF4s390abE_LW8wQeeE5-A%3DdQ%40mail.gmail.com.
