← Back to team overview

kicad-developers team mailing list archive

Re: Why we chose to put libraries in directories?

 

Hi,

On 28.01.19 18:22, Tomasz Wlostowski wrote:

> I'm asking because despite our efforts to improve Kicad's UX, the
> library configuration is still quite difficult, even for experienced PCB
> designers who are switching to KiCad from proprietary tools (see recent
> posts on the Kicad Forum). I'd like to improve this during the V6
> development cycle.

Radical proposal:

 - symbols and footprints are stored in content-addressable repositories
similar to git's objects directory
 - schematics and boards reference library items by their checksum
 - any part that is used is copied to the project
 - modifying a part creates a new object that contains a note that it
supersedes the old one
 - parts are saved into the user home directory or (if configured) an
organization wide shared folder
 - the entire library path is scanned for parts, and the results merged
to a common view

This would solve a number of problems:

 - projects always have copies of the parts that were used, without
needing to copy them into the design files
 - we can detect when projects use parts that have been modified since,
and allow the user to upgrade if they like (but they can defer
indefinitely without risk)
 - path configuration is reduced to "where the system library is"
(handled by distro) and "where the company library is" (optional)
 - libraries can always be written to

The actual directory layout of the library directories does not really
matter, so we could also allow zip files, add directory indexes or do
some neat stuff with indexed extended file attributes (which ext4, NTFS
and HFS all offer) through plugins without the main program having to
care about that.

The "supersedes" mechanism will need some more thought, as we probably
don't want to keep all intermediate versions, but we need to know their
checksums in case we encounter them -- maybe a file that lists
relationships between parts that have been removed could be sufficient.

   Simon

Attachment: signature.asc
Description: OpenPGP digital signature


References