kicad-developers team mailing list archive
Mailing list archive
Re: Symbol library code changes
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 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
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
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
is currently being edited. I suspect this will be the biggest
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
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
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
I added code to DIALOG_SHIM to allow the caller to reset the last
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
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
symbol library format. Thanks in advance for the help.
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?
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()
4) That ternary in GetNextDrawItem() is breaking my brain a bit.
5) In footprint_info.h, if we are returning the wxString itself (instead
of the reference), it shouldn't be const. (addendum: Also loadAliases())
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 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!
KiCad Services Corporation
+1 530 302 5483 | +1 212 603 9372