kicad-developers team mailing list archive

[Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx>]

Sorry the link to the symbol library format doesn’t seem to work.

Can you supply a link which works and maybe a link to the PCB file format? I’ve been dying to know ... 

From: Wayne Stambaugh
Sent: November 9, 2019 3:42 PM
To: kicad-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Kicad-developers] Symbol library code changes

Hi Brian,

On 11/7/2019 3:39 PM, Brian wrote:
> From the peanut gallery:
> I know 6.0 symbol library handling has many significant differences
> versus 5.x.  Eventually, if I want to keep myself at or near the
> bleeding edge, I'll have to port my ODBC stuff to the 6.0 way of doing
> things.  A couple questions:
> 
> 1. Is there any documentation of the design, or is my best bet just
> studying the code?

The symbol library file format document can be found at
https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit.
 The comment period is closed so please do not add any comments to the
documentation unless you find an error.  This is subject to change
during development but I will do my best to keep the file format
document up to date.  The schematic file format is still being finalized
so I will make a request for comment when I'm ready to make that public.

> 2. I guess there will be some means for converting a 5.x symbol library
> to 6.0, yes?  Regardless of the actual storage mechanism (filesystem,
> ODBC, TCP over carrier pigeon), the format is just different (I remember
> something about switching to S-code), so there'll have to be some way to
> convert from the older SCH/LIB format to S-code, right?

You will convert them the same way you do (did) with the legacy
footprint library files, just save to a new library and it will
automatically be converted to the new format.  Initially you will be
able to save as both formats so I can round-robin test between the two
formats.  Once the new symbol library file format feature compatible and
correct with the legacy format, writing legacy symbol library files will
be deprecated.

Cheers,

Wayne

> 
> Thanks,
> -Brian Henning
> 
> 
> On 11/7/19 2:30 PM, Wayne Stambaugh wrote:
>> Hey Seth,
>>
>> On 11/7/19 12:22 PM, Seth Hillbrand wrote:
>>> On 2019-11-06 12:34, Wayne Stambaugh wrote:
>>>> I finally finish up the initial attempt at simple inheritance for the
>>>> symbol library code.  The change is non-trivial and will likely have
>>>> some unexpected side affects that I missed.  I pushed the branch to my
>>>> personal repo[1] and I would like a few pair of extra eyes on it before
>>>> I merge it into master.  If you prefer, I can set up a merge request
>>>> from this branch in Launchpad.
>>>>
>>>> The biggest user facing change is that the concept of aliases is gone
>>>> which means internally, the LIB_ALIAS object has been removed and
>>>> all of
>>>> the information it managed was moved into LIB_PART.  This actually
>>>> simplified some of the UI code but made the LIB_MANAGER and LIB_PART
>>>> object code more complicated.  The symbol library editor works
>>>> significantly different now.  When you select a derived part
>>>> (formerly a
>>>> LIB_ALIAS), it will show the parent symbol that it was derived from
>>>> darkened and all of the edit features disabled.  Until the new symbol
>>>> file format is done and writing to the legacy symbol file format is
>>>> deprecated, this restriction will have to remain in place.  The
>>>> properties editor no longer has an aliases panel and is limited to what
>>>> it can change in the derived or parent symbols depending on which
>>>> symbol
>>>> is currently being edited.  I suspect this will be the biggest
>>>> stumbling
>>>> block for existing users so if you can think of a better way to handle
>>>> this, I'm open to suggestion.  The other thing that I am concerned
>>>> about
>>>> is symbol library editing.  There were a lot of LIB_MANAGER object
>>>> changes which I am not 100% confident in.
>>>>
>>>> Just a couple of other internal changes to be aware of:
>>>>
>>>> A flattened copy of the symbol is used in SCH_COMPONENT instead of
>>>> relying on the weak reference to the library symbol.  This way we don't
>>>> have to worry about the shared pointer disappearing and causing issues.
>>>> However, this will require that we be diligent about updating modified
>>>> symbol libraries in the schematic.  Otherwise, the schematic could
>>>> change the next time it is loaded.  I'm open to changing this back
>>>> if we
>>>> think it's going to be an issue.
>>>>
>>>> There is now a compare function for the LIB_PART object which can be
>>>> rather tricky.  I created a new test suite inside the current LIB_PART
>>>> test file so if you change anything, please run the test to ensure
>>>> nothing gets broken.  I also added a bunch of other new tests for the
>>>> LIB_PART object.
>>>>
>>>> I added code to DIALOG_SHIM to allow the caller to reset the last
>>>> dialog
>>>> size when hiding dialog control state changes between dialog instances.
>>>> We have some dialog windows that are not the correct default size
>>>> depending on which controls are shown so there is now a convenient way
>>>> to address this.
>>>>
>>>> Please let me know if you find anything so I can get it fixed and
>>>> merged
>>>> into master.  The next step is to convert the schematic internal units
>>>> from 1mil to 10nm.  Once that step is complete, I will knock out the
>>>> new
>>>> symbol library format.  Thanks in advance for the help.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> [1]:https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/lib-alias-merge
>>>>
>>>>
>>>>
>>> Hi Wayne-
>>>
>>> I'm psyched to see this progress!  Congrats.  I'll have a chance to
>>> fully test after next week but I wanted to get you the code read
>>> feedback before then.
>>>
>>> 1) Compare function:
>>> - It looks like rhs isn't checked for end() in the loop.  While size
>>> gets checked ahead of time, we've had a couple cases where code gets
>>> added between checks and loops in the past, so it's probably safer to
>>> put the check in the loop.
>>> - Same with the footprint check.  Ideally, these would be the same style
>>> (iterators vs. dereference) but that's minor
>>> - Do we expect these containers to remain sorted?
>> I'm not sure thats strictly necessary but I will take a look at it.
>>
>>> 2) You have a few C-style casts in Flatten()>
>>> 3) The LIB_PART() copy constructor should take a const reference rather
>>> than the existing one, that should remove the requirement of using
>>> const_cast in Flatten()
>> Gaaa!  How did I miss that?
>>
>>> 4) That ternary in GetNextDrawItem() is breaking my brain a bit.
>> This will only get worse with multiple inheritance.  Draw items from
>> each parent will have to be recused to create a final image of the
>> symbol.
>>
>>> 5) In footprint_info.h, if we are returning the wxString itself (instead
>>> of the reference), it shouldn't be const.  (addendum: Also
>>> loadAliases())
>> Missed another one.
>>
>>> 6) sch_view.cpp has a couple c-style casts that can probably be
>>> compressed into our dyn_cast routine.
>>>
>>> 7) DeleteSymbol mixes up it and it1 in the while() loop.
>> I'll take a look at it.
>>
>>> I can't wait to test it out!  On the usability issue for aliases, I
>>> suspect that this is a time limited constraint, so there shouldn't be
>>> large issues as people should not be building aliased libraries with the
>>> master branch at this point.  We may want to clarify that in a list
>>> message.  Overall, I am very excited for the new formats.  Thanks again
>>> for taking on this huge job!
>> Thanks for the review, I should have most of the issues above fixed by
>> in the next day or so.  There are lot more big changes coming.  I
>> desperately want to have the new file formats in place by FOSDEM.
>>
>> Cheers,
>>
>> Wayne
>>
>>> Best-
>>> Seth
>>>
>>> Seth Hillbrand
>>> KiCad Services Corporation
>>> https://www.kipro-pcb.com
>>> +1 530 302 5483 | +1 212 603 9372
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> 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

_______________________________________________
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