Re: [Kicad-developers] Kicad 6 API

[Wayne Stambaugh]

On 7/16/20 12:13 AM, Tim Hawkins wrote:
> Modularization is a key part to large-scale refactoring, if you have
> system that can't be subdivided then that a good indicator that you have
> an architectural problem.

Parts of KiCad are very modular.  Other parts, not so much.  There is
still plenty to do in that regard.

> 
> One of the best refactoring patterns for large systems is the "Strangler
> fig pattern", where you split out a unit of functionality as a seperate
> module and refactor that.  In this case I'm speaking of modules nothing
> the kicad sense of its bunch of seperate apps, but in the sense of a lot
> of small subunits, somebody spoke above of a kicad.so library, but that
> is in itself too large a chunk and things need to be a lot smaller than
> that. 

Code modularity and shared object modularity are two separate issues.
If you are suggesting that we break a kicad.so into lots of smaller
libraries, I don't see the need for that except maybe to split out the
board and schematic base object code.

> 
> I'm a 40 year veteran coder, c, c++, php, java, kotlin, and c#/dotnet
> core. I have not been very active in OSS, maybe it's time that changed,
> and kicad sounds like a good project to engage with, as it would engage
> with my interests (PCBs, CNC, 3d printers etc, personal fabrication). I
> use fedora Linux everywhere, I have all the tooling required. 
> 
> Where can I find a good guide for getting started with the project?

The two best sources of information for new developers are the
contributors guidelines on the KiCad website[1] and the wiki on the
KiCad source repo at GitLab[2].  There is a bit overlap between these
resources but everything you need to know is in there.  If you have any
questions, the mailing list is the place to ask.

[1]: https://kicad-pcb.org/contribute/developers/
[2]: https://gitlab.com/kicad/code/kicad/-/wikis/home

> 
> On Thu, Jul 16, 2020, 07:10 Wayne Stambaugh  > wrote:
> 
> Hi Conrad,
> 
> On 7/15/20 3:51 PM, Conrad Wood wrote:
> > On Wed, 2020-07-15 at 13:53 -0400, Mark Roszko wrote:
> >>> I also think it would enable independent software developers to
> >> build software on top of, or around kicad, further enhancing its
> >> value.
> >>
> >> They should be contributing to KiCad first ;)
> >> These plans for separation have been around for years, the problem is
> >> the amount of devs is limited and their time even more so. It is
> >> an open source volunteer effort after all.
> >
> > Isn't that a bit of a chicken-and-egg situation?
> 
> Not necessarily.  Refactoring can be done incrementally over long
> periods of time.  It doesn't have to be an all or nothing effort.  This
> is pretty much how the Linux kernel development happens.
> 
> >
> > I mean, it's fairly hard to start contributing to KiCad due to its
> > complexity. (at least that is my impression - but then I might just be
> > stupid :) )
> > IMHO, splitting it up would lower the entry barrier to new-comers.
> 
> EDA applications are by their nature complex so I don't know how
> splitting up complex code would lower the barrier to entry.  I'm not
> suggesting that the KiCad code base couldn't be vastly improved but I
> cannot see how that will lower the barrier to entry for new developers.
> 
> >
> > I'd be more than happy to contribute, but clearly I can't just "split
> > out bits into a library" on my own w/o discussion and consensus. That
> > _has_ to be a team effort, right?
> 
> Any changes to the code structure would require discussion and consensus
> with the lead development team.  My guess any discussion that you could
> think of has already been discussed more than once.  It's generally a
> good idea to check the developer list mailing archives for previous
> discussions so we don't have to rehash the same discussion.
> 
> >
> > I understand, that there never is "The Right Time" to do something
> like
> > it and I consider it very important not to add any extra workload on
> > already stretched people.
> >
> > Rather, with starting this discussion I hope to contribute  with my
> > limited means, specifically, finding a means to spread the workload a
> > bit more evenly, and at some point, I might be able to directly
> > contribute as well.
> 
> I will reiterate Seth's comments about starting small.  It really is the
> most sensible path forward to becoming a member of the development team.
> 
> Cheers,
> 
> Wayne
> 
> 
> >
> > Also, for the sake of clarity, when I mentioned about on top of or
> > "around kicad" I was very much thinking of more open-source software,
> > not closed systems! Thus adding to the functionality of KiCad.
> >
> > Conrad
> > 
> >
> >
> > ___
> > Mailing list: 

Re: [Kicad-developers] CADSTAR Importer & Pad Stacks

[Wayne Stambaugh]

Hi Roberto,

Sorry it took so long to reply but I've been busy.  I did read your
draft and it looks promising.   Please give me permission to at least
add comments.  I don't necessarily need full edit permission.

Thanks,

Wayne

On 7/11/20 8:01 AM, Roberto Fernández Bautista wrote:
> Hi all,
> 
> Has anybody had a chance to check the draft document I made on Pad
> Stacks
> ?
>  
> 
> I would like at least some feedback if this is the kind of document you
> would be looking for, or if not what to change about it/what it should
> focus on. 
> 
> I'm keen on pad stacks in KiCad since CADSTAR heavily relies on them -
> at the moment the importer wouldn't be able to handle complex cases. 
> 
> I would like to help wherever I can to get this in before v6 feature freeze.
> 
> Thanks.
> 
> Roberto.
> 
> On Sun, 21 Jun 2020 at 12:19, Roberto Fernández Bautista
> mailto:roberto.fer@gmail.com>> wrote:
> 
> Jon,
> 
> Thanks for the advice. It will still be a while until I have
> something working but yes, I will create a merge request once I have
> a skeleton for the importer.
> 
> @Jeff Young - I've made you an editor of the document I made on Pad
> Stacks
> 
> .
> Hopefully you will have received a separate email with an editor's
> link. Let me know if that wasn't the case.
> 
> Roberto
> 
> On Sun, 21 Jun 2020 at 02:51, Jon Evans  > wrote:
> 
> Hi Roberto,
> 
> Welcome!  Thanks for pointing that out about Altium, I learn
> something
> new every day!
> 
> I recommend that you open a merge request for your CADSTAR importer
> once it is far enough along for people to do some basic tests.  You
> can mark it as "WIP", but having the MR open early will help get
> early
> testing and review so that we can help get it in for V6.
> 
> Regarding Pad Stacks, @Jeff Young is probably the best person to
> sync
> with on the lead dev team as he has recently been doing some of the
> groundwork.
> 
> Best,
> Jon
> 
> On Sat, Jun 20, 2020 at 9:07 PM Roberto Fernández Bautista
> mailto:roberto.fer@gmail.com>>
> wrote:
> >
> > Hi all,
> >
> > I'm new to the mailing list. I just wanted to make you aware
> that I'm starting work on a native Zuken CADSTAR importer for
> KiCad. I intend to follow a similar approach to @pointhi in the
> forums for his Altium importer - trying to stick to similar
> class structure where possible. My "short" term plan is to
> provide an importer for the CADSTAR PCB archive format (which is
> an ASCII file that is based on S-expressions). Since I'm doing
> this in my free time, I expect it will take a few months but
> hopefully the PCB importer would be ready before KiCad v6
> feature freeze. Once I have something that sort of works, I'll
> make a merge request and ask for further feedback on how to
> improve it.
> >
> > Now, on a second note, I'd like to provide some input on Pad
> Stacks. I joined the mailing list after the last post on the
> thread "How do we envision Pad Stacks?"
> (https://lists.launchpad.net/kicad-developers/msg44006.html), so
> I can't reply to that thread directly, unfortunately. However,
> the topic discussed in that thread is very relevant to the work
> I am trying to do with the CADSTAR importer (and I bet also
> important for the Altium importer @pointhi  made).
> >
> > I'd like to point out two small inaccuracies in Jon's message:
> >
> > In Altium you can define a full pad stack when editing
> footprints: Altium uses a default 14-electrical-layer board
> stackup which is then mapped to whatever layers you actually use
> in your design when you include the footprint.
> > You can define a SMD pad in an inner layer.
> >
> > Please see attached screenshots from v20.1 showing above two
> cases, maybe earlier versions didn't allow this?.  More details
> can be found here:
> 
> https://www.altium.com/documentation/altium-designer/pcb-prop-padpad-properties-ad.
> >
> >
> > To keep this email short, I've created a document with other
> bits of information that I feel might be useful (such as how
> CADSTAR handles Pad Stacks) as well as some suggestions for Pad
> Stack implementation in KiCad - maybe this could be the start of
> a more complex design document?
> 
> https://docs.google.com/document/d/1lxBI7_X_I7pO-nuDHPR

[Kicad-developers] GTK2 Support Dropped for Linux

[Ian McInerney]

I have just merged the PR that drops GTK2 support for Linux. This means
that the GTK3 version of wxWidgets must be used on all Linux platforms
building and using master (e.g. future v6). This change does not affect
5.1. If you don't use Linux, then this change shouldn't affect you.

-Ian
___
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] CADSTAR Importer & Pad Stacks

[Roberto Fernández Bautista]

Dear Wayne,

Thanks for taking the time to look at this. However, I should credit Seth
for the hard work he has put on the document to get it to the shape it is
in now - thanks Seth!

I've made you editor now - feel free to edit directly. I suppose I should
make everyone from the lead development team an editor of this document -
could you send me a private email with their email addresses, so I can add
them?

Roberto.

On Thu, 16 Jul 2020 at 13:13, Wayne Stambaugh  wrote:

> Hi Roberto,
>
> Sorry it took so long to reply but I've been busy.  I did read your
> draft and it looks promising.   Please give me permission to at least
> add comments.  I don't necessarily need full edit permission.
>
> Thanks,
>
> Wayne
>
> On 7/11/20 8:01 AM, Roberto Fernández Bautista wrote:
> > Hi all,
> >
> > Has anybody had a chance to check the draft document I made on Pad
> > Stacks
> > <
> https://docs.google.com/document/d/1lxBI7_X_I7pO-nuDHPRVlfRBH24XTmwuuN69o_Bqk3s/edit?usp=sharing
> >?
> >
> > I would like at least some feedback if this is the kind of document you
> > would be looking for, or if not what to change about it/what it should
> > focus on.
> >
> > I'm keen on pad stacks in KiCad since CADSTAR heavily relies on them -
> > at the moment the importer wouldn't be able to handle complex cases.
> >
> > I would like to help wherever I can to get this in before v6 feature
> freeze.
> >
> > Thanks.
> >
> > Roberto.
> >
> > On Sun, 21 Jun 2020 at 12:19, Roberto Fernández Bautista
> > mailto:roberto.fer@gmail.com>> wrote:
> >
> > Jon,
> >
> > Thanks for the advice. It will still be a while until I have
> > something working but yes, I will create a merge request once I have
> > a skeleton for the importer.
> >
> > @Jeff Young - I've made you an editor of the document I made on Pad
> > Stacks
> > <
> https://docs.google.com/document/d/1lxBI7_X_I7pO-nuDHPRVlfRBH24XTmwuuN69o_Bqk3s/edit?usp=sharing
> >.
> > Hopefully you will have received a separate email with an editor's
> > link. Let me know if that wasn't the case.
> >
> > Roberto
> >
> > On Sun, 21 Jun 2020 at 02:51, Jon Evans  > > wrote:
> >
> > Hi Roberto,
> >
> > Welcome!  Thanks for pointing that out about Altium, I learn
> > something
> > new every day!
> >
> > I recommend that you open a merge request for your CADSTAR
> importer
> > once it is far enough along for people to do some basic tests.
> You
> > can mark it as "WIP", but having the MR open early will help get
> > early
> > testing and review so that we can help get it in for V6.
> >
> > Regarding Pad Stacks, @Jeff Young is probably the best person to
> > sync
> > with on the lead dev team as he has recently been doing some of
> the
> > groundwork.
> >
> > Best,
> > Jon
> >
> > On Sat, Jun 20, 2020 at 9:07 PM Roberto Fernández Bautista
> > mailto:roberto.fer@gmail.com>>
> > wrote:
> > >
> > > Hi all,
> > >
> > > I'm new to the mailing list. I just wanted to make you aware
> > that I'm starting work on a native Zuken CADSTAR importer for
> > KiCad. I intend to follow a similar approach to @pointhi in the
> > forums for his Altium importer - trying to stick to similar
> > class structure where possible. My "short" term plan is to
> > provide an importer for the CADSTAR PCB archive format (which is
> > an ASCII file that is based on S-expressions). Since I'm doing
> > this in my free time, I expect it will take a few months but
> > hopefully the PCB importer would be ready before KiCad v6
> > feature freeze. Once I have something that sort of works, I'll
> > make a merge request and ask for further feedback on how to
> > improve it.
> > >
> > > Now, on a second note, I'd like to provide some input on Pad
> > Stacks. I joined the mailing list after the last post on the
> > thread "How do we envision Pad Stacks?"
> > (https://lists.launchpad.net/kicad-developers/msg44006.html), so
> > I can't reply to that thread directly, unfortunately. However,
> > the topic discussed in that thread is very relevant to the work
> > I am trying to do with the CADSTAR importer (and I bet also
> > important for the Altium importer @pointhi  made).
> > >
> > > I'd like to point out two small inaccuracies in Jon's message:
> > >
> > > In Altium you can define a full pad stack when editing
> > footprints: Altium uses a default 14-electrical-layer board
> > stackup which is then mapped to whatever layers you actually use
> > in your design when you include the footprint.
> > > You can define a SMD pad in an inner layer.
> > >
> > > Please 

[Kicad-developers] DRC ladybug symbol origin

[Ben Ellis]

Hi all,

Does anyone know why the DRC symbol is a ladybug? Asking for a friend

Best,
Ben
___
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] DRC ladybug symbol origin

[Brian Piccioni]

I'm guessing because it finds bugs?

On 2020-07-16 11:14 p.m., Ben Ellis wrote:

Hi all,

Does anyone know why the DRC symbol is a ladybug? Asking for a friend

Best,
Ben

___
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] DRC ladybug symbol origin

[Eeli Kaikkonen]

Do an image google search for "debug icon ladybug" and you'll see
quite many debugging related ladybugs. I think it has been used as a
symbol because it's easily recognizable and cute.

See https://en.wikipedia.org/wiki/Bug_(engineering).

On Fri, Jul 17, 2020 at 6:16 AM Brian Piccioni
 wrote:
>
> I'm guessing because it finds bugs?
>
> On 2020-07-16 11:14 p.m., Ben Ellis wrote:
>
> Hi all,
>
> Does anyone know why the DRC symbol is a ladybug? Asking for a friend
>
> Best,
> Ben
>
> ___
> 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

___
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