← Back to team overview

kicad-developers team mailing list archive

Re: Future plans on the KiCad library releases?

 

On 1/23/2018 12:18 PM, Matthijs Kooijman wrote:
> 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.

If someone comes up with a reasonable patch for this, I'm not opposed to
it.  Obviously it wont happen until v6.

> 
> Gr.
> 
> Matthijs
> 


References