Re: [Kicad-developers] Symbol library code changes
Thanks! Just to show I wasn’t making it up, here is a screen grab of what happens when I click the link you provided initially. I edited the link to remove the period (https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit) and now it works. It didn’t occur to me to try that before. From: Wayne Stambaugh Sent: November 12, 2019 9:05 AM To: Brian Piccioni; kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] Symbol library code changes On 11/9/19 7:04 PM, Brian Piccioni wrote: > Sorry the link to the symbol library format doesn’t seem to work. Strange, it's open to all for comment so you should be able to ready it with google docs. I've attached a copy. > > > > Can you supply a link which works and maybe a link to the PCB file > format? I’ve been dying to know ... The board file documentation[1] is not complete but it will give you some idea of the file format. The best bet is to just open a board file with a text editor. One of the design goals of the s-expression file format is human readability so if you know what elements you would expect to find in a PCB design, you can likely deduce you way through the KiCad board file format. [1]: http://bazaar.launchpad.net/~stambaughw/kicad/doc-read-only/download/head:/1115%4016bec504-3128-0410-b3e8-8e38c2123bca:trunk%252Fkicad-doc%252Fdoc%252Fhelp%252Ffile_formats%252Ffile_formats.pdf/file_formats.pdf > > > > *From: *Wayne Stambaugh <mailto:stambau...@gmail.com> > *Sent: *November 9, 2019 3:42 PM > *To: *kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > *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 rem
Re: [Kicad-developers] Symbol library code changes
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@lists.launchpad.net 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 >>
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
Re: [Kicad-developers] Symbol library code changes
Hi Seth, 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. Did you miss the previous check verifies the size of the draw items list and returns non-zero if the list sizes are different? The right hand side list end check would be redundant unless we are worried thread safety. I suppose the check wouldn't hurt. >> - Same with the footprint check. Ideally, these would be the same style >> (iterators vs. dereference) but that's minor Same as above. >> - Do we expect these containers to remain sorted? I hadn't considered that but it is possible that you could have identical objects in a different order which would fail the comparison. I don't see where the MULTIVECTOR is sorted any where but maybe I missed it. If it is not sorted than I will have to fix this. Everything else has been fixed. Let me know if you find anything else. Cheers, Wayne > > 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
Re: [Kicad-developers] Symbol library code changes
Hi JP, On 11/8/19 7:51 AM, jp charras wrote: > Le 06/11/2019 à 21:34, Wayne Stambaugh a écrit : >> 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 did not really have a look into the code, but I encountered an issue > in DIALOG_EDIT_COMPONENT_IN_LIBRARY dialog: the page 0 is incorrectly > drawn (the page 1 is drawn as background of page 0). > > Attached a patch that fixes this issue (already encountered in > simulation options frame). > > To remove a page from a wxNotebook, using Hide() is incorrect: one can > hide a widget inside a page, not the page itself. > (RemovePage must be used instead) > > Hide() the panel can work on some platforms, but not all. > Moreover Show() the panel draws this panel in the background of the > active panel! > Strange result... Good catch and thanks for the patch. I merged it pushed it to the my development branch along with some other fixes. Cheers, Wayne > > Thanks. > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Symbol library code changes
Le 06/11/2019 à 21:34, Wayne Stambaugh a écrit :
> 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 did not really have a look into the code, but I encountered an issue
in DIALOG_EDIT_COMPONENT_IN_LIBRARY dialog: the page 0 is incorrectly
drawn (the page 1 is drawn as background of page 0).
Attached a patch that fixes this issue (already encountered in
simulation options frame).
To remove a page from a wxNotebook, using Hide() is incorrect: one can
hide a widget inside a page, not the page itself.
(RemovePage must be used instead)
Hide() the panel can work on some platforms, but not all.
Moreover Show() the panel draws this panel in the background of the
active panel!
Strange result...
Thanks.
--
Jean-Pierre CHARRAS
eeschema/dialogs/dialog_edit_component_in_lib.cpp | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/eeschema/dialogs/dialog_edit_component_in_lib.cpp
b/eeschema/dialogs/dialog_edit_component_in_lib.cpp
index 0e3edcf67..2add8156c 100644
--- a/eeschema/dialogs/dialog_edit_component_in_lib.cpp
+++ b/eeschema/dialogs/dialog_edit_component_in_lib.cpp
@@ -684,10 +684,11 @@ void DIALOG_EDIT_COMPONENT_IN_LIBRARY::OnSizeGrid(
wxSizeEvent& event )
void DIALOG_EDIT_COMPONENT_IN_LIBRARY::syncControlStates( bool aIsAlias )
{
+// Remove the not wanted notebook page.
+// *Do not use* Hide(), it is suitable to hide a widget,
+// but it is not suitable to hide a notebook page (that is not a widget)
if( aIsAlias )
-m_PanelFootprintFilter->Hide();
-else
-m_PanelFootprintFilter->Show();
+m_NoteBook->RemovePage( 1 );
bSizerLowerBasicPanel->Show( !aIsAlias );
bButtonSize->Show( !aIsAlias );
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :
Re: [Kicad-developers] Symbol library code changes
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? 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? 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
Re: [Kicad-developers] Symbol library code changes
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
Re: [Kicad-developers] 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[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? 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! 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More
[Kicad-developers] Symbol library code changes
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 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
