kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Python scripting support is hopefully going to be implemented at some
point during V6 development.  This should allow you to integrate the KLC
scripts directly into the symbol library editor.  This will most likely
happen late in V6 development because there are some major functional
changes to the low level schematic and library objects.  It doesn't make
sense to swig this until the low level object APIs stabilize.

On 4/25/19 9:39 AM, Antonio Vázquez Blanco wrote:
> From the feedback given I am thinking about changing the proposal.
> 
> Given that my ultimate goal was to integrate KLC check into KiCad to
> improve the quality of contributions and reduce librarian work, and that
> seems conflicting we may need to re-think my approach to the problem.
> 
> I don't want to enforce KLC on every user. Furthermore, from your
> comments I thought that maybe I am interested in even writing some tests
> that would conform with a set of rules that only my organization would
> care about. That being said, I came to the conclusion that maybe we
> could define groups of tests that could be enabled or disabled depending
> on user preferences. For example, KLC could be one of those groups of rules.
> 
> John suggested the usage of external scripts. That could be the solution
> to various problems. Scripts could be externally updated if needed and
> they would also allow to users to write their own checks without having
> to recompille the full source code. It would also allow the distribution
> of those "groups" of rules suggested above.
> 
> Maybe we sould think of a interface that would allow KiCad to look for a
> set of Python scripts inside a particular folder to allow us to perform
> a certain set of checks that would return result objects that KiCad
> could later show.
> 
> Is this approach better? If so, given my lack of knowledge about KiCad
> codebase, I would need some help designing that interface.
> 
> Thank you for your feedback!
> 
> 
> 
> 
> 
> 
> El jue., 25 abr. 2019 a las 13:46, Wayne Stambaugh
> (<stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>) escribió:
> 
>     Antonio,
> 
>     Exactly what checks are you planning on implementing?  As long as they
>     are generic in nature like off grid pin checking, then I'm fine with
>     that.  If they are specific KLC checks like spacing, line width, etc,
>     that is a different issue.  We should not be forcing KLC rules on all
>     users.  If you wanted to make KLC style checks that can be customized
>     and disabled to meet each users specific needs, I would be open to that.
> 
>     This code is not in the ERC code.  Symbol library tests are separate
>     from the ERC and live in the symbol editor code.  You can find the
>     symbol library editor code in the ./eeschema/libedit folder in the
>     source tree.
> 
>     Thank you in your interest in contributing to KiCad.
> 
>     Cheers,
> 
>     Wayne
> 
>     On 4/25/19 5:39 AM, Antonio Vázquez Blanco wrote:
>     > I've been playing around a little bit with KiCad source code
>     lately and
>     > in the forums [1] I was encouraged to write to the dev mailing list in
>     > order to get feedback on how to improve the current library error
>     checking.
>     >
>     > Summarizing the thread, I made some changes [2] so that a couple
>     of KLC
>     > checks are performed on syms but now that I've done that I would
>     like to
>     > implement this properly. I am looking for pointers on how should I
>     > implement this so that the chances of me getting the code upstream
>     > maximize and so that I can reuse the ERC/DRC code as much as possible.
>     >
>     > Thank you!
>     >
>     > [1] https://forum.kicad.info/t/improving-library-editor-checks/16557/5
>     > [2]
>     >
>     https://gitlab.com/kicad-mirror/kicad-source-mirror/compare/master...feature%2Fklc
>     >
>     > _______________________________________________
>     > Mailing list: https://launchpad.net/~kicad-developers
>     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto: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
>     <mailto: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
>