← Back to team overview

kicad-developers team mailing list archive

Re: Future plans on the KiCad library releases?

 

Hi Wayne,

> This is not a trivial issue to fix.  I'm not sure there is a good answer
> for this issue.
It's certainly not trivial, but I believe a fix would not be terribly
hard either.

Let me repeat my original proposal here:

> I can imagine that KiCad either gets a way to:
>  1) include all libraries in a given directory (e.g.
>     /usr/share/kicad/something). This should be re-evaluated whenever
>     KiCad starts up, so there should be an explicit
>     "/usr/share/kicad/library/*.lib" entry in the table (or something
>     like that), as opposed to actually putting each library in the table
>     individually, or
>  2) include a secondary library table from the normal one. Then any kicad
>     library package can ship such a secondary library table, and update
>     it to reflect the new list of libraries.
>
> I think these would apply to both symbols and footprints equally. Option
> 2) seems more elegant and flexible to me. Both options should be able to
> provide pretty seamless library upgrades for users (and can even be
> extended to third party library collections, or a user's own libraries).

So far, you've only responded to this proposal itself by saying you
don't want KiCad to decide what libraries to load, but, as I already
pointed out in a previous reply, both of these options would be opt-in
through an entry in the global library table (or something similar).

The above proposal only makes sure that the library list gets upgraded,
not the actual schematics that point to any symbols that are now moved
into another library.

I think upgrading the library list is the most important, since (in the
eyes of users) it is a fairly trivial change (in terms of what needs to
happen, not necessarily in terms of implementation) that is annoying to
do every time (remove all libraries and re-add all libraries, or compare
the list of libraries to the files to see if anything changes).

Automatically updating existing schematics when one of its symbols moved
to a different library would of course be awesome if that could happen
as well. I also made a suggestion about that:

> One way I can imagine this works is to also include a "rename"
> specification (perhaps similar to the current rename.json), which can be
> used by KiCad to automatically migrate older symbol references. Or
> perhaps the rescue dialog can be improved to look among other libraries
> for a symbol with the same name and let the user choose between
> relinking to such a symbol, or resueing one from the cache.

Gr.

Matthijs

Attachment: signature.asc
Description: PGP signature


Follow ups

References