kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #33423
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
-
Re: Future plans on the KiCad library releases?
From: Rene Pöschl, 2018-01-15
-
Re: Future plans on the KiCad library releases?
From: Matthijs Kooijman, 2018-01-15
-
Re: Future plans on the KiCad library releases?
From: Wayne Stambaugh, 2018-01-15
-
Re: Future plans on the KiCad library releases?
From: Matthijs Kooijman, 2018-01-17
-
Re: Future plans on the KiCad library releases?
From: Chris Pavlina, 2018-01-17
-
Re: Future plans on the KiCad library releases?
From: Wayne Stambaugh, 2018-01-17
-
Re: Future plans on the KiCad library releases?
From: Matthijs Kooijman, 2018-01-23
-
Re: Future plans on the KiCad library releases?
From: Wayne Stambaugh, 2018-01-23
-
Re: Future plans on the KiCad library releases?
From: Matthijs Kooijman, 2018-01-23
-
Re: Future plans on the KiCad library releases?
From: Wayne Stambaugh, 2018-01-23
-
Re: Future plans on the KiCad library releases?
From: Matthijs Kooijman, 2018-01-23