kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 12/7/2013 8:56 AM, Povilas Kanapickas wrote:
> On 12/07/2013 03:19 PM, Wayne Stambaugh wrote:
>> On 12/7/2013 2:45 AM, Povilas Kanapickas wrote:
>>> I've already got a reply off-list that equivalent functionality is
>>> already developed (I couldn't find any discussions on the list until now
>>> unfortunately). It thus makes sense to scrap the proposal. Perhaps I can
>>> help whoever is working on the new library file format?
>>>
>>> Regards,
>>> Povilas
>>>
>>
>> This work is already complete and is about to become the default
>> setting.  Hopefully this will happen today.  I'm just waiting to hear
>> back from JP.  There is really no coding left to be done other than
>> fixing any remaining issues.  You can test this code by building KiCad
>> with the CMake flag -DUSE_FP_LIB_TABLE=ON.  Even better, also set
>> -DBUILD_GITHUB_PLUGIN=ON to enable the GitHub plugin.  Then you will
>> really appreciate the full potential of the new footprint library file
>> format.  The documentation for the GitHub plugin is currently only
>> available in the developer documentation (I'm currently working on
>> adding it to the user documentation as well) by running `make
>> doxygen-docs`.  Look at the GITHUB_PLUGIN class documentation for
>> information on configuring the GitHub plugin.
>>
>> Wayne
>>
>>
> 
> I'm fully aware that footprint libraries are already restructured :-) My
> proposal was about for the symbol libraries, i.e. those defined in *.lib
> files. AFAIK there's no alternative format for them yet, though I was
> told in an off-list email that some work is being done.
> 
> Regards,
> Povilas

A document has already been written for the new schematic and component
library file formats (known as sweet) and the preliminary sweet code was
written by Dick and lives in the new folder in the KiCad source tree.
However, the integration of sweet and the new schematic file format will
not happen without serious surgery to Eeschema (there is some concerns
that it will be a complete rewrite of Eeschema) because the decision was
made to make schematics unitless and the method of accessing external
objects must be fixed to support sweet component libraries as well as
other schematic objects such as sheets.  There still has to be some
discussion on the subject of externally (and possibly internally) bound
objects before this can move forward.  It is not a simple matter of
changing the file formats.  Otherwise, it would have been done already.
 Pcbnew did not suffer from this complete design change philosophy, that
is why it got the new file format treatment first.

> 
> P.S. Just out of interest, could someone give a two sentence overview
> over why custom, non XML/JSON/etc. format has been chosen for various
> serializers in KiCad? I've tried to search in the email archives but the
> decision and arguments for it seem to be burried sufficiently deep
> enough :-)
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>