Re: [Kicad-developers] CircuitHub KiCad Integration
On Wed, May 15, 2013 at 1:09 AM, Andrew Seddon wrote: > > But I believe the world does need a better way to design and > manufacture electronics and the cause is just. Your cause or KiCad's? Mitch. ___ 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] The developer mailing list did not work in my case
I to want to voice my disappointment in not having the schematic portion merged. If there are problems please clearly list them so others can fix them. Regards, Shane On May 14, 2013 6:31 PM, "Alexander Lunev" wrote: > Jean-Pierre and Wayne, you have let me know that the root of the problem > is I was silent about my intentions. > > The short review of what happened: > > 1) [31 Aug 2008]: > https://lists.launchpad.net/kicad-developers/msg01689.html > "> ... > > I think, for users, better to have something than nothing! > > Is it required to have a different homepage for pcad2kicad? > > May be better to integrate it directly in to the KiCad? > > ... > > Igor Plyatov > > Would anybody object if PCAD to KiCad converter were integrated to KiCad? > Alexander Lunev" > > 2) Dick Hollenbeck wrote: "No objection from me." > > So only Dick responded. It was clear to me that nobody disagreed. > > Unfortunately the long break took place here. > > 3) [08 Jun 2012]: I started to rewrite pcad2kicad from Delphi to c++. > > 4) [10 Jun 2012]: > https://lists.launchpad.net/kicad-developers/msg08429.html > Alexander Lunev wrote: "Hi. Would you add me to the team?" > > 5) [11 Jun 2012]: > https://lists.launchpad.net/kicad-developers/msg08435.html > Alexander Lunev wrote: "I had been granted a write permission to Kicad > SVN repository since 2008. At the same time I was involved to pcad2kicad > project and added polygons support. pcad2kicad is mostly written in Delphi. > It was agreed to rewrite pcad2kicad in C++ in order to integrate it into > Kicad and provide the opportunity for more people to be involved in the > developing process. > Unfortunately, since that time both the former of pcad2kicad and I had had > no spare time to continue the development. But now I have just started to > develop a new device and I want to use Kicad for that. So I need to convert > some libraries into Kicad and decided to resume my plans with pcad2kicad > converter. That is why I created the pcad2kicad branch that you noticed > some days ago. > > P.S. Several weeks ago I tried to find Kicad project in old locations, > firstly on the sourceforge.net Wiki. But there are some issues. As I > understood, Kicad developing group was removed from Yahoo and I do not know > why. I think I missed much. And now I see that Kicad is on Launchpad and > Bazaar repo is used where I have not got the write permission. So there are > many surprises to me." > > No reaction except Miguel Angel Ajo Pelayo. > > 6) [15 Jun 2012]: I completed rewriting pcad2kicad from Delphi to c++ and > fixed the main bug concerning the recursion. At this point pcad2kicad was > ready to use. I requested merge with lp:kicad. > > 7) [24 Jun 2012]: I received Wayne's respond: > "PCAD import support would be a welcome addition to KiCad but I am not > thrilled about adding another stand alone executable to KiCad. My > preference would be to add a PCAD plug-in to Pcbnew..." > > 8) [25 Jun 2012]: I asked Wayne: "What about translating P-Cad libraries?" > No reaction. > > 9) [27 Jun 2012]: I decided to agree and started to rewrite pcad2kicad to > make it Pcbnew plugin. > > 10) [07 Jul 2012]: I published eeschema-plugin blueprint: > https://blueprints.launchpad.net/kicad/+spec/eeschema-plugin and assigned > Jean-Pierre as an approver: "This Eeschema plug-in is necessary to > support new ones such as Eagle, P-Cad and other plug-ins for Eeschema. It > is supposed that the Eeschema plug-in mechanism needs to be very similar to > the one implemented in Pcbnew." > No reaction. > > 11) I continued trying to agree with Wayne and Jean-Pierre fulfilling > their ideas again and again. Every time I tried to believe that all will be > OK. > > 12) 6 months passed and at last Jean-Pierre merged pcad2kicadpcb to > lp:kicad! > For some unknown to me reason pcad2kicadsch is still not merged into > lp:kicad! > Today is 15 May, 2013. > Moreover, still there is not a write access to lp:kicad! > > The same ignoring situation is with GOST-doc-gen and the component manager. > > I have ultimately stopped hoping anything positive from the team. > > Alexander > > ___ > 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
[Kicad-developers] The developer mailing list did not work in my case
Jean-Pierre and Wayne, you have let me know that the root of the problem is I was silent about my intentions. The short review of what happened: 1) [31 Aug 2008]: https://lists.launchpad.net/kicad-developers/msg01689.html "> ... > I think, for users, better to have something than nothing! > Is it required to have a different homepage for pcad2kicad? > May be better to integrate it directly in to the KiCad? > ... > Igor Plyatov Would anybody object if PCAD to KiCad converter were integrated to KiCad? Alexander Lunev" 2) Dick Hollenbeck wrote: "No objection from me." So only Dick responded. It was clear to me that nobody disagreed. Unfortunately the long break took place here. 3) [08 Jun 2012]: I started to rewrite pcad2kicad from Delphi to c++. 4) [10 Jun 2012]: https://lists.launchpad.net/kicad-developers/msg08429.html Alexander Lunev wrote: "Hi. Would you add me to the team?" 5) [11 Jun 2012]: https://lists.launchpad.net/kicad-developers/msg08435.html Alexander Lunev wrote: "I had been granted a write permission to Kicad SVN repository since 2008. At the same time I was involved to pcad2kicad project and added polygons support. pcad2kicad is mostly written in Delphi. It was agreed to rewrite pcad2kicad in C++ in order to integrate it into Kicad and provide the opportunity for more people to be involved in the developing process. Unfortunately, since that time both the former of pcad2kicad and I had had no spare time to continue the development. But now I have just started to develop a new device and I want to use Kicad for that. So I need to convert some libraries into Kicad and decided to resume my plans with pcad2kicad converter. That is why I created the pcad2kicad branch that you noticed some days ago. P.S. Several weeks ago I tried to find Kicad project in old locations, firstly on the sourceforge.net Wiki. But there are some issues. As I understood, Kicad developing group was removed from Yahoo and I do not know why. I think I missed much. And now I see that Kicad is on Launchpad and Bazaar repo is used where I have not got the write permission. So there are many surprises to me." No reaction except Miguel Angel Ajo Pelayo. 6) [15 Jun 2012]: I completed rewriting pcad2kicad from Delphi to c++ and fixed the main bug concerning the recursion. At this point pcad2kicad was ready to use. I requested merge with lp:kicad. 7) [24 Jun 2012]: I received Wayne's respond: "PCAD import support would be a welcome addition to KiCad but I am not thrilled about adding another stand alone executable to KiCad. My preference would be to add a PCAD plug-in to Pcbnew..." 8) [25 Jun 2012]: I asked Wayne: "What about translating P-Cad libraries?" No reaction. 9) [27 Jun 2012]: I decided to agree and started to rewrite pcad2kicad to make it Pcbnew plugin. 10) [07 Jul 2012]: I published eeschema-plugin blueprint: https://blueprints.launchpad.net/kicad/+spec/eeschema-plugin and assigned Jean-Pierre as an approver: "This Eeschema plug-in is necessary to support new ones such as Eagle, P-Cad and other plug-ins for Eeschema. It is supposed that the Eeschema plug-in mechanism needs to be very similar to the one implemented in Pcbnew." No reaction. 11) I continued trying to agree with Wayne and Jean-Pierre fulfilling their ideas again and again. Every time I tried to believe that all will be OK. 12) 6 months passed and at last Jean-Pierre merged pcad2kicadpcb to lp:kicad! For some unknown to me reason pcad2kicadsch is still not merged into lp:kicad! Today is 15 May, 2013. Moreover, still there is not a write access to lp:kicad! The same ignoring situation is with GOST-doc-gen and the component manager. I have ultimately stopped hoping anything positive from the team. Alexander___ 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
[Kicad-developers] CircuitHub KiCad Integration
Hi Everyone, I am working on https://circuithub.com/ which is an online symbol/footprint/3D library. We had a lot of requests for KiCad export, which I'm just polishing off now. I would like to put the KiCad logo on our homepage as a supported tool. I did a bit of digging and it looks like Fabrizio's work is the latest and greatest. https://commons.wikimedia.org/wiki/File:Kicad_logo_new.png I just wanted to sanity check if anybody has objections to me doing this, particularly Fabrizio. p.s As I have discovered over the last year, large software projects are no joke. But I believe the world does need a better way to design and manufacture electronics and the cause is just. So thanks for all your hard work! Best -- Andrew Seddon Co-founder CircuitHub ___ 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] layer based constraints
bzr branch lp:~simon-huwyler/kicad/layerConstraints From: Simon Huwyler Sent: Tuesday, May 14, 2013 11:48 AM To: Dick Hollenbeck Cc: KiCad Developers Subject: Re: [Kicad-developers] layer based constraints I have uploaded a branch. It’s still the version with simple constraints for layers which won’t probably be what we want. But if you feel like getting a hands-on-experience of how the however-layer-dependent constraints could “look and feel” like, feel free to try it out. Select the option to show clearances for all tracks. I really like it this way. Unfortunately I haven’t had much time to do more investigations of how the constraints should and could look like (5 months old twins, Mummy is out of house, Daddy has to look after...) But I will have a look at it asap! Best regards Simon From: Dick Hollenbeck Sent: Wednesday, May 08, 2013 2:42 PM To: Simon Huwyler Cc: KiCad Developers ; Lorenzo Marcantonio Subject: Re: [Kicad-developers] layer based constraints On May 8, 2013 7:31 AM, "Dick Hollenbeck" wrote: > > > On May 8, 2013 7:24 AM, "Simon Huwyler" wrote: > >> > >> Kicad evolves based on individual need. Try and stay close to your > >> individual use cases, else you may end up creating something few will use. > >> Einstein: as simple as possible, but not simpler. > > > > > > So, if I get you right, the whole KiCad repository is merely a huge > > collection of branches each one created for personal needs (as in my case > > the very special need to deal with _fabrication_ layer constraints), and > > only time will show what turns out to be a feature that should be taken > > into the main branch? > > > > So, my approch was not that bad, indeed! :-) Therefore, I should upload > > this branch, even knowing that it is useful for _me_ and probably no one > > else? > > Sorry for these newbie-ish questions. But this is really a whole new world > > for me. :-) I was quite reluctant doing so, because I thought I should only > > "contribute" things that are really useful to others and have a chance to > > eventually make it to the main branch. > > This approach is now common in launchpad hosted projects and at github. > > Your blueprint idea is worth a try. I don't know how good its UI is. A forum with topic specific threads might be more useful. Rate of improvement in launchpad is slow at this point. Shuttleworth is chasing bigger fish. No sign of the $100, 000, 000 investment at github either. They still cannot even display source lines wider than about 80 characters. But free only buys you so much. But often great ideas are lost in the stream of the mailing list. > > > > > > > > > -Ursprüngliche Nachricht- From: Lorenzo Marcantonio > > Sent: Wednesday, May 08, 2013 2:12 PM > > > > To: Kicad Developers > > Subject: Re: [Kicad-developers] layer based constraints > > > > On Wed, May 08, 2013 at 07:03:48AM -0500, Dick Hollenbeck wrote: > >> > >> Alfons, in munich, worked for zucken (spelling), an eda company, for 15 > >> years, well bfore writing freerouter. His UI includes netclass features. > >> It is not obvious that they merely mimic the specctra spec. If not, is > >> this his experience being injected to trump something he thought was > >> imperfect? > > > > > > I can't say... SPECCTRA was a pre-existing product, and simply became the > > defacto interface. Maybe it's simply well engineered for the things it > > needs to do, but then every company will 'personalize' it depending on > > the requirements (so they can say "our specctra is better than yours!"). > > The same freerouter AFAIK don't implement it in full (no arcs, for > > example, seeing the kicad code). > > > > Or maybe the author of freerouter simply added the extra features > > because they were convenient (and to hell with the specctra standard). > > > >> Kicad evolves based on individual need. Try and stay close to your > >> individual use cases, else you may end up creating something few will use. > >> Einstein: as simple as possible, but not simpler. > > > > > > That's why we are discussing if/how enhanced rules can be applied. > > > > -- > > Lorenzo Marcantonio > > Logos Srl > > > > ___ > > 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:
Re: [Kicad-developers] layer based constraints
I have uploaded a branch. It’s still the version with simple constraints for layers which won’t probably be what we want. But if you feel like getting a hands-on-experience of how the however-layer-dependent constraints could “look and feel” like, feel free to try it out. Select the option to show clearances for all tracks. I really like it this way. Unfortunately I haven’t had much time to do more investigations of how the constraints should and could look like (5 months old twins, Mummy is out of house, Daddy has to look after...) But I will have a look at it asap! Best regards Simon From: Dick Hollenbeck Sent: Wednesday, May 08, 2013 2:42 PM To: Simon Huwyler Cc: KiCad Developers ; Lorenzo Marcantonio Subject: Re: [Kicad-developers] layer based constraints On May 8, 2013 7:31 AM, "Dick Hollenbeck" wrote: > > > On May 8, 2013 7:24 AM, "Simon Huwyler" wrote: > >> > >> Kicad evolves based on individual need. Try and stay close to your > >> individual use cases, else you may end up creating something few will use. > >> Einstein: as simple as possible, but not simpler. > > > > > > So, if I get you right, the whole KiCad repository is merely a huge > > collection of branches each one created for personal needs (as in my case > > the very special need to deal with _fabrication_ layer constraints), and > > only time will show what turns out to be a feature that should be taken > > into the main branch? > > > > So, my approch was not that bad, indeed! :-) Therefore, I should upload > > this branch, even knowing that it is useful for _me_ and probably no one > > else? > > Sorry for these newbie-ish questions. But this is really a whole new world > > for me. :-) I was quite reluctant doing so, because I thought I should only > > "contribute" things that are really useful to others and have a chance to > > eventually make it to the main branch. > > This approach is now common in launchpad hosted projects and at github. > > Your blueprint idea is worth a try. I don't know how good its UI is. A forum with topic specific threads might be more useful. Rate of improvement in launchpad is slow at this point. Shuttleworth is chasing bigger fish. No sign of the $100, 000, 000 investment at github either. They still cannot even display source lines wider than about 80 characters. But free only buys you so much. But often great ideas are lost in the stream of the mailing list. > > > > > > > > > -Ursprüngliche Nachricht- From: Lorenzo Marcantonio > > Sent: Wednesday, May 08, 2013 2:12 PM > > > > To: Kicad Developers > > Subject: Re: [Kicad-developers] layer based constraints > > > > On Wed, May 08, 2013 at 07:03:48AM -0500, Dick Hollenbeck wrote: > >> > >> Alfons, in munich, worked for zucken (spelling), an eda company, for 15 > >> years, well bfore writing freerouter. His UI includes netclass features. > >> It is not obvious that they merely mimic the specctra spec. If not, is > >> this his experience being injected to trump something he thought was > >> imperfect? > > > > > > I can't say... SPECCTRA was a pre-existing product, and simply became the > > defacto interface. Maybe it's simply well engineered for the things it > > needs to do, but then every company will 'personalize' it depending on > > the requirements (so they can say "our specctra is better than yours!"). > > The same freerouter AFAIK don't implement it in full (no arcs, for > > example, seeing the kicad code). > > > > Or maybe the author of freerouter simply added the extra features > > because they were convenient (and to hell with the specctra standard). > > > >> Kicad evolves based on individual need. Try and stay close to your > >> individual use cases, else you may end up creating something few will use. > >> Einstein: as simple as possible, but not simpler. > > > > > > That's why we are discussing if/how enhanced rules can be applied. > > > > -- > > Lorenzo Marcantonio > > Logos Srl > > > > ___ > > 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
