[Kicad-developers] Transferring KiCad Librarians team ownership

[Carl Poirier]

Hi folks,

I just wanted to let you know that I transferred my ownership of the KiCad
Librarians team to Oliver Walters, known as SchrodingersGat on Github. This
ownership allowed me to create new repos, manage the team and the usual
stuff. I won't be contributing to KiCad anymore on a regular basis, so your
libraries manager of choice for the releases and other discussions will be
Oliver.

I wish the best for the project and I have been elated to collaborate with
you all.

Carl
___
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] Release 4.0.5 tagged.

[Carl Poirier]

Alright.

On Fri, Dec 9, 2016 at 1:34 AM, Nick Østergaard  wrote:

> Symlinks are not portable. I will just copy it, it is not taking up
> that much space.
>
> 2016-12-09 2:16 GMT+01:00 Carl Poirier :
> > Better yet, in the tarball still, just add a symlink from the old to the
> new
> > name.
> >
> > On Wed, Dec 7, 2016 at 4:55 PM, Carl Poirier 
> > wrote:
> >>
> >> Yeah that was my thoughts. Include in the tarball the old and the new
> >> names.
> >>
> >> On Wed, Dec 7, 2016 at 4:38 PM, Nick Østergaard 
> wrote:
> >>>
> >>> Yeah, I don't know what is the best solution. But alternatively we
> >>> could also just include them in the tarball, if we don't want it to
> >>> "pollute" the github kicad org.
> >>>
> >>> These tarballs:
> >>> http://downloads.kicad-pcb.org/libraries/
> >>>
> >>> 2016-12-07 22:28 GMT+01:00 Carl Poirier :
> >>> > Aah, I see now. I had missed the part that the fp-lib-table didn't
> get
> >>> > updated along the new install.
> >>> >
> >>> > We indeed decided to keep the pretty names the same but with Github's
> >>> > redirection, I missed the local uppgrade use case. What I can do is
> >>> > restore
> >>> > a copy of the pretties with the old name. This way the newer pretties
> >>> > will
> >>> > work with the old fp-lib-table.
> >>> >
> >>> > Carl
> >>> >
> >>> > On Wed, Dec 7, 2016 at 1:57 PM, Wayne Stambaugh <
> stambau...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> On 12/7/2016 1:52 PM, Nick Østergaard wrote:
> >>> >> > Yes, but lets use the windows use case. A user has 4.0.4 intalled
> >>> >> > and
> >>> >> > have fp-lib-table that matches the one used there for local libs.
> He
> >>> >> > then uninstalls 4.0.4 and install 4.0.5 (this would be the same as
> >>> >> > an
> >>> >> > update with a package manager and possibly osx too), the
> >>> >> > fp-lib-table
> >>> >> > is a user preference and will now reference non existing pretty
> >>> >> > dirs.
> >>> >> > The user starts pcbnew or cvpcb to add parts and when kicad tries
> to
> >>> >> > access one of those libs that do not exist anymore he gets
> >>> >> > "unexpected" errors.
> >>> >> >
> >>> >> > All I ask about is really; what is the desired action?
> >>> >> >
> >>> >> > I am ok with just including the rename, but I remember that at
> some
> >>> >> > time we said that we should not remove libs for patch releases.
> This
> >>> >> > would require a mention in the release note, which is probably
> also
> >>> >> > acceptable.
> >>> >>
> >>> >> I believe keeping the library names the same for stable series
> >>> >> releases
> >>> >> was what we originally decided.  I'm OK with adding a note to the
> >>> >> release notes for this one time.  In the future, we should probably
> >>> >> create a release series branch for the libraries as we did with the
> >>> >> source and cherry-pick changes as required.  I know it's extra work
> >>> >> but
> >>> >> this will keep users happy.  Hopefully there wont be many more 4
> >>> >> stable
> >>> >> releases so it probably doesn't make sense to do this until the 5
> >>> >> stable
> >>> >> release.
> >>> >>
> >>> >> >
> >>> >> >
> >>> >> > 2016-12-07 19:43 GMT+01:00 Carl Poirier  >:
> >>> >> >> Well, if I use all the libs as local pretties, using the
> >>> >> >> fp-lib-table
> >>> >> >> that
> >>> >> >> has been tagged the same will work, won't it? Do we want to
> support
> >>> >> >> mix
> >>> >> >> and
> >>> >> >> matching tags?
> >>> >> >>
> >>> >> >> On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard
> >>> >> >> 
> >>&g

Re: [Kicad-developers] Release 4.0.5 tagged.

[Carl Poirier]

Better yet, in the tarball still, just add a symlink from the old to the
new name.

On Wed, Dec 7, 2016 at 4:55 PM, Carl Poirier 
wrote:

> Yeah that was my thoughts. Include in the tarball the old and the new
> names.
>
> On Wed, Dec 7, 2016 at 4:38 PM, Nick Østergaard  wrote:
>
>> Yeah, I don't know what is the best solution. But alternatively we
>> could also just include them in the tarball, if we don't want it to
>> "pollute" the github kicad org.
>>
>> These tarballs:
>> http://downloads.kicad-pcb.org/libraries/
>>
>> 2016-12-07 22:28 GMT+01:00 Carl Poirier :
>> > Aah, I see now. I had missed the part that the fp-lib-table didn't get
>> > updated along the new install.
>> >
>> > We indeed decided to keep the pretty names the same but with Github's
>> > redirection, I missed the local uppgrade use case. What I can do is
>> restore
>> > a copy of the pretties with the old name. This way the newer pretties
>> will
>> > work with the old fp-lib-table.
>> >
>> > Carl
>> >
>> > On Wed, Dec 7, 2016 at 1:57 PM, Wayne Stambaugh 
>> > wrote:
>> >>
>> >> On 12/7/2016 1:52 PM, Nick Østergaard wrote:
>> >> > Yes, but lets use the windows use case. A user has 4.0.4 intalled and
>> >> > have fp-lib-table that matches the one used there for local libs. He
>> >> > then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an
>> >> > update with a package manager and possibly osx too), the fp-lib-table
>> >> > is a user preference and will now reference non existing pretty dirs.
>> >> > The user starts pcbnew or cvpcb to add parts and when kicad tries to
>> >> > access one of those libs that do not exist anymore he gets
>> >> > "unexpected" errors.
>> >> >
>> >> > All I ask about is really; what is the desired action?
>> >> >
>> >> > I am ok with just including the rename, but I remember that at some
>> >> > time we said that we should not remove libs for patch releases. This
>> >> > would require a mention in the release note, which is probably also
>> >> > acceptable.
>> >>
>> >> I believe keeping the library names the same for stable series releases
>> >> was what we originally decided.  I'm OK with adding a note to the
>> >> release notes for this one time.  In the future, we should probably
>> >> create a release series branch for the libraries as we did with the
>> >> source and cherry-pick changes as required.  I know it's extra work but
>> >> this will keep users happy.  Hopefully there wont be many more 4 stable
>> >> releases so it probably doesn't make sense to do this until the 5
>> stable
>> >> release.
>> >>
>> >> >
>> >> >
>> >> > 2016-12-07 19:43 GMT+01:00 Carl Poirier :
>> >> >> Well, if I use all the libs as local pretties, using the
>> fp-lib-table
>> >> >> that
>> >> >> has been tagged the same will work, won't it? Do we want to support
>> mix
>> >> >> and
>> >> >> matching tags?
>> >> >>
>> >> >> On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard > >
>> >> >> wrote:
>> >> >>>
>> >> >>> Well, the issue os the fact that if a user has choosen (one way or
>> the
>> >> >>> other) to use all of the local libs he needs to update the
>> >> >>> fp-lib-table
>> >> >>> manually. An option is to copy the renamed pretty fors to the old
>> name
>> >> >>> as to
>> >> >>> not generate errors for the user.
>> >> >>>
>> >> >>>
>> >> >>> Den 07/12/2016 13.21 skrev "Carl Poirier" <
>> carl.poirie...@gmail.com>:
>> >> >>>
>> >> >>> The KIGITHUB variable leads to Github. For using the pretties
>> locally,
>> >> >>> the
>> >> >>> fp-lib-table.for-pretty has to be used instead, which is the one
>> >> >>> that's
>> >> >>> included by default in the stable release. Anyway, as I had
>> mentioned
>> >> >>> in
>> >> >>> another thread very recently, the Github plugin is no

Re: [Kicad-developers] Release 4.0.5 tagged.

[Carl Poirier]

Yeah that was my thoughts. Include in the tarball the old and the new names.

On Wed, Dec 7, 2016 at 4:38 PM, Nick Østergaard  wrote:

> Yeah, I don't know what is the best solution. But alternatively we
> could also just include them in the tarball, if we don't want it to
> "pollute" the github kicad org.
>
> These tarballs:
> http://downloads.kicad-pcb.org/libraries/
>
> 2016-12-07 22:28 GMT+01:00 Carl Poirier :
> > Aah, I see now. I had missed the part that the fp-lib-table didn't get
> > updated along the new install.
> >
> > We indeed decided to keep the pretty names the same but with Github's
> > redirection, I missed the local uppgrade use case. What I can do is
> restore
> > a copy of the pretties with the old name. This way the newer pretties
> will
> > work with the old fp-lib-table.
> >
> > Carl
> >
> > On Wed, Dec 7, 2016 at 1:57 PM, Wayne Stambaugh 
> > wrote:
> >>
> >> On 12/7/2016 1:52 PM, Nick Østergaard wrote:
> >> > Yes, but lets use the windows use case. A user has 4.0.4 intalled and
> >> > have fp-lib-table that matches the one used there for local libs. He
> >> > then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an
> >> > update with a package manager and possibly osx too), the fp-lib-table
> >> > is a user preference and will now reference non existing pretty dirs.
> >> > The user starts pcbnew or cvpcb to add parts and when kicad tries to
> >> > access one of those libs that do not exist anymore he gets
> >> > "unexpected" errors.
> >> >
> >> > All I ask about is really; what is the desired action?
> >> >
> >> > I am ok with just including the rename, but I remember that at some
> >> > time we said that we should not remove libs for patch releases. This
> >> > would require a mention in the release note, which is probably also
> >> > acceptable.
> >>
> >> I believe keeping the library names the same for stable series releases
> >> was what we originally decided.  I'm OK with adding a note to the
> >> release notes for this one time.  In the future, we should probably
> >> create a release series branch for the libraries as we did with the
> >> source and cherry-pick changes as required.  I know it's extra work but
> >> this will keep users happy.  Hopefully there wont be many more 4 stable
> >> releases so it probably doesn't make sense to do this until the 5 stable
> >> release.
> >>
> >> >
> >> >
> >> > 2016-12-07 19:43 GMT+01:00 Carl Poirier :
> >> >> Well, if I use all the libs as local pretties, using the fp-lib-table
> >> >> that
> >> >> has been tagged the same will work, won't it? Do we want to support
> mix
> >> >> and
> >> >> matching tags?
> >> >>
> >> >> On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard 
> >> >> wrote:
> >> >>>
> >> >>> Well, the issue os the fact that if a user has choosen (one way or
> the
> >> >>> other) to use all of the local libs he needs to update the
> >> >>> fp-lib-table
> >> >>> manually. An option is to copy the renamed pretty fors to the old
> name
> >> >>> as to
> >> >>> not generate errors for the user.
> >> >>>
> >> >>>
> >> >>> Den 07/12/2016 13.21 skrev "Carl Poirier"  >:
> >> >>>
> >> >>> The KIGITHUB variable leads to Github. For using the pretties
> locally,
> >> >>> the
> >> >>> fp-lib-table.for-pretty has to be used instead, which is the one
> >> >>> that's
> >> >>> included by default in the stable release. Anyway, as I had
> mentioned
> >> >>> in
> >> >>> another thread very recently, the Github plugin is not even built in
> >> >>> the
> >> >>> stable release so I don't know how users can get into trouble.
> >> >>>
> >> >>> Carl
> >> >>>
> >> >>> On Dec 7, 2016 1:45 AM, "Nick Østergaard" 
> wrote:
> >> >>>>
> >> >>>> But this will not help if the user is using them locally. How is
> that
> >> >>>> supposed to be handled?
> >> >>>>
> >> >>>>

Re: [Kicad-developers] Release 4.0.5 tagged.

[Carl Poirier]

Aah, I see now. I had missed the part that the fp-lib-table didn't get
updated along the new install.

We indeed decided to keep the pretty names the same but with Github's
redirection, I missed the local uppgrade use case. What I can do is restore
a copy of the pretties with the old name. This way the newer pretties will
work with the old fp-lib-table.

Carl

On Wed, Dec 7, 2016 at 1:57 PM, Wayne Stambaugh 
wrote:

> On 12/7/2016 1:52 PM, Nick Østergaard wrote:
> > Yes, but lets use the windows use case. A user has 4.0.4 intalled and
> > have fp-lib-table that matches the one used there for local libs. He
> > then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an
> > update with a package manager and possibly osx too), the fp-lib-table
> > is a user preference and will now reference non existing pretty dirs.
> > The user starts pcbnew or cvpcb to add parts and when kicad tries to
> > access one of those libs that do not exist anymore he gets
> > "unexpected" errors.
> >
> > All I ask about is really; what is the desired action?
> >
> > I am ok with just including the rename, but I remember that at some
> > time we said that we should not remove libs for patch releases. This
> > would require a mention in the release note, which is probably also
> > acceptable.
>
> I believe keeping the library names the same for stable series releases
> was what we originally decided.  I'm OK with adding a note to the
> release notes for this one time.  In the future, we should probably
> create a release series branch for the libraries as we did with the
> source and cherry-pick changes as required.  I know it's extra work but
> this will keep users happy.  Hopefully there wont be many more 4 stable
> releases so it probably doesn't make sense to do this until the 5 stable
> release.
>
> >
> >
> > 2016-12-07 19:43 GMT+01:00 Carl Poirier :
> >> Well, if I use all the libs as local pretties, using the fp-lib-table
> that
> >> has been tagged the same will work, won't it? Do we want to support mix
> and
> >> matching tags?
> >>
> >> On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard 
> wrote:
> >>>
> >>> Well, the issue os the fact that if a user has choosen (one way or the
> >>> other) to use all of the local libs he needs to update the fp-lib-table
> >>> manually. An option is to copy the renamed pretty fors to the old name
> as to
> >>> not generate errors for the user.
> >>>
> >>>
> >>> Den 07/12/2016 13.21 skrev "Carl Poirier" :
> >>>
> >>> The KIGITHUB variable leads to Github. For using the pretties locally,
> the
> >>> fp-lib-table.for-pretty has to be used instead, which is the one that's
> >>> included by default in the stable release. Anyway, as I had mentioned
> in
> >>> another thread very recently, the Github plugin is not even built in
> the
> >>> stable release so I don't know how users can get into trouble.
> >>>
> >>> Carl
> >>>
> >>> On Dec 7, 2016 1:45 AM, "Nick Østergaard"  wrote:
> >>>>
> >>>> But this will not help if the user is using them locally. How is that
> >>>> supposed to be handled?
> >>>>
> >>>> 2016-12-07 0:46 GMT+01:00 Carl Poirier :
> >>>>> Hi Nick,
> >>>>>
> >>>>> I do understand but it is not an issue, Just try it out, go to
> >>>>> https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty.
> >>>>>
> >>>>> Carl
> >>>>>
> >>>>> On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard 
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi Carl
> >>>>>>
> >>>>>> I have found an issue with the lib tagging. I think we decided to
> not
> >>>>>> remove any libs for the patch releaes. That is for releases where
> only
> >>>>>> the third number changes. What I see is:
> >>>>>>
> >>>>>> Buttons_Switches_ThroughHole.pretty remaned to
> >>>>>> Buttons_Switches_THT.pretty
> >>>>>> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty
> >>>>>> Connect.pretty renamed to Connectors.pretty
> >>>>>> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty
> >>>>>> Sockets_WAGO734.pretty renamed t

Re: [Kicad-developers] Release 4.0.5 tagged.

[Carl Poirier]

Well, if I use all the libs as local pretties, using the fp-lib-table that
has been tagged the same will work, won't it? Do we want to support mix and
matching tags?

On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard  wrote:

> Well, the issue os the fact that if a user has choosen (one way or the
> other) to use all of the local libs he needs to update the fp-lib-table
> manually. An option is to copy the renamed pretty fors to the old name as
> to not generate errors for the user.
>
> Den 07/12/2016 13.21 skrev "Carl Poirier" :
>
> The KIGITHUB variable leads to Github. For using the pretties locally, the
> fp-lib-table.for-pretty has to be used instead, which is the one that's
> included by default in the stable release. Anyway, as I had mentioned in
> another thread very recently, the Github plugin is not even built in the
> stable release so I don't know how users can get into trouble.
>
> Carl
>
> On Dec 7, 2016 1:45 AM, "Nick Østergaard"  wrote:
>
>> But this will not help if the user is using them locally. How is that
>> supposed to be handled?
>>
>> 2016-12-07 <20%2016%2012%2007> 0:46 GMT+01:00 Carl Poirier <
>> carl.poirie...@gmail.com>:
>> > Hi Nick,
>> >
>> > I do understand but it is not an issue, Just try it out, go to
>> > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty.
>> >
>> > Carl
>> >
>> > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard 
>> wrote:
>> >>
>> >> Hi Carl
>> >>
>> >> I have found an issue with the lib tagging. I think we decided to not
>> >> remove any libs for the patch releaes. That is for releases where only
>> >> the third number changes. What I see is:
>> >>
>> >> Buttons_Switches_ThroughHole.pretty remaned to
>> Buttons_Switches_THT.pretty
>> >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty
>> >> Connect.pretty renamed to Connectors.pretty
>> >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty
>> >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty
>> >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty
>> >> Display.pretty renamed to Displays.pretty
>> >> Relays_ThroughHole.pretty renamed to Relays_THT.pretty
>> >> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty
>> >> Sockets_BNC.pretty removed?
>> >> Sockets_Mini-Universal.pretty renamed to Connectors_Mini-Universal.pret
>> ty
>> >>
>> >> Won't users have to manually update their fp-lib-table?
>> >>
>> >> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty  .
>> >> This looks correct, so that is ok.
>> >>
>> >> The fp-lib-table.for-pretty seems to match the repos tagged.
>> >>
>> >> Those renamed repos will easily summon errors in the users face. I
>> >> hope you understand what I mean.
>> >>
>> >> 2016-12-03 22:54 GMT+01:00 Carl Poirier :
>> >> > I will be tagging the libs in 24h.
>> >> >
>> >> > Carl
>> >> >
>> >> > On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> I'll take a look early this week!
>> >> >>
>> >> >> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh <
>> stambau...@gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Better late than never.  I just pushed the 4.0.5 stable release.
>> Just
>> >> >>> a
>> >> >>> note to the package devs, you no longer need to set the version
>> string
>> >> >>> at config.  You can use KICAD_VERSION_EXTRA to append any package
>> >> >>> specific information to the "4.0.5" version string.  This will also
>> >> >>> hold
>> >> >>> true when building from the source archive when I make the official
>> >> >>> announcement.  Hopefully it wont take more than a week or two to
>> get
>> >> >>> get
>> >> >>> documentation, libraries, and most of the packages ready.  Please
>> let
>> >> >>> me
>> >> >>> know so I can plan the release announcement.  Thank you everyone
>> for
>> >> >>> you
>> >> >>> efforts.
>> >> >>>

Re: [Kicad-developers] Release 4.0.5 tagged.

[Carl Poirier]

The KIGITHUB variable leads to Github. For using the pretties locally, the
fp-lib-table.for-pretty has to be used instead, which is the one that's
included by default in the stable release. Anyway, as I had mentioned in
another thread very recently, the Github plugin is not even built in the
stable release so I don't know how users can get into trouble.

Carl

On Dec 7, 2016 1:45 AM, "Nick Østergaard"  wrote:

> But this will not help if the user is using them locally. How is that
> supposed to be handled?
>
> 2016-12-07 0:46 GMT+01:00 Carl Poirier :
> > Hi Nick,
> >
> > I do understand but it is not an issue, Just try it out, go to
> > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty.
> >
> > Carl
> >
> > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard 
> wrote:
> >>
> >> Hi Carl
> >>
> >> I have found an issue with the lib tagging. I think we decided to not
> >> remove any libs for the patch releaes. That is for releases where only
> >> the third number changes. What I see is:
> >>
> >> Buttons_Switches_ThroughHole.pretty remaned to
> Buttons_Switches_THT.pretty
> >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty
> >> Connect.pretty renamed to Connectors.pretty
> >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty
> >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty
> >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty
> >> Display.pretty renamed to Displays.pretty
> >> Relays_ThroughHole.pretty renamed to Relays_THT.pretty
> >> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty
> >> Sockets_BNC.pretty removed?
> >> Sockets_Mini-Universal.pretty renamed to Connectors_Mini-Universal.pret
> ty
> >>
> >> Won't users have to manually update their fp-lib-table?
> >>
> >> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty  .
> >> This looks correct, so that is ok.
> >>
> >> The fp-lib-table.for-pretty seems to match the repos tagged.
> >>
> >> Those renamed repos will easily summon errors in the users face. I
> >> hope you understand what I mean.
> >>
> >> 2016-12-03 22:54 GMT+01:00 Carl Poirier :
> >> > I will be tagging the libs in 24h.
> >> >
> >> > Carl
> >> >
> >> > On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf
> >> > 
> >> > wrote:
> >> >>
> >> >> I'll take a look early this week!
> >> >>
> >> >> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh <
> stambau...@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> Better late than never.  I just pushed the 4.0.5 stable release.
> Just
> >> >>> a
> >> >>> note to the package devs, you no longer need to set the version
> string
> >> >>> at config.  You can use KICAD_VERSION_EXTRA to append any package
> >> >>> specific information to the "4.0.5" version string.  This will also
> >> >>> hold
> >> >>> true when building from the source archive when I make the official
> >> >>> announcement.  Hopefully it wont take more than a week or two to get
> >> >>> get
> >> >>> documentation, libraries, and most of the packages ready.  Please
> let
> >> >>> me
> >> >>> know so I can plan the release announcement.  Thank you everyone for
> >> >>> you
> >> >>> efforts.
> >> >>>
> >> >>> Cheers,
> >> >>>
> >> >>> Wayne
> >> >>>
> >> >>> ___
> >> >>> 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
> >> >
> >
> >
>
___
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] Release 4.0.5 tagged.

[Carl Poirier]

Hi Nick,

I do understand but it is not an issue, Just try it out, go to
https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty.

Carl

On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard  wrote:

> Hi Carl
>
> I have found an issue with the lib tagging. I think we decided to not
> remove any libs for the patch releaes. That is for releases where only
> the third number changes. What I see is:
>
> Buttons_Switches_ThroughHole.pretty remaned to Buttons_Switches_THT.pretty
> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty
> Connect.pretty renamed to Connectors.pretty
> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty
> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty
> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty
> Display.pretty renamed to Displays.pretty
> Relays_ThroughHole.pretty renamed to Relays_THT.pretty
> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty
> Sockets_BNC.pretty removed?
> Sockets_Mini-Universal.pretty renamed to Connectors_Mini-Universal.pretty
>
> Won't users have to manually update their fp-lib-table?
>
> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty  .
> This looks correct, so that is ok.
>
> The fp-lib-table.for-pretty seems to match the repos tagged.
>
> Those renamed repos will easily summon errors in the users face. I
> hope you understand what I mean.
>
> 2016-12-03 22:54 GMT+01:00 Carl Poirier :
> > I will be tagging the libs in 24h.
> >
> > Carl
> >
> > On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf  >
> > wrote:
> >>
> >> I'll take a look early this week!
> >>
> >> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh 
> >> wrote:
> >>>
> >>> Better late than never.  I just pushed the 4.0.5 stable release.  Just
> a
> >>> note to the package devs, you no longer need to set the version string
> >>> at config.  You can use KICAD_VERSION_EXTRA to append any package
> >>> specific information to the "4.0.5" version string.  This will also
> hold
> >>> true when building from the source archive when I make the official
> >>> announcement.  Hopefully it wont take more than a week or two to get
> get
> >>> documentation, libraries, and most of the packages ready.  Please let
> me
> >>> know so I can plan the release announcement.  Thank you everyone for
> you
> >>> efforts.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> ___
> >>> 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
> >
>
___
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] Github plugin not built in Ubuntu PPA

[Carl Poirier]

Hi Orson,

Yes I am talking about the 4.0 branch. Thanks for the explanation.

Carl

On Tue, Dec 6, 2016 at 3:36 AM, Maciej Sumiński 
wrote:

> Hi Carl,
>
> Do you mean PPA for the 4.0 branch? Recently I had troubles building the
> 4.0 branch with Github plugin enabled on Arch as well.
>
> Seemingly the problem is disabled SSLv3 support in Arch's OpenSSL
> package, which might be the case in Ubuntu as well. SSLv3 is used by
> avhttp to connect to Github. In the master branch, avhttp is already
> replaced with curl, which works fine.
>
> The 4.0 branch becomes tough to maintain, I do not know if backporting
> the curl patch is a simple task now.
>
> Regards,
> Orson
>
> On 12/06/2016 03:35 AM, Carl Poirier wrote:
> > Hi folks,
> >
> > I just noticed the Github plugin isn't built in the Ubuntu PPA. Why is
> > that? This is confusing, you can select "Github" as plugin type in the
> > fp-lib-table, but once you ask to browse the libs, an error pops out. I
> had
> > never noticed before because I was compiling from source, but anyway this
> > is definitely something that has to be enabled!
> >
> > Carl
> >
> >
> >
> > ___
> > 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] Github plugin not built in Ubuntu PPA

[Carl Poirier]

Hi folks,

I just noticed the Github plugin isn't built in the Ubuntu PPA. Why is
that? This is confusing, you can select "Github" as plugin type in the
fp-lib-table, but once you ask to browse the libs, an error pops out. I had
never noticed before because I was compiling from source, but anyway this
is definitely something that has to be enabled!

Carl
___
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] Release 4.0.5 tagged.

[Carl Poirier]

I will be tagging the libs in 24h.

Carl

On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf 
wrote:

> I'll take a look early this week!
>
> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh 
> wrote:
>
>> Better late than never.  I just pushed the 4.0.5 stable release.  Just a
>> note to the package devs, you no longer need to set the version string
>> at config.  You can use KICAD_VERSION_EXTRA to append any package
>> specific information to the "4.0.5" version string.  This will also hold
>> true when building from the source archive when I make the official
>> announcement.  Hopefully it wont take more than a week or two to get get
>> documentation, libraries, and most of the packages ready.  Please let me
>> know so I can plan the release announcement.  Thank you everyone for you
>> efforts.
>>
>> Cheers,
>>
>> Wayne
>>
>> ___
>> 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

Re: [Kicad-developers] 4.0.3 stable release last call.

[Carl Poirier]

All .pretty repositories featured in the fp-lib-table have been tagged as
well as the kicad-library repo. Other .pretty repositories should NOT be
packaged.

On Fri, Aug 5, 2016 at 9:39 AM, Wayne Stambaugh 
wrote:

> Thanks for the update Carl.
>
> On 8/4/2016 9:24 PM, Carl Poirier wrote:
> > Hi Wayne,
> >
> > I will be tagging all the library repositories tomorrow evening.
> >
> > Carl
> >
> >
> > On Aug 3, 2016 14:27, "Nick Østergaard"  > <mailto:oe.n...@gmail.com>> wrote:
> >
> > Thanks.
> >
> >
> > Den 03/08/2016 20.22 skrev "Wayne Stambaugh"  > <mailto:stambau...@gmail.com>>:
> >
> > My bad.  I thought this patch was part of a bug report.  I'll
> > commit it
> > and change the 4.0.3 tag.  This is the last non-critical bug fix
> for
> > 4.0.3.  Any other non-critical bugs can wait until the 4.0.4
> > release.
> >
> > On 8/3/2016 2:15 PM, Nick Østergaard wrote:
> > > I don't think it has been reported on the tracker, but that
> > doesn't mean
> > > it is not a bug ;)
> > >
> > >
> > > Den 03/08/2016 18.01 skrev "Wayne Stambaugh"
> > mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>:
> > >
> > > I got that but Nick mentioned a bug fix so I assumed that
> > it fixed a bug
> > > report.  Did r7000 fix a bug report or not?  If so, what
> > is the bug
> > > report number so I can link to it when I commit the stable
> > release fix.
> > >
> > > On 8/3/2016 11:52 AM, Chris Pavlina wrote:
> > > > He's referring to revision 7000.
> > > >
> > > > On Wed, Aug 03, 2016 at 11:41:36AM -0400, Wayne
> > Stambaugh wrote:
> > > >> Which bug does it fix?  It is not linked in the commit
> > and I did
> > > a quick
> > > >> search and I cannot find the bug in question.
> > > >>
> > > >> A reminder to my devs with commit access, please use
> > the bzr --fixes
> > > >> option when committing LP bug report fixes so I don't
> > have to go back
> > > >> and figure out which commit fixes which bug.
> > > >>
> > > >> On 8/3/2016 9:17 AM, Nick Østergaard wrote:
> > > >>> Hi Wayne
> > > >>>
> > > >>> Will it be possible to include the fix the the F.Silk
> > on new
> > > pads too?
> > > >>> I know it is not a segfault or anything similar, but I
> > still
> > > consider
> > > >>> it a bugfix.
> > > >>>
> > > >>>
> > >
> >
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/7000
> > > >>>
> > > >>> 2016-08-03 14:33 GMT+02:00 Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com
> >>>:
> > > >>>> If no one has any issues, I'm going to apply this
> > patch to the
> > > stable
> > > >>>> branch an tag r6298 as 4.0.3 instead of r6297.  I am
> > still
> > > planning on
> > > >>>> announcing the stable release over the weekend.  Let
> > me know if
> > > this is
> > > >>>> going to be a problem and I will push the stable
> > release back
> > > another
> > > >>>> week.  I'm guessing this will only effect our package
> > devs.
> > > >>>>
> > > >>>> Thanks,
> > > >>>>
> > > >>>> Wayne
> > > >>>>
> > > >>>> On 8/2/2016 7:00 PM, Nick Østergaard w

Re: [Kicad-developers] 4.0.3 stable release last call.

[Carl Poirier]

Hi Wayne,

I will be tagging all the library repositories tomorrow evening.

Carl

On Aug 3, 2016 14:27, "Nick Østergaard"  wrote:

Thanks.

Den 03/08/2016 20.22 skrev "Wayne Stambaugh" :

> My bad.  I thought this patch was part of a bug report.  I'll commit it
> and change the 4.0.3 tag.  This is the last non-critical bug fix for
> 4.0.3.  Any other non-critical bugs can wait until the 4.0.4 release.
>
> On 8/3/2016 2:15 PM, Nick Østergaard wrote:
> > I don't think it has been reported on the tracker, but that doesn't mean
> > it is not a bug ;)
> >
> >
> > Den 03/08/2016 18.01 skrev "Wayne Stambaugh"  > >:
> >
> > I got that but Nick mentioned a bug fix so I assumed that it fixed a
> bug
> > report.  Did r7000 fix a bug report or not?  If so, what is the bug
> > report number so I can link to it when I commit the stable release
> fix.
> >
> > On 8/3/2016 11:52 AM, Chris Pavlina wrote:
> > > He's referring to revision 7000.
> > >
> > > On Wed, Aug 03, 2016 at 11:41:36AM -0400, Wayne Stambaugh wrote:
> > >> Which bug does it fix?  It is not linked in the commit and I did
> > a quick
> > >> search and I cannot find the bug in question.
> > >>
> > >> A reminder to my devs with commit access, please use the bzr
> --fixes
> > >> option when committing LP bug report fixes so I don't have to go
> back
> > >> and figure out which commit fixes which bug.
> > >>
> > >> On 8/3/2016 9:17 AM, Nick Østergaard wrote:
> > >>> Hi Wayne
> > >>>
> > >>> Will it be possible to include the fix the the F.Silk on new
> > pads too?
> > >>> I know it is not a segfault or anything similar, but I still
> > consider
> > >>> it a bugfix.
> > >>>
> > >>>
> >
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/7000
> > >>>
> > >>> 2016-08-03 14:33 GMT+02:00 Wayne Stambaugh  > >:
> >  If no one has any issues, I'm going to apply this patch to the
> > stable
> >  branch an tag r6298 as 4.0.3 instead of r6297.  I am still
> > planning on
> >  announcing the stable release over the weekend.  Let me know if
> > this is
> >  going to be a problem and I will push the stable release back
> > another
> >  week.  I'm guessing this will only effect our package devs.
> > 
> >  Thanks,
> > 
> >  Wayne
> > 
> >  On 8/2/2016 7:00 PM, Nick Østergaard wrote:
> > > Hi
> > >
> > > Please be aware of this bug which causes a segfault. The issues
> > > appears both on recent product and 4.0.2.
> > > https://bugs.launchpad.net/kicad/+bug/1607430
> > >
> > > The reason have been found, but I am not sure if you would
> > consider
> > > the fix for inclusion in 4.0.3 at this stage.
> > >
> > > Nick
> > >
> > > 2016-07-09 18:07 GMT+02:00 Wayne Stambaugh
> > mailto:stambau...@gmail.com>>:
> > >> I'm making one last call for any last bug fixes for the
> > version 4 stable
> > >> branch before I tag 4.0.3.  If you are working on anything or
> > know of
> > >> anything that could be a show stopper, please let me know.  I
> > hope to
> > >> tag 4.0.3 early next week to give our doc devs and
> > translators a chance
> > >> to make any last changes before I roll out 4.0.3 and make the
> > announcement.
> > >>
> > >> Cheers,
> > >>
> > >> Wayne
> > >>
> > >> ___
> > >> 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
___
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] Eeschema : Component name auto-placement

[Carl Poirier]

Thank you very much for the tip.

Carl

On Sat, May 14, 2016 at 8:33 AM, jp charras  wrote:

> Le 14/05/2016 à 14:20, Carl Poirier a écrit :
> > Hi folks,
> >
> > It was pointed out to me that when you place a component on a schematic,
> > its name is automatically moved on top of it reagardless of the position
> it
> > it set to in the library. Is this a desired feature and if so, what is
> the
> > rationale behind it? Couldn't we have placed it on top right from the
> start
> > in the library instead?
> >
> > Regards,
> >
> > Carl
>
> Auto placement of fields is an option in Eeschema preferences.
> You can use or not this feature.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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] Eeschema : Component name auto-placement

[Carl Poirier]

Hi folks,

It was pointed out to me that when you place a component on a schematic,
its name is automatically moved on top of it reagardless of the position it
it set to in the library. Is this a desired feature and if so, what is the
rationale behind it? Couldn't we have placed it on top right from the start
in the library instead?

Regards,

Carl
___
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] [Pull-request] Github Footprints Library Repo

[Carl Poirier]

Hi,

We are a small team of librarians on Github. Please give us some time and
we'll get to your pull requests.

Thanks for your interest in contributing to KiCad.

Carl

On Sun, May 1, 2016 at 2:26 PM, Эльдар Хайруллин 
wrote:

> Hello.
> Who maintains github footprints library repos?
> I opened some pull-requests more than 20 days ago, maybe somebody who
> maintains repos looks my requests:
>
>
> *https://github.com/KiCad/Crystals.pretty/pull/8
>  
> https://github.com/KiCad/Converters_DCDC_ACDC.pretty/pull/3
>  *
>
> ___
> 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] plot component image from command line

[Carl Poirier]

Hi RIcardo,

That's a great idea. I haven't tried your patch yet, which revision is it
intended for?

I personally think it could be upstreamed but indeed not in its current
form. There is a similar option in the Part Library Editor in File->Create
PNG File from screen.

Carl

On Sat, Mar 19, 2016 at 1:23 PM, Ricardo Crudo 
wrote:

> Hello Everyone.
>
> I've attached a patch that allows to eeschema plot a PNG image from given
> library and component names via command line. First let me say that my
> intention is not to have this patch applied to upstream KiCad code, I wrote
> the patch exclusively to got this feature, I know it's wrong in many ways.
> My aim here is to use it as a tool to help us (librarians) with the
> evaluation of the users libraries pull requests at kicad-library.
>
> Ideally we would have a patched kicad version running over Jenkis,
> similiar with what Jon Neal has done for checking scripts.
>
> To test it, apply the patch and run as following:
>
> eeschema --component-png microchip_pic12mcu "PIC12(L)F1501-I/MC"
>
> You will see the eeschema window pop up and close automatically. After
> this an output.png file should have been plotted to local dir.
>
> I'm copying the developers mail list to ask a help to guide me where to
> tweak in order to prevent the windows to pop up (if possible). I've tried
> to comment out some Show and Raise methods but it didn't work out. I got a
> corrupted png and program did stop to close automatically.
>
>
> Best Regards,
> Ricardo.
>
> ___
> 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] [PATCH] Eeschema creating extra whitespace in .lib

[Carl Poirier]

I was mistaken in thinking I had commit rights to the repo. It's been a
long time but I now believe it might have been for the original kicad-lib
only! Can you commit it for me please?

Regards,

Carl

On Thu, Mar 17, 2016 at 5:05 AM, jp charras  wrote:

> Le 13/03/2016 22:00, Carl Poirier a écrit :
> > Hi folks,
> >
> > Working on the libraries, we noticed opening and saving back a lib with
> > KiCad creating a big diff mainly because of extra whitespace.
> >
> > The attached patch fixes this. I can commit it once I have the green
> light.
> >
> > Regards,
> >
> > Carl
>
> I do not see any problem.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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] [PATCH] Eeschema creating extra whitespace in .lib

[Carl Poirier]

Hi folks,

Working on the libraries, we noticed opening and saving back a lib with
KiCad creating a big diff mainly because of extra whitespace.

The attached patch fixes this. I can commit it once I have the green light.

Regards,

Carl
=== modified file 'eeschema/lib_polyline.cpp'
--- eeschema/lib_polyline.cpp	2015-11-03 19:44:05 +
+++ eeschema/lib_polyline.cpp	2016-03-13 20:45:09 +
@@ -63,7 +63,7 @@
 
 for( unsigned i = 0; i < GetCornerCount(); i++ )
 {
-aFormatter.Print( 0, "  %d %d", m_PolyPoints[i].x, m_PolyPoints[i].y );
+aFormatter.Print( 0, " %d %d", m_PolyPoints[i].x, m_PolyPoints[i].y );
 }
 
 aFormatter.Print( 0, " %c\n", fill_tab[m_Fill] );

=== modified file 'eeschema/lib_text.cpp'
--- eeschema/lib_text.cpp	2015-11-08 10:10:52 +
+++ eeschema/lib_text.cpp	2016-03-13 20:46:08 +
@@ -71,7 +71,7 @@
 text.Replace( wxT( " " ), wxT( "~" ) );
 }
 
-aFormatter.Print( 0, "T %g %d %d %d %d %d %d %s ", GetOrientation(), m_Pos.x, m_Pos.y,
+aFormatter.Print( 0, "T %g %d %d %d %d %d %d %s", GetOrientation(), m_Pos.x, m_Pos.y,
   m_Size.x, m_Attributs, m_Unit, m_Convert, TO_UTF8( text ) );
 
 aFormatter.Print( 0, " %s %d", m_Italic ? "Italic" : "Normal", ( m_Bold > 0 ) ? 1 : 0 );

___
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] Questionably useful code

[Carl Poirier]

Sooo:

- If the size is not specified, then assume it is 60mils
- From now on, default size is 50mils (as per KLC)
- From now on, never omit the size (or specify it in a header)

Then we have the backwards compatibility and contributors don't get caught
by submitting pull requests using a 60mils size.

This is great. Thanks Jon for tackling this.

Carl

On Fri, Mar 11, 2016 at 3:51 PM, Wayne Stambaugh 
wrote:

> I'm not opposed to adding a global font definition but adding the
> default parameters for every single text definition would be
> unacceptable.  I'm assuming you are going to include the font, weight,
> italics, orientation, etc. information to this as well as they all have
> default values which are currently not saved.
>
> On 3/11/2016 3:05 PM, Adam Wolf wrote:
> > I hope we don't add more things like this in the future.
> >
> > Adding a header to the file with "default font size is 60 mils" or
> > whatever, and setting omitted font size in the file to use the header
> > value, would add only a few bytes over what the current is--except there
> > wouldn't be a magic constant in KiCad we can't change without breaking
> > backwards compatibility.
> >
> > Adam Wolf
> >
> > On Fri, Mar 11, 2016 at 7:34 AM, Wayne Stambaugh  > > wrote:
> >
> > On 3/11/2016 2:55 AM, jp charras wrote:
> > > Le 11/03/2016 00:01, Jon Neal a écrit :
> > >> Oh, I should add that to prevent breaking backwards compatibility
> the
> > >> parser could just continue interpreting a missing size and
> thickness value
> > >> with the current defaults hard coded there.
> > >
> > > No problem for me to always store the text font size, especially in
> > > board and fp files.
> > >
> > > Of course, as you say, to avoid breaking backwards compatibility,
> the
> > > default values (when the size is missing) must be not modified.
> >
> > You cannot change the default values or anyone who used the default
> > value text size and line width will end up with changes to their
> board.
> >  How much of a problem this would be is questionable.  I doubt many
> > users use the default text size but it is the policy of the project
> not
> > to break backwards compatibility.  The short answer is you cannot
> > change it.
> >
> > >
> > > I am thinking this optimization was made more for the schematic
> (for new
> > > schematic file format using S expr) than for Pcbnew.
> >
> > The optimization is for the board because footprints are embedded in
> the
> > board file.  This can make a significant difference in board file
> size
> > on boards with lots of footprints.  It makes virtually no difference
> on
> > the footprint library files.  You are free to set them to whatever
> you
> > want.  If the footprint library devs decide to use something other
> than
> > the default for the all of the footprint text, I have no issues with
> > that.
> >
> > >
> > > In Pcbnew files, the thickness is never 0 and most of time the
> size of
> > > texts is not 60 mils.
> > >
> > > So we need the Wayne's opinion.
> > >
> > > But, to tell the true, I do not understand why changing this
> current
> > > code helps the library team.
> >
> > I honestly don't see what problem we are trying to solve. There is
> > nothing preventing you from using any text size you want in footprint
> > files.  You can always configure your footprint library editor to
> make
> > the default size for text to any value you would like.  That way you
> > don't have to go back and edit the text sizes after you create them.
> >
> > > In schematic files the text size is always stored.
> > >
> > > Adding an option in the component editor to set the default
> component
> > > text size (like for pin sizes) is better, very easy and allows
> > each user
> > > to choose this size.
> > > Moreover, this option could be different for ref and value and for
> > other
> > > fields (especially the footprint field, which could be smaller)
> > >
> > >>
> > >> On Thu, Mar 10, 2016 at 5:59 PM Jon Neal  > > wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I was looking in to helping the library team by changing the
> > default kicad
> > >>> text size to 50 mils rather than the current 60 mils.
> > >>>
> > >>> Well, I discovered that the s-expr formatter and parser omits
> > certain text
> > >>> settings if they are the default. I assume this is to make kicad
> > files
> > >>> smaller which yay, but it means that we basically can't change
> > the default
> > >>> text size without breaking backwards compatibility. Huge,
> > resounding BO.
> > >>>
> > >>> What I would like to request is that we remove the bit of code
> > that omits
> > >>> text size and thickness if they are default

Re: [Kicad-developers] 3D plugin for STEP/IGES via OCE

[Carl Poirier]

As I was saying in the other thread, I am in favor of committing the STEP
models into our repositories. I suggest in the process we separate them
from the kicad-library repo. I mean having a repository only for 3D models
instead of being part of kicad-library. We could set the 3D repo as a
submodule to the kicad-library to ease transition. This would make sense,
as the STEP models are over 4 times bigger than the VRML ones. Then, we
could get the right people onboard a new team, the 3D team, to fill this
new repository.

On Thu, Mar 10, 2016 at 8:17 AM, Wayne Stambaugh 
wrote:

> Before I would allow OCE as a KiCad dependency, it must build without
> modification from source on OSX, msys2/mingw32 and msys2/mingw64 at a
> minimum.  If it fails this test, then someone will have to provide
> packages for these platforms.  Has this been tested?
>
> On 3/10/2016 4:11 AM, Cirilo Bernardo wrote:
> > Hi folks,
> >
> >  I have a 3D plugin built to support STEP and IGES visualization via OCE
> > and have linked 3 screenshots below.
> >
> > https://drive.google.com/open?id=0By_XTJN-s8aXS1pKSE5uNVp0VG8
> > https://drive.google.com/open?id=0By_XTJN-s8aXclV4enBueWhnaGM
> > https://drive.google.com/open?id=0By_XTJN-s8aXclV4enBueWhnaGM
> >
> >  The HackRF STEP model was created by Maurice via his KiCad StepUP
> > tools for FreeCAD.
> >
> >  If people would like this plugin to be pushed into 3d_initial_merge then
> > let me know; I would need to add a CMake option to build it since it
> > depends on OCE and should not be built by default. Just remember that
> > these models will not be visible in 3DViewer until the current 3DViewer
> > has been replaced by one which uses the scenegraph objects from
> > 3d_initial_merge.  Mario is making a lot of progress with his 3DViewer
> > branch, so hopefully it won't be too long before we have all the latest
> > 3D visualization codes. :)
> >
> >  One note: although the new 3D viewer will be able to directly use the
> > STEP/IGES models (no need to convert to VRML), actual MCAD
> > exports is still a long way away since it depends on the implementation
> > of a plugin system for reading and manipulating the PCB data itself.
> >
> >  Thanks to Tom Wlostowski for the initial OCE investigations and his
> > sample c++ code for converting STEP to VRML.
> >
> > - Cirilo
> >
> >
> >
> > ___
> > 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

[Kicad-developers] Fwd: [Kicad-lib-committers] Quality on current 3D models and MCAD formats on KiCad

[Carl Poirier]

Hi folks,

I'm forwarding from the kicad-lib-committers mailing list to here a message
from Mario Luzeiro in the hope of gathering more interest.

My opinion on the matter is it would be great to commit the STEP models
directly to the kicad-library. Maybe in the process we could separate the
formers from the latter? I mean having a repository only for 3D models
instead of being part of kicad-library. We could set the 3D repo as a
submodule to the kicad-library to ease transition. Then, we could get the
right people onboard a new team, the 3D team, to fill this new repository.

As for the improper material values, I guess we could fix most of them
using scripts like we did for the symbols in kicad-library.

Regards,

Carl


-- Forwarded message --
From: Mário Luzeiro 
Date: Fri, Feb 26, 2016 at 5:36 AM
Subject: [Kicad-lib-committers] Quality on current 3D models and MCAD
formats on KiCad
To: "kicad-lib-committ...@lists.launchpad.net" <
kicad-lib-committ...@lists.launchpad.net>


Hello all,

Thanks for Carl Poirier to add me here to the mailing list.

I am Mario Luzeiro, I am contributing in last years to the KiCad 3D-Viewer.
I am recently working in the 3D-Viewer refactor with Cirilo (3D plugins for
load 3d files)
https://code.launchpad.net/~mrluzeiro/kicad/kicad_new3d-viewer


There are two points I was looking to discuss hopping that we can have a
better 3d (default) library on Kicad.

The first point is about the "quality" of the 3d model files (VRML models)

One of the most important are the (bad) materials that are assigned in the
VRML files.
I made recently a tutorial where I explain some of this issues in the
models and how to assigned proper material values:
https://forum.kicad.info/t/tutorial-and-guidelines-for-better-materials-on-3d-models/2321
Basically, they have improper values for "emissive", "shininess", etc..
Some also may have a bad normals in the models and would be better that
kicad calculate it the normals by itself.


The second point is that I found an increase for the use of MCAD (eg: STEP
format) models that can be used later for mechanical validation.
I know that there are some authors that are develop some models in STEP and
then export for the VRML format that kicad can support.
They have interest in add their contributions for the kicad library:
https://github.com/KiCad/kicad-library/issues/186
So this proposal would be to accept still the VRML file but with other
(other than WINGs) formats that can be used for MCAD proposes.


This two points together could contribute for a better quality and support
of the kicad 3D default library,
so it could be used with 3rd part softwars for mechanical validation (the
VRML format is not proper for mechanical validation since there are no
units )

Are you open to discuss some of this points and if we can do something to
improve the 3D model library of KiCad ?

I am available to give some help or guidance in order to see this points
improved on KiCad.
Since I am working in a new 3D-Viewer render, the quality of models will
have a high importance to get good looking renders. So in order to see my
work to shine, the models have to be shining too! ;)

Regards,
Mario Luzeiro
--
Mailing list: https://launchpad.net/~kicad-lib-committers
Post to : kicad-lib-committ...@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-lib-committers
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] Stable release 4.0.2

[Carl Poirier]

Tagging only X.0.0 for kicad-library could work. As for the pretties, we
desperately need some popup warning the user to update the fp-lib-table if
some Github repositories are not found.

On Fri, Feb 19, 2016 at 7:57 AM, Wayne Stambaugh 
wrote:

> I just checked and the library has been tagged with 4.0.2 but there were
> changes to device.lib since 4.0.1.  It looks like the POT component was
> resized which most likely will fire a component recovery for users who
> have POTs in their schematics.  I think we should ship component
> libraries that do not trigger a recovery during the 4 series stable
> releases so it looks like you should pull the 4.0.1 library for
> packaging for the remainder of version 4 stable releases.  I'll see if I
> can come up with a reasonable policy to eliminate confusion in the
> future.  We probably should just tag the library at X.0.0 when the
> stable version is released and use that for the entire stable release
> series to prevent any surprises for the user.  The other option is to
> create separate library packages and let the user assume the risk when
> updating the libraries.
>
> On 2/19/2016 1:39 AM, Nick Østergaard wrote:
> > I need a clear answer. If we don't want to update, then we shall move
> > the tag on the libs to the 4.0.1 tag on the libs.
> >
> > 2016-02-15 19:36 GMT+01:00 Wayne Stambaugh :
> >> I'm not sure how much of a difference it makes with the github libraries
> >> since the contents of the libraries can change even if you don't update
> >> your fp-lib-table.  Shipping the updated fp-lib-table wont make any
> >> difference unless the user chooses to copy the new one.  The schematic
> >> libraries however are a different matter.  We should probably keep those
> >> the same through out the entire stable 4 release series rather than
> >> breaking users schematics.  I know Chris's rescue code goes a long way
> >> in mitigating this issue but I would still like to avoid users having to
> >> rescue a schematic during a stable release series.
> >>
> >> On 2/15/2016 1:29 PM, Carl Poirier wrote:
> >>> The pretty repository with the old name still exists for as long as
> >>> needed. My question is about having lib differences between bugfix
> >>> releases. In this case, the fp-lib-table will be updated so that 4.0.3
> >>> will use the renamed lib whereas 4.0.2 uses the old lib.
> >>>
> >>> Regards,
> >>>
> >>> Carl
> >>>
> >>> On Mon, Feb 15, 2016 at 2:40 AM, Nick Østergaard  >>> <mailto:oe.n...@gmail.com>> wrote:
> >>>
> >>> 2016-02-14 17:07 GMT+01:00 Carl Poirier  >>> <mailto:carl.poirie...@gmail.com>>:
> >>> > We have some new libraries to add to the fp-lib-table and one to
> rename. If
> >>> > we do so now, when we'll be tagging 4.0.3, it will include the
> changes.
> >>> >
> >>> > Would this be permitted in such a release? If not, what about
> version 4.1?
> >>>
> >>> I am not exactly sure, but what about we just do not perform the
> >>> rename (for the release), but just add the new ones, then there is
> >>> little change for the user to experience errors, or am I mistaken?
> >>>
> >>> > On Sun, Feb 14, 2016 at 7:10 AM, Nick Østergaard
> >>> mailto:oe.n...@gmail.com>> wrote:
> >>> >>
> >>> >> 2016-02-14 12:18 GMT+01:00 Nick Østergaard  >>> <mailto:oe.n...@gmail.com>>:
> >>> >> > Ok, so we tag the latest snapshot of the libraries as
> suggested
> >>> by the
> >>> >> > librarians, and will do the same with the docs to get the
> >>> latest fixes
> >>> >> > and translations there too.
> >>> >> >
> >>> >> > Wayne, I wonder why you tagged the release kicad-4.0.2 instead
> >>> of just
> >>> >> > 4.0.2 as you did for 4.0.0 and 4.0.1.
> >>> >>
> >>> >> Hmm, I think that is just a name set in the lp web ui, which
> can be
> >>> >> edited.
> >>> >>
> >>> >> > 2016-02-13 22:59 GMT+01:00 Wayne Stambaugh
> >>> mailto:stambau...@gmail.com>>:
> >>> >> >> Did we tag 4.0.1?  I thought we just tagged 4.0 and used it
> >>> for 4.0.1
> >>> >

Re: [Kicad-developers] Stable release 4.0.2

[Carl Poirier]

The pretty repository with the old name still exists for as long as needed.
My question is about having lib differences between bugfix releases. In
this case, the fp-lib-table will be updated so that 4.0.3 will use the
renamed lib whereas 4.0.2 uses the old lib.

Regards,

Carl

On Mon, Feb 15, 2016 at 2:40 AM, Nick Østergaard  wrote:

> 2016-02-14 17:07 GMT+01:00 Carl Poirier :
> > We have some new libraries to add to the fp-lib-table and one to rename.
> If
> > we do so now, when we'll be tagging 4.0.3, it will include the changes.
> >
> > Would this be permitted in such a release? If not, what about version
> 4.1?
>
> I am not exactly sure, but what about we just do not perform the
> rename (for the release), but just add the new ones, then there is
> little change for the user to experience errors, or am I mistaken?
>
> > On Sun, Feb 14, 2016 at 7:10 AM, Nick Østergaard 
> wrote:
> >>
> >> 2016-02-14 12:18 GMT+01:00 Nick Østergaard :
> >> > Ok, so we tag the latest snapshot of the libraries as suggested by the
> >> > librarians, and will do the same with the docs to get the latest fixes
> >> > and translations there too.
> >> >
> >> > Wayne, I wonder why you tagged the release kicad-4.0.2 instead of just
> >> > 4.0.2 as you did for 4.0.0 and 4.0.1.
> >>
> >> Hmm, I think that is just a name set in the lp web ui, which can be
> >> edited.
> >>
> >> > 2016-02-13 22:59 GMT+01:00 Wayne Stambaugh :
> >> >> Did we tag 4.0.1?  I thought we just tagged 4.0 and used it for 4.0.1
> >> >> but I'm not sure.  I don't think the docs have any of the new stuff
> >> >> like
> >> >> the one button board update yet so it may be OK to tag the docs
> 4.0.2.
> >> >>
> >> >> On 2/13/2016 4:56 PM, Nick Østergaard wrote:
> >> >>> I expect we tag a new snapshot of the libraries and docs again.
> >> >>>
> >> >>> 2016-02-13 22:51 GMT+01:00 Wayne Stambaugh :
> >> >>>> Just a heads up, stable version 4.0.2 has been released.  This is a
> >> >>>> bug
> >> >>>> fix release so when the build devs get a chance, please create
> builds
> >> >>>> for the new stable release packages.  Thank you everyone for your
> >> >>>> efforts to make this possible.
> >> >>>>
> >> >>>> Cheers,
> >> >>>>
> >> >>>> Wayne
> >> >>>>
> >> >>>> ___
> >> >>>> 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

Re: [Kicad-developers] Stable release 4.0.2

[Carl Poirier]

We have some new libraries to add to the fp-lib-table and one to rename. If
we do so now, when we'll be tagging 4.0.3, it will include the changes.

Would this be permitted in such a release? If not, what about version 4.1?

On Sun, Feb 14, 2016 at 7:10 AM, Nick Østergaard  wrote:

> 2016-02-14 12:18 GMT+01:00 Nick Østergaard :
> > Ok, so we tag the latest snapshot of the libraries as suggested by the
> > librarians, and will do the same with the docs to get the latest fixes
> > and translations there too.
> >
> > Wayne, I wonder why you tagged the release kicad-4.0.2 instead of just
> > 4.0.2 as you did for 4.0.0 and 4.0.1.
>
> Hmm, I think that is just a name set in the lp web ui, which can be edited.
>
> > 2016-02-13 22:59 GMT+01:00 Wayne Stambaugh :
> >> Did we tag 4.0.1?  I thought we just tagged 4.0 and used it for 4.0.1
> >> but I'm not sure.  I don't think the docs have any of the new stuff like
> >> the one button board update yet so it may be OK to tag the docs 4.0.2.
> >>
> >> On 2/13/2016 4:56 PM, Nick Østergaard wrote:
> >>> I expect we tag a new snapshot of the libraries and docs again.
> >>>
> >>> 2016-02-13 22:51 GMT+01:00 Wayne Stambaugh :
>  Just a heads up, stable version 4.0.2 has been released.  This is a
> bug
>  fix release so when the build devs get a chance, please create builds
>  for the new stable release packages.  Thank you everyone for your
>  efforts to make this possible.
> 
>  Cheers,
> 
>  Wayne
> 
>  ___
>  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

Re: [Kicad-developers] Stable release 4 is out!

[Carl Poirier]

The kicad-library repository and all non-empty .pretty repositories have
been tagged as well!

Congrats to everyone. It's a great day today!

Carl Poirier

On Sun, Nov 29, 2015 at 4:19 PM, Adam Wolf 
wrote:

> Wonderful!  Thanks all!
>
> I should be able to push the button on an OS X download tonight, and I'll
> sanity check and then push it again with the proper fancy name tomorrow :)
>
> Adam Wolf
>
> On Sun, Nov 29, 2015 at 3:17 PM, Wayne Stambaugh 
> wrote:
>
>>
>>
>> On 11/29/2015 04:05 PM, Nick Østergaard wrote:
>> > 2015-11-29 21:39 GMT+01:00 Wayne Stambaugh :
>> >> I just finished rolling out KiCad 4.0.0.  Many thanks to everyone who
>> >> made this possible.  Each and every one of you deserve to sit back and
>> >> enjoy this accomplishment.  I have a few minor requests before I make a
>> >> trip to my refrigerator to grab a cold one to celebrate.
>> >>
>> >> Someone please add an announcement the to blog page on the KiCad
>> website?
>> >
>> > Yes, I am on it. It will be available shortly.
>>
>> Thanks.
>>
>> >
>> >> The footprint, symbol and 3D model library, documentation, and
>> >> translation repos need to be tagged 4.0.0 so future package builds can
>> >> pull the proper version.  At some point in the future we may need to
>> >> create 4.0.0 branches of the library, documentation, and translation
>> >> repos but for now the tags should suffice.  Please do not make any
>> >> commits to these repos until after they are tagged.
>> >
>> > Commiting should not prevent you to tag commits in git, and I don't
>> > even think so in bzr. :)
>>
>> You are correct.  I had a brain cramp.  You just have to remember which
>> commit needs to be tagged if you make any commits after the announcement.
>>
>> >
>> >> What do we need to do as far as creating automated builds for the
>> >> correct version of the documentation?  I know packagers on some
>> >> platforms will need pre-built documentation for the 4.0 release.  This
>> >> shouldn't be a significant issue until we start documenting new
>> features
>> >> during the next development cycle.
>> >
>> > I am planning to just build the latest docs and make them available on
>> > downloads.kicad-pcb.org/docs/kicad-doc.{tar.gz,zip}
>> <http://downloads.kicad-pcb.org/docs/kicad-doc.%7Btar.gz,zip%7D> or
>> something.
>>
>> Thanks.
>>
>> >
>> >> Please do not swamp me with patches and new feature merge requests over
>> >> the next few days.  I have some of my own coding that I need to get
>> done
>> >> for the next development cycle so I'm not going to have a lot of time
>> to
>> >> do code reviews and I would like to reduce the number hours a week I've
>> >> been spending working on KiCad for a few weeks.
>> >
>> > Thank you for finally calling the release.
>> >
>> >> Thanks again everyone!
>> >>
>> >> Cheers,
>> >>
>> >> Wayne
>>
>> ___
>> 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

Re: [Kicad-developers] Stable release update.

[Carl Poirier]

I'll let you manage it on KiCad's side and I'll take care of tagging.

On Sat, Nov 28, 2015 at 5:03 AM, Nick Østergaard  wrote:

> I vote for tagging, I don't think we will have much use of branching the
> libs. When they are tagged on all repos we can easily fetch a consistent
> package, and we can provide that as a download for those who wants that. I
> can tag them if you want.
> Den 28/11/2015 01.08 skrev "Carl Poirier" :
>
>> So what was the decision for tying the libraries to the release? Tagging
>> or branching? Who's managing it?
>>
>> On Mon, Nov 23, 2015 at 9:00 PM, Carl Poirier 
>> wrote:
>>
>>> Hi,
>>>
>>> This is just to warn you that the fp-lib-tables have been updated and
>>> the deprecated pretty repos have been removed.
>>>
>>> I'm still waiting for a peer reviewer to do a spot-check for the 50mils
>>> field text size update.
>>>
>>> Regards,
>>>
>>> Carl
>>>
>>> On Tue, Nov 17, 2015 at 2:01 PM, Wayne Stambaugh 
>>> wrote:
>>>
>>>> That was quick.  Thanks.
>>>>
>>>> On 11/17/2015 8:58 AM, Marco Ciampa wrote:
>>>> > On Tue, Nov 17, 2015 at 08:35:41AM -0500, Wayne Stambaugh wrote:
>>>> >> Would you please make "KiCad Stable Release Policy" and
>>>> >> link to
>>>> >>
>>>> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_stable-release-policy.html
>>>> >> when you get a chance?
>>>> >
>>>> > Done.
>>>> >
>>>>
>>>> ___
>>>> 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

Re: [Kicad-developers] Stable release update.

[Carl Poirier]

So what was the decision for tying the libraries to the release? Tagging or
branching? Who's managing it?

On Mon, Nov 23, 2015 at 9:00 PM, Carl Poirier 
wrote:

> Hi,
>
> This is just to warn you that the fp-lib-tables have been updated and the
> deprecated pretty repos have been removed.
>
> I'm still waiting for a peer reviewer to do a spot-check for the 50mils
> field text size update.
>
> Regards,
>
> Carl
>
> On Tue, Nov 17, 2015 at 2:01 PM, Wayne Stambaugh 
> wrote:
>
>> That was quick.  Thanks.
>>
>> On 11/17/2015 8:58 AM, Marco Ciampa wrote:
>> > On Tue, Nov 17, 2015 at 08:35:41AM -0500, Wayne Stambaugh wrote:
>> >> Would you please make "KiCad Stable Release Policy" and
>> >> link to
>> >>
>> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_stable-release-policy.html
>> >> when you get a chance?
>> >
>> > Done.
>> >
>>
>> ___
>> 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] Stable release update.

[Carl Poirier]

Hi,

This is just to warn you that the fp-lib-tables have been updated and the
deprecated pretty repos have been removed.

I'm still waiting for a peer reviewer to do a spot-check for the 50mils
field text size update.

Regards,

Carl

On Tue, Nov 17, 2015 at 2:01 PM, Wayne Stambaugh 
wrote:

> That was quick.  Thanks.
>
> On 11/17/2015 8:58 AM, Marco Ciampa wrote:
> > On Tue, Nov 17, 2015 at 08:35:41AM -0500, Wayne Stambaugh wrote:
> >> Would you please make "KiCad Stable Release Policy" and
> >> link to
> >>
> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_stable-release-policy.html
> >> when you get a chance?
> >
> > Done.
> >
>
> ___
> 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] Release - licenses and legal issues

[Carl Poirier]

On Wed, Nov 18, 2015 at 9:10 AM, Wayne Stambaugh 
wrote:
>
>
> Before I spend too much time on the library licensing, do any of the
> library developers have any objections to the wording in the geda
> license?  The nice thing about using an exception like the geda project
> used is we can still keep the GPL license everywhere.  I think it works
> nicely with the intent of the libraries that the KiCad project provides.
>
> Cheers,
>
> Wayne


Sounds good to me.
___
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] Stable release update.

[Carl Poirier]

Thanks for the reminder Michal. We'll do that as well.

On Mon, Nov 16, 2015 at 12:00 PM, Eldar Khayrullin  wrote:

> Hello.
> I have included patch that update RU translator list.
>
> ___
> 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] Stable release update.

[Carl Poirier]

Aah right, Google has guessed I needed the date for the latter more than
the former. :-P

It will be updating quite a good chunk of the symbols maybe up to half of
them, but the only thing changing is the field text size. It does not break
anything.

On Sun, Nov 15, 2015 at 8:11 PM, Adam Wolf 
wrote:

> Carl,
>
> Between Canadian Thanksgiving and American Thanksgiving I'll move mine to
> the day KiCad 4.0.0 comes out...
>
> How many symbols does that change, about?
>
> Adam Wolf
> Cofounder and Engineer
> Wayne and Layne
>
> On Sun, Nov 15, 2015 at 7:09 PM, Carl Poirier 
> wrote:
>
>> Isn't thanksgiving in 11 months from now?
>>
>> Before then, with this
>> <https://github.com/KiCad/kicad-library-utils/pull/10> I'll be setting
>> all the symbol libraries field text sizes to 50mils.
>>
>> Carl
>>
>> On Sun, Nov 15, 2015 at 6:55 PM, Wayne Stambaugh 
>> wrote:
>>
>>> Fingers crossed but the rc2 noise has been fairly low so if no critical
>>> bugs are reported between now and Thanksgiving weekend, I'll roll out
>>> the stable release sometime that weekend.  If you have any last minute
>>> bug fixes, documentation changes, or library improvements to make, now
>>> is the time.  I'll give everyone a 24hr notice before I tag the source,
>>> doc, library, and translation repos with 4.0.0 when I roll out the
>>> release.  From there we can branch if the need be.  Hopefully one of
>>> things we will have to be thankful for this Thanksgiving holiday is a
>>> new KiCad stable release.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> ___
>>> 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

Re: [Kicad-developers] Stable release update.

[Carl Poirier]

Isn't thanksgiving in 11 months from now?

Before then, with this
 I'll be setting all
the symbol libraries field text sizes to 50mils.

Carl

On Sun, Nov 15, 2015 at 6:55 PM, Wayne Stambaugh 
wrote:

> Fingers crossed but the rc2 noise has been fairly low so if no critical
> bugs are reported between now and Thanksgiving weekend, I'll roll out
> the stable release sometime that weekend.  If you have any last minute
> bug fixes, documentation changes, or library improvements to make, now
> is the time.  I'll give everyone a 24hr notice before I tag the source,
> doc, library, and translation repos with 4.0.0 when I roll out the
> release.  From there we can branch if the need be.  Hopefully one of
> things we will have to be thankful for this Thanksgiving holiday is a
> new KiCad stable release.
>
> Cheers,
>
> Wayne
>
> ___
> 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] A question for library devs.

[Carl Poirier]

Hi,

Indeed, this dates back from the beginning of the KLC. The question about
origin had been discussed on both the kicad-lib-committers and the
developers mailing list. Here
 is some of the
archives. I hope this helps.

Regards,

Carl

On Thu, Oct 1, 2015 at 3:43 PM, nnn  wrote:

> I can see the rule about origins is on initial commit of kicad library
> convention (may 2014) so the origins are changing with newer commits.
> About changes: some of .pretty libraries are going to be removed because
> some of footprints were sorted to reduce the mess in official libraries.
>
>
> W dniu 01.10.2015 o 16:29, Wayne Stambaugh pisze:
>
> While I was fixing the broken 3D models on the interf_u demo, I noticed
>> that reference point (0,0) for many if not all of the through hole
>> footprints and models is now pin 1 of the footprint instead of the
>> physical center of the footprint.  When did this change take place?  I'm
>> pretty sure reference point used to be the physical center of the
>> footprint because I had to recenter (and rotate some) many of the
>> through hole footprints on the interf_u demo.  I thought that I
>> mentioned this before about announcing library changes like this to a
>> least the developers list.  I don't use through hole components very
>> often but I also don't like being blindsided by unexpected changes.  In
>> the future, when there are policy changes to the library structure or
>> footprint defaults that effect users, please give everyone (this
>> probably should include users) a heads up.
>>
>> Thanks,
>>
>> Wayne
>>
>> ___
>> 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

Re: [Kicad-developers] Can I move values in footprints library back to silkscreen?

[Carl Poirier]

Could the plot values checkbox be fixed easily? Since it's a "fix" I
suggest it for integration in 4.0.

On Thu, Sep 3, 2015 at 5:42 PM, yann jautard  wrote:

>
>
>
> Le 03/09/2015 23:01, Jean-Paul Louis a écrit :
>
>> Hi nnn,
>>
>> I do not understand your point about having values on the PCB. NOBODY in
>> the industry put values on the PCB.
>>
>
>
> I disagree, I have a few examples of recent industrial boards with values
> on them. Last one I've seen is an inverter welder.
> I do electronic troubleshooting and getting such a board with values
> written down is really a pleasant thing when you don't have any
> documentation on the device, and when you can't get value from the part
> themselves because for some reason they've burned during the failure.
>
> So for that reason I also put values on silkscreen on my own boards.
>
> I really can't see the point of moving values to another layer. There is a
> checkbox to plot or not the values on the silkscreen layer. Now that
> checkbox does nothing, and this is pretty confusing. Leave values on
> silkscreen layer and if you dont need them, just do not check the option,
> where is the problem ?
>
> And if you need a Fab layer with the values... ok there is a problem you
> can't get it. Well then for that particular purpose, there should be a way
> in the plot window to output several layers in a single file like there is
> in the print window.
>
> In fact, I think the three windows "plot", "print" and "export SVG" need
> some rework to combine them all in a single one, because each of them have
> features that can be needed in some ways to achieve a particular thing. Now
> the example is adding values on silkscreen even if they are on a different
> layer : you can't get it from the plot window, but you can do it with the
> export SVG or print one using the single file output checkbox, and
> selecting silk and fab layer. But on the other hand, from these windows you
> can't get a gerber file...
>
> regards,
> yann
>
> To facilitate the assembly, a lot of companies I worked for used a FAB
>> drawing with one inch grid, and then generate a list of parts with the
>> location on the grid. That’s more than enough to locate a part when
>> troubleshooting.
>> You can do the same easily.
>>
>> Just my $0.02,
>> Jean-Paul
>> AC9GH
>>
>>
>>
>> On Sep 3, 2015, at 3:32 PM, nnn  wrote:
>>>
>>> I don't want remove refdes from silkscreen - just add a copy (text %R)
>>> scaled to footprints size - this layer really helps when you need to find
>>> component from schematic on a pcb (if you don't have computer with your
>>> design in a lab).
>>>
>>>
>>> W dniu 03.09.2015 o 21:25, Andy Peters pisze:
>>>
 On Sep 3, 2015, at 11:06 AM, nnn  wrote:
>
> Some time ago after short discussion on librarians mailing list it was
> decided to change default reference and value fields of footprints and 
> move
> values to F.Fab layer.
> I think it was bad decision. I'm asking here to get more opinions.
>
 For the value fields, putting them on the Fab layer is fine. As Chris
 notes, pretty much nobody prints the values on the board but having them on
 an assembly or fab drawing helps the human who’s stuffing the board.

 I think having the reference designators on any non-silkscreen layer is
 a mistake.  If the ref-des is on the F.Fab layer, your generated Gerbers
 won’t have them on the F.SilkS (or B.Silks) layer, but rather on the Fab
 layer — and the PCB fab guys will probably bounce your design back because
 they won’t know how to make a silkscreen out of stuff on the F.Fab layer,
 especially when a silkscreen layer already exists in the package!

 And to make matters worse, if you had older parts in your library or a
 design which had the ref-deses all on the F.SilkS layer, and you add new
 footprints which have the ref-des on the F.Fab layer, your Gerbers will be
 all confused, since some parts will show a ref-des on the silkscreen and
 some won’t.

 I think it’s a matter of expectations: EVERYONE expects the reference
 designators to be on a silkscreen layer.

 -a
 ___
 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.l

Re: [Kicad-developers] Wizard to download 3D shape libs from Github

[Carl Poirier]

Hi Jean-Pierre,

It works great on my side. The only comment I have is when we click on the
"Default 3D Path" button, nothing seems to happen. I suggest writing the
value of KISYS3DMOD into the path textbox.

This should be included into the stable release. Then, it will be easy for
anybody to keep their libraries up to date and it will simplify the
librarian's duties.

On Sun, Aug 16, 2015 at 3:23 PM, jp charras  wrote:

> Le 13/08/2015 21:20, jp charras a écrit :
> > I wrote a wizard to download our 3D shape libs from our Github KiCad
> repo.
> >
> > For guys who are interested at testing this wizard, here is a patch.
> >
> > Although it works fine, it has an issue: the download process is very
> slow.
> >
> > It uses a "brute force":
> > It reads the main web page of packages3d to extract the URL of all
> > .3dshapes folders available, and read the web page of each .3dshapes
> > folder selected and read the URLs of 3D shape files.
> > Then it reads and download all .wrl and .wings files (usually large
> > files) found in selected folders.
> >
> > So if someone knows a way to speed up these downloads from Github, let
> > me know *exactly* how to do that.
> >
> > (I am not a specialist of Github).
>
> This patch replaces the previous patch.
> It fixes 2 issues on Linux.
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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] official web page

[Carl Poirier]

Hi Maurice,

I suggest you open up a pull request to include your script in
https://github.com/KiCad/kicad-library-utils.

Regards,

Carl

On Wed, Aug 5, 2015 at 3:40 PM, Marcos Chaparro 
wrote:

> Hi Maurice,
> I'm not that Marco and I'm not involved in documentation, but this week I
> tested your script and its really nice. It is key to have a repository of
> wrl+step models, it was a bit painful to get the step models for an old
> project but once the setup is ready the workflow is good.
>
> I'd suggest to include in the tutorial the creation of a simple part in
> freecad, it took me a while to realize that it doesn't handle well multiple
> part objects, and I still can't fuse parts while preserving the colors.
>
> I made a DCDC converter step model, a buzzer and downloaded a SO16 step.
> I'm not sure where to get open source models so we can add them to your
> repo. Freecad has some models, for example
> /free-cad-code/src/Mod/Idf/lib/0805_SMD.stp they could be bettery though.
>
> Thanks a lot for this work.
>
>
>
>
> Marcos
>
> On Wed, Aug 5, 2015 at 9:27 AM, Wayne Stambaugh 
> wrote:
>
>> Maurice,
>>
>> I think Marco is currently on vacation.  The new documentation format is
>> asciidoc.  You can use git to clone the current documentation at
>> https://github.com/ciampix/kicad-doc.  Information on how to use
>> asciidoc can be found at http://www.methods.co.nz/asciidoc/
>>
>> Wayne
>>
>> On 8/5/2015 8:23 AM, easyw wrote:
>> > @Marco
>> >
>> > what could I do to prepare a small tutorial for the kicad stepup script?
>> > do you accept libre-office file or pdf file?
>> > I'm sorry but I'm new to the doc side :)
>> >
>> > thank you
>> > Maurice
>> >
>> > On 17/07/2015 15.12, Wayne Stambaugh wrote:
>> >> On 7/17/2015 3:36 AM, Mário Luzeiro wrote:
>> >>> Excellent!
>> >>>
>> >>> Do you (all) think should be nice to have a small step tutorial /
>> >>> explanation how can someone reproduce identical results for another
>> >>> boards?
>> >>
>> >> Yes.  Any help we can provide our users is a good thing.  Something
>> like
>> >> this should be added to the user documentation either as part of the
>> >> Pcbnew manual or as a stand alone tutorial.  I don't have a preference
>> >> one way or another so I'll leave that decision to our documentation
>> >> experts.
>> >>
>> >>>
>> >>> Mario Luzeiro
>> >>> 
>> >>> From: Kicad-developers
>> >>> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on
>> >>> behalf of easyw [ea...@katamail.com]
>> >>> Sent: 17 July 2015 02:43
>> >>> To: Marcos Chaparro; KiCad Developers
>> >>> Subject: Re: [Kicad-developers] official web page
>> >>>
>> >>> Hi Marcos and all,
>> >>>
>> >>> it took me a bit but here is the hackrf-one generated with STEP models
>> >>> by kicad stepup script and the hackrf-one in kicad 3d-viewer with all
>> >>> the 3d-models generated from the conversion of the STEP models.
>> >>> I also checked the geometries of the generated board with models and
>> >>> there are no problems ...
>> >>>
>> >>> The rendering result shows that the two scenarios are exactly the
>> same,
>> >>> and I didn't get any problem in rendering all the vrml models in
>> kicad.
>> >>>
>> >>> generating the 3D modes in FreeCAD will produce a vrml 3D models with
>> no
>> >>> shading issues and with mechanical respect of all the dimensions
>> >>>
>> >>> It would be nice if some of these screenshots could be in the official
>> >>> web page...
>> >>>
>> >>> please let me know what you think
>> >>>
>> >
>> > ___
>> > 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
>
>
___
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] Stable release update.

[Carl Poirier]

> I'd like this
 to be
merged. In a few words, it consists of merging some libraries dating back
from pre-github
> era into two cleaner ones: TO_SOT_Packages_SMD.pretty and
TO_SOT_Packages_THT.pretty. Possibly
> also renaming the _ThroughHole suffix to _THT for the other libraries.

Hi,

This is just to let you guys know that this has been merged. The
repositories to be deleted will be kept a while although they are marked as
deprecated. You should see no issue if you wait to update your
kicad-library and fp-lib-table.

Regards,

Carl

On Sun, Jun 21, 2015 at 12:21 PM, Wayne Stambaugh 
wrote:

> On 6/20/2015 4:21 PM, Chris Pavlina wrote:
> > On Sat, Jun 20, 2015 at 09:14:14PM +0100, David J S Briscoe wrote:
> >> [snip] I'm afraid I will screw up the files on Github so probably
> >> better for me to do it the old fashioned way. Who can I send the edited
> >> files to?
> >
> > If you do this, someone will have to convert them back to AsciiDoc *by
> > hand*. The AsciiDoc is the original source now. You'll have to learn
> > git.
> >
> > --
> > Chris
>
> The official documentation is now https://github.com/KiCad/kicad-doc.
> Please do not make any changes to the legacy .odt documentation on
> launchpad as it will surely get lost.
>
> >
> >
> > ___
> > 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

Re: [Kicad-developers] [PATCH] Skip redundant repetition of component name in component chooser

[Carl Poirier]

Hi,

This is just to let you know that this has been merged. Sorry for it taking
so long.

Regards,

Carl

On Fri, Jun 26, 2015 at 3:20 PM, Wayne Stambaugh 
wrote:

> Indeed!  In fact my couple of beer suggestion is sounding like a pretty
> good idea right about now. :)
>
> On 6/26/2015 3:11 PM, Adam Wolf wrote:
> > Not only does no good deed go unpunished, every change breaks someone's
> > workflow :)
> >
> > https://xkcd.com/1172/
> >
> > Adam Wolf
> > Cofounder and Engineer
> > W&L
> >
> > On Fri, Jun 26, 2015 at 2:09 PM, Wayne Stambaugh  > > wrote:
> >
> > On 6/26/2015 2:59 PM, Vesa Solonen wrote:
> > > 26/06/15, 21:54, Adam Wolf kirjoitti:
> > >> I think it is unfortunate that a request to the library
> maintainers
> > >> requested by Wayne is responded to with a one line dismissal of:
> > >>
> > >> "You know my opinion and it is immutable. Sorry."
> > >>
> > >> Adam Wolf
> > >> Cofounder and Engineer
> > >> W&L
> > >>
> > >> On Fri, Jun 26, 2015 at 11:08 AM, Henner Zeller  
> > >> >> wrote:
> > >
> > >> ... Looks like library maintainers don't like it; see thread
> here:
> > >> https://github.com/KiCad/kicad-library/pull/231
> > >>
> > >> -h
> > >
> > > Give it two days to sink in. Friday evenings may not be the best
> time
> > > either... ;)
> > >
> > > -Vesa
> > >
> >
> > Two days and a couple of beers. :)
> >
> > I'm going to avoid a pissing contest at this juncture in order to
> focus
> > on the stable release.  I understand where Kerusey's frustration is
> > coming from.  No one wants to see their efforts removed from the
> project
> > but his response is not in the best interest of the project even if
> he
> > is correct.  Henner, could you rework your patch to include a
> checkbox
> > to hide the redundant description field information in your component
> > search dialog.  Please make the default setting disabled so no one
> has a
> > stroke.  No good deed goes unpunished.  Sig!
> >
> >
> > ___
> > 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

Re: [Kicad-developers] Stable release update.

[Carl Poirier]

>
> Libraries:
>
> If there are any last minute changes to the symbol, footprint, and/or 3D
> model libraries, now is the time to get that done.  We should probably
> tag the library repos when we release the stable branch so the packagers
> can pull the same libraries if the need be.
>

I'd like this 
to be merged. In a few words, it consists of merging some libraries dating
back from pre-github era into two cleaner ones: TO_SOT_Packages_SMD.pretty
and TO_SOT_Packages_THT.pretty. Possibly also renaming the _ThroughHole
suffix to _THT for the other libraries.
___
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] Caching the github footprints with Nginx

[Carl Poirier]

Hi folks,

In case you didn't notice it, Orson committed a configuration for the nginx
http server here
.
Dick is the author of it. This email is to report the excellent performance
I am getting here using Nginx as a local cache. This makes the Github
plugin even more attractive now as it got waaay faster. I encourage you all
to try it out.

Regards,

Carl
___
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] CvPcb change.

[Carl Poirier]

Hi Nick,

All is fine here on Xubuntu x64.

Also, thanks to Dick for the contribution.

Regards,

Carl

On Sun, Jun 7, 2015 at 7:44 PM, Wayne Stambaugh 
wrote:

> Thanks Adam.  I tested it on windows and I'm sure Dick tested it on linux.
>
>
> On 6/7/2015 6:45 PM, Adam Wolf wrote:
> > I can test OS X this week.
> >
> > On Jun 7, 2015 3:25 PM, "Wayne Stambaugh"  > > wrote:
> >
> > I just checked both 32 and 64 bit builds on windows and I don't have
> any
> > issues no matter how I launch pcbnew, KiCad, EEschema, or stand
> alone.
> >
> > On 6/7/2015 4:11 PM, Nick Østergaard wrote:
> > > I just tied to pull those changes, but now I get a segfault when
> > > starting pcbnew from the kicad app.
> > >
> > > I could possibly be some other stuff that I did not revert in my
> > > workspace before the build. The backtrace looks funny:
> > > http://dpaste.com/0DF8RP8
> > >
> > > Could anyone just try to verify weather or not it crashes if you
> start
> > > kicad with a project and then open pcbnew form there?I guess
> this
> > > should preferable be tested on a linux system to verify. (Trace
> looks
> > > gtk related)
> > >
> > > 2015-06-07 20:20 GMT+02:00 Wayne Stambaugh  > >:
> > >> I just committed a patch (r5718) from Dick that should greatly
> > simplify
> > >> the process of footprint assignment using cvpcb.  This patch does
> > away
> > >> with using the intermediate *.cmp file and directly updates the
> > s-expr
> > >> netlist via kiway express messaging.  This means there is no more
> > stand
> > >> alone executable of cvpcb.  This also means that you will have to
> use
> > >> the s-expr netlist when importing in pcbnew.  If you do not
> normally
> > >> back import the footprint assignments from the *.cmp file into
> > eeschema,
> > >> you will have to do this before your run cvpcb because the s-expr
> > >> netlist will not contain the footprint assignments until you do
> this.
> > >> This patch will eliminate one more unnecessary step when assigning
> > >> footprints and streamline the process.  I still need to fix the
> save
> > >> tooltip in the cvpcb toolbar since the *.cmp file does not get
> > saved.  I
> > >> also need to remove the read footprints from *.cmp file in the
> pcbnew
> > >> import netlist dialog since the *.cmp can no longer be generated
> by
> > >> cvpcb.  Going forward, the *.cmp file will only be useful for back
> > >> importing from pcbnew to eeschema.  At some point in the future,
> even
> > >> that will go away.j  Please test this and let me know if you find
> any
> > >> issues.
> > >>
> > >> Cheers,
> > >>
> > >> Wayne
> > >>
> > >> ___
> > >> 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
>
___
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] Library Developers.

[Carl Poirier]

HI folks,

This is just to let you know the splitting and removal of the special.lib
happened minutes ago. Only a handful of parts have been updated in the
process and there should be no synchronization problem between it and the
footprint libraries.

Have a great day,

Carl

On Mon, Mar 23, 2015 at 1:49 PM, Kerusey Karyu  wrote:

>
> Hi everyone.
>
> Let me express few words about changes in the symbol libraries.
>
> At the moment there are no major changes in the naming of the
> current symbol library files. Together with GitHub users we added
> and we are planning to add a few new ones.
>
> One library is provided for the liquidation in near future from the
> current library set: 'special.lib', as it has become a kind of garbage
> dump (IMO). The discussion is here:
> https://github.com/KiCad/kicad-library/issues/153
>
> Last year, only one library has been removed: 'microchip1.lib', as
> I remember.
>
>
> The biggest changes are taking place within the existing libraries.
> The establishment of strict rules written in the KiCad Library
> Convention document forces far-reaching changes in symbols
> including also those in existing libraries. Refresh the older
> schematics will unfortunately be *necessary*. Many existing symbols
> were drawn without any rules. That's why they look the way they do.
>
>
> We realize that such changes will be immediately negative commented
> and might be refused by users, but unfortunately we have no choice.
> Along with the improvement of the quality of KiCad as an EDA Tool
> we have to go to improve the quality of libraries contained therein.
>
>
> Best Regards
> Kerusey Karyu
>
> ___
> 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] UPDATE: Diode pins swapped in KiCad Libraries

[Carl Poirier]

What if we have a "Never show on startup" checkbox LOL.

No seriously, this indeed would be great for not only libraries but
anything else. The website will need a section for the news as well, which
currently from what I see doesn't have.

On Fri, Apr 24, 2015 at 10:38 PM, Adam Wolf 
wrote:

> Carl and other library folks,
>
> I understand you had to make the change, and I'm certain it took hard work
> to make everything match, and I'm glad that the libraries are better now,
> but I hate the fact that many, many users will never be notified of this
> board-breaking change, and we have absolutely no way of notifying them.
>
> Rather than make a github-plugin specific change that will only alert
> users about changes in footprints, I think we should see if we can quickly
> code a dialog that checks a location on kicad-pcb.org for news, and
> display it on KiCad startup by default if it has changed.  I would like to
> get this in before the stable release, but I know we're already in feature
> freeze.  Wayne, what do you think?
>
> Adam Wolf
> Cofounder and Engineer
> Wayne and Layne, LLC
>
> On Fri, Apr 24, 2015 at 9:25 PM, Carl Poirier 
> wrote:
>
>> Hi Adam,
>>
>> Indeed, those who want to be sure nothing changes until they want so are
>> better to make a local copy. With the new Footprint Libraries Wizard, users
>> are just a few clicks away from it with the checkbox "Save a local copy
>> to". Using the libraries directly from Github is bleeding-edge, but as you
>> said the problem arises from the fact that we have symbols installed
>> locally and footprints fetched from Github. If both are handled the same
>> way, either way it is, it will be fine. And again this causes problems only
>> for aspects of libraries that have to be in sync - such as pin numbers. The
>> other things that have to be in sync are the 3D models. That's why many
>> folks, including me, have suggested
>> <https://lists.launchpad.net/kicad-developers/msg14793.html> to move the
>> 3D model inside the .pretty library. Maybe it could be done elegantly, but
>> unfortunately I'm not the one who has enough time to put in this.
>>
>> As for the other libraries, we're slowly getting to a stable and
>> consistent state. Besides eradicating the special.lib library, I can't
>> think of another disruptive change that will happen soon. I'm not saying
>> there will be none, just that there are none planned. We go as our time
>> permits.
>>
>> As for why people would use KiCad's libraries, I'd say because they can
>> be assured at least two librarians go over a suggested change to iron out
>> errors. Also because new parts are constantly thrown into the mix as well
>> so the libraries are getting more complete over time. As for the quality of
>> the pre-github era libraries, nothing can be vouched. We're fixing things
>> as we find them. What's great is that with Github, it's very easy for those
>> people in doubt about KiCad's libraries to contribute and make them better
>> if they think there is room for it.
>>
>> I should have warned in advance here for this change specifically to make
>> sure everyone was aware. I should have not relied on the fact that no one
>> disagreed days ago about having disruptive changes in general. Besides
>> that, I'm not sure what more could have been done.
>>
>> Regards,
>>
>> Carl
>>
>> On Fri, Apr 24, 2015 at 8:43 PM, Adam Wolf > > wrote:
>>
>>> Carl,
>>>
>>> I have had multiple people contact me today saying, "Why would I ever
>>> use KiCad's libraries again?"
>>>
>>> I had no idea before your email today that diodes were going to change,
>>> and I follow the dev list daily, and I'm the packager for the OS X
>>> nightlies.
>>>
>>> We're in this together.  I don't have time to check yet another place
>>> for KiCad changes.
>>>
>>> After I think about this some more, I'm going to start another thread on
>>> what this means for the OS X nightlies.  By having half the data burned in,
>>> and half the data updated live, this is going to continue to happen.
>>> People are going to make bad boards, and if I would have bundled the
>>> footprints with the nightlies and not made Github the default, this
>>> wouldn't have happened.
>>>
>>> Most of the other packages are like this, right?
>>>
>>> Adam Wolf
>>>
>>> Cofounder and Engineer
>>>

Re: [Kicad-developers] KiCad Github Plugin Required Features

[Carl Poirier]

Jean-Paul, thanks for the first congratulations we get. Ricardo Crudo is
the one who deserves it.

Adam, I fully agree this can be better. I had suggested in the other thread
to make a branch of each .pretty repository for each stable release. Then,
the github plugin fetches that branch according to the software version. I
don't think more branching/tagging than that is necessary once we have the
first stable release.

It shouldn't be too hard to implement either.

Carl

On Fri, Apr 24, 2015 at 10:21 PM, Adam Wolf 
wrote:

> Jean-Paul,
>
> I don't think anyone has complained on this list about the change
> happening--neither I nor Garth have.  No one has proposed rolling it back.
>
> The complaint isn't that diodes now fit a standard--that's better than
> before!
>
> The issue is that there is now mismatch between live footprints and user's
> installed schematic symbols, and there isn't a good way to communicate this
> to our users.  How many users follow the user mailing list?  Under 1%?
> Under 0.1%?  While posting on the users lists is necessary, it is not
> sufficient!
>
> There are relatively simple technical solutions to communicate these
> changes to users, and for some reason (certainly not for my blood pressure)
> I'm volunteering to spend even more time on this project.
>
> Adam Wolf
> Cofounder and Engineer
> Wayne and Layne, LLC
>
> On Fri, Apr 24, 2015 at 9:02 PM, Jean-Paul Louis  wrote:
>
>> Hi Adam,
>>
>> I do not see why the change in the library to make it compatible with
>> other CAD packages, and IPC standards is a bad thing.
>> Since the beginning, I always used my own library for diodes because they
>> were broken in the KiCad library.
>> At least now, I will be able to use the "standard” library.
>>
>> People who are complaining are just whiners. Everybody in the Pro world
>> use pin 1 as the cathode of a diode. Our libraries were backward god knows
>> why.
>> We should thank the person who took the pain to fix it, instead of
>> whining.
>>
>> Just my $0.02,
>> Jean-Paul
>> AC9GH
>>
>> > On Apr 24, 2015, at 9:01 PM, Adam Wolf 
>> wrote:
>> >
>> > Hi folks,
>> >
>> > Git has tags and branches and a bunch of features to stop issues like
>> this from happening.
>> >
>> > One easy way I think we can stop this from ever happening again:
>> instead of always running off the newest commits to master, the github
>> plugin could use a tag or a commit, and then when folks decide to update,
>> we can parse and tell them what libraries changed and how, through metadata
>> and commit messages, and they can choose when to update.
>> >
>> > This would stop changes in footprints from breaking users' boards due
>> to static library files.
>> >
>> > Thoughts?
>> >
>> > Adam Wolf
>> > Cofounder and Engineer
>> > Wayne and Layne, LLC
>> > ___
>> > 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

Re: [Kicad-developers] UPDATE: Diode pins swapped in KiCad Libraries

[Carl Poirier]

Hi Adam,

Indeed, those who want to be sure nothing changes until they want so are
better to make a local copy. With the new Footprint Libraries Wizard, users
are just a few clicks away from it with the checkbox "Save a local copy
to". Using the libraries directly from Github is bleeding-edge, but as you
said the problem arises from the fact that we have symbols installed
locally and footprints fetched from Github. If both are handled the same
way, either way it is, it will be fine. And again this causes problems only
for aspects of libraries that have to be in sync - such as pin numbers. The
other things that have to be in sync are the 3D models. That's why many
folks, including me, have suggested
<https://lists.launchpad.net/kicad-developers/msg14793.html> to move the 3D
model inside the .pretty library. Maybe it could be done elegantly, but
unfortunately I'm not the one who has enough time to put in this.

As for the other libraries, we're slowly getting to a stable and consistent
state. Besides eradicating the special.lib library, I can't think of
another disruptive change that will happen soon. I'm not saying there will
be none, just that there are none planned. We go as our time permits.

As for why people would use KiCad's libraries, I'd say because they can be
assured at least two librarians go over a suggested change to iron out
errors. Also because new parts are constantly thrown into the mix as well
so the libraries are getting more complete over time. As for the quality of
the pre-github era libraries, nothing can be vouched. We're fixing things
as we find them. What's great is that with Github, it's very easy for those
people in doubt about KiCad's libraries to contribute and make them better
if they think there is room for it.

I should have warned in advance here for this change specifically to make
sure everyone was aware. I should have not relied on the fact that no one
disagreed days ago about having disruptive changes in general. Besides
that, I'm not sure what more could have been done.

Regards,

Carl

On Fri, Apr 24, 2015 at 8:43 PM, Adam Wolf 
wrote:

> Carl,
>
> I have had multiple people contact me today saying, "Why would I ever use
> KiCad's libraries again?"
>
> I had no idea before your email today that diodes were going to change,
> and I follow the dev list daily, and I'm the packager for the OS X
> nightlies.
>
> We're in this together.  I don't have time to check yet another place for
> KiCad changes.
>
> After I think about this some more, I'm going to start another thread on
> what this means for the OS X nightlies.  By having half the data burned in,
> and half the data updated live, this is going to continue to happen.
> People are going to make bad boards, and if I would have bundled the
> footprints with the nightlies and not made Github the default, this
> wouldn't have happened.
>
> Most of the other packages are like this, right?
>
> Adam Wolf
>
> Cofounder and Engineer
>
> Wayne and Layne, LLC
>
> (resending from an email that can post to kicad-dev...)
>
> On Fri, Apr 24, 2015 at 7:42 PM, Adam Wolf  wrote:
>
>> Carl,
>>
>> I have had multiple people contact me today saying, "Why would I ever use
>> KiCad's libraries again?"
>>
>> I had no idea before your email today that diodes were going to change,
>> and I follow the dev list daily, and I'm the packager for the OS X
>> nightlies.
>>
>> We're in this together.  I don't have time to check yet another place for
>> KiCad changes.
>>
>> After I think about this some more, I'm going to start another thread on
>> what this means for the OS X nightlies.  By having half the data burned in,
>> and half the data updated live, this is going to continue to happen.
>> People are going to make bad boards, and if I would have bundled the
>> footprints with the nightlies and not made Github the default, this
>> wouldn't have happened.
>>
>> Most of the other packages are like this, right?
>>
>> Adam Wolf
>>
>> Cofounder and Engineer
>>
>> Wayne and Layne, LLC
>>
>> On Apr 24, 2015 7:01 PM, "Carl Poirier"  wrote:
>>
>>> Then you should have come by and discussed the matter on Github. The
>>> issues and pull requests about the diodes had been open for a while now and
>>> open for comments. To get updates in time about the changes proposed, I
>>> suggest you watch this repository
>>> <https://github.com/KiCad/kicad-library>.
>>>
>>> If you have suggestions for the next similar situation, I'm listening.
>>>
>>> On 

Re: [Kicad-developers] UPDATE: Diode pins swapped in KiCad Libraries

[Carl Poirier]

Then you should have come by and discussed the matter on Github. The issues
and pull requests about the diodes had been open for a while now and open
for comments. To get updates in time about the changes proposed, I suggest
you watch this repository <https://github.com/KiCad/kicad-library>.

If you have suggestions for the next similar situation, I'm listening.

On Fri, Apr 24, 2015 at 7:55 PM, Garth Corral  wrote:

> I don’t object to what you’re doing, just how it’s being done.  You don’t
> think this case is just a little bit special?  Last time things were pretty
> obviously broken with the change, in this case they’re not.  You’ve swapped
> out a symbol for something that’s basically the same except, oh, by the
> way, all your diodes are reversed.  Am I misunderstanding this change?  Is
> this not true?
>
> Garth
>
> On Apr 24, 2015, at 4:34 PM, Carl Poirier 
> wrote:
>
> KiCad's libraries were filled without any rules throughout time. All these
> changes are necessary to have something consistent. Kerusey Karyu warned
> people one month ago on the mailing list
> <https://lists.launchpad.net/kicad-developers/msg17476.html> that we were
> in the process of moving things around. No one complained. Now why when we
> take action people wake up all of a sudden?
>
> The sooner we get things straight, the better it is. If we wait too much,
> it will be too late. Before issuing the stable release sounds like an
> appropriate moment to land the disruptive changes.
>
> BTW, I'm about to eradicate the special.lib library, as planned for now
> over one month <https://github.com/KiCad/kicad-library/issues/153>, a
> great initiative taken by Kerusey.
>
> Regards,
>
> Carl
>
> On Fri, Apr 24, 2015 at 7:21 PM, Garth Corral  wrote:
>
>>
>> This plan to deprecate the old diode type seems… uh... poorly thought
>> out.  Yanking these out from under everyone and every project in exiistence
>> and then sending out a message that says, “hey, guess what I did?” doesn’t
>> seem like the best way to handle this.  It is most certainly not the way to
>> win converts to kicad.
>>
>>
>> Garth
>>
>>
>> On Apr 24, 2015, at 2:31 PM, Carl Poirier 
>> wrote:
>>
>> Thiadmer, your proposal would require to duplicate every .pretty
>> repository for every stable release. And I believe the schematics won't
>> change because of the cache.
>>
>> Another solution would be to modify the github plugin to fetch a branch
>> in particular instead of the master. Then, we could create one branch in
>> each .pretty repository that would remain in the state at the time of the
>> stable release.
>>
>> That, or we ship the stable release with local .pretty repositories as
>> well.
>>
>> On Fri, Apr 24, 2015 at 3:20 PM, Thiadmer Riemersma <
>> thiadmer.riemer...@gmail.com> wrote:
>>
>>> For the stable release, I would vote for backward compatibility: have
>>> "deprecated" libraries with the diodes as they are right now (footprints +
>>> symbols), plus "standards-compliant" libraries with the cathode at pin 1
>>> and the anode at pin 2. It would not be good if old schematics change just
>>> because they are loaded in a new version of KiCad.
>>>
>>>
>>> On Fri, Apr 24, 2015 at 7:31 PM, Carl Poirier 
>>> wrote:
>>>
>>>> Maybe this could be implemented for the stable release.
>>>>
>>>> On Fri, Apr 24, 2015 at 1:30 PM, Bob Gustafson  wrote:
>>>>
>>>>>  Sounds professional.
>>>>>
>>>>> Bob G
>>>>>
>>>>>
>>>>> On 04/24/2015 12:24 PM, Adam Wolf wrote:
>>>>>
>>>>> For future things like this, what do people think of a webview that
>>>>> pops up on startup after checking a site for alerts?
>>>>> On Apr 24, 2015 12:14 PM, "Carl Poirier" 
>>>>> wrote:
>>>>>
>>>>>> All installations need a local kicad-library, not just OS X. They are
>>>>>> all in the same situation. The next OS X nightly will be good if you pull
>>>>>> the latest kicad-libary for the build.
>>>>>>
>>>>>>  Kerusey Karyu will announce the change on the users group on Yahoo
>>>>>> to warn people. If anyone has an account and wants to forward my message
>>>>>> before he does, feel free to do so.
>>>>>>
>>>>>> On Fri, Apr 24, 2015 at 12:55 PM, Adam Wolf <
>>>>>> adamw...@

Re: [Kicad-developers] UPDATE: Diode pins swapped in KiCad Libraries

[Carl Poirier]

KiCad's libraries were filled without any rules throughout time. All these
changes are necessary to have something consistent. Kerusey Karyu warned
people one month ago on the mailing list
<https://lists.launchpad.net/kicad-developers/msg17476.html> that we were
in the process of moving things around. No one complained. Now why when we
take action people wake up all of a sudden?

The sooner we get things straight, the better it is. If we wait too much,
it will be too late. Before issuing the stable release sounds like an
appropriate moment to land the disruptive changes.

BTW, I'm about to eradicate the special.lib library, as planned for now
over one month <https://github.com/KiCad/kicad-library/issues/153>, a great
initiative taken by Kerusey.

Regards,

Carl

On Fri, Apr 24, 2015 at 7:21 PM, Garth Corral  wrote:

>
> This plan to deprecate the old diode type seems… uh... poorly thought
> out.  Yanking these out from under everyone and every project in exiistence
> and then sending out a message that says, “hey, guess what I did?” doesn’t
> seem like the best way to handle this.  It is most certainly not the way to
> win converts to kicad.
>
>
> Garth
>
>
> On Apr 24, 2015, at 2:31 PM, Carl Poirier 
> wrote:
>
> Thiadmer, your proposal would require to duplicate every .pretty
> repository for every stable release. And I believe the schematics won't
> change because of the cache.
>
> Another solution would be to modify the github plugin to fetch a branch in
> particular instead of the master. Then, we could create one branch in each
> .pretty repository that would remain in the state at the time of the stable
> release.
>
> That, or we ship the stable release with local .pretty repositories as
> well.
>
> On Fri, Apr 24, 2015 at 3:20 PM, Thiadmer Riemersma <
> thiadmer.riemer...@gmail.com> wrote:
>
>> For the stable release, I would vote for backward compatibility: have
>> "deprecated" libraries with the diodes as they are right now (footprints +
>> symbols), plus "standards-compliant" libraries with the cathode at pin 1
>> and the anode at pin 2. It would not be good if old schematics change just
>> because they are loaded in a new version of KiCad.
>>
>>
>> On Fri, Apr 24, 2015 at 7:31 PM, Carl Poirier 
>> wrote:
>>
>>> Maybe this could be implemented for the stable release.
>>>
>>> On Fri, Apr 24, 2015 at 1:30 PM, Bob Gustafson  wrote:
>>>
>>>>  Sounds professional.
>>>>
>>>> Bob G
>>>>
>>>>
>>>> On 04/24/2015 12:24 PM, Adam Wolf wrote:
>>>>
>>>> For future things like this, what do people think of a webview that
>>>> pops up on startup after checking a site for alerts?
>>>> On Apr 24, 2015 12:14 PM, "Carl Poirier" 
>>>> wrote:
>>>>
>>>>> All installations need a local kicad-library, not just OS X. They are
>>>>> all in the same situation. The next OS X nightly will be good if you pull
>>>>> the latest kicad-libary for the build.
>>>>>
>>>>>  Kerusey Karyu will announce the change on the users group on Yahoo
>>>>> to warn people. If anyone has an account and wants to forward my message
>>>>> before he does, feel free to do so.
>>>>>
>>>>> On Fri, Apr 24, 2015 at 12:55 PM, Adam Wolf <
>>>>> adamw...@feelslikeburning.com> wrote:
>>>>>
>>>>>> Hmm.
>>>>>>
>>>>>> So the OSX builds use Github by default for footprints, and have
>>>>>> symbols "baked in" at build time.
>>>>>>
>>>>>> Every OS X nightly build is going to produce bad boards, and there's
>>>>>> no way to tell users to update or inform them about this change through 
>>>>>> the
>>>>>> program at all.
>>>>>>
>>>>>> I really wish I would have known about this earlier.
>>>>>>
>>>>>> Adam Wolf
>>>>>> Cofounder and Engineer
>>>>>> Wayne and Layne
>>>>>>  On Apr 24, 2015 11:42 AM, "Carl Poirier" 
>>>>>> wrote:
>>>>>>
>>>>>>>  Hi folks,
>>>>>>>
>>>>>>>  This is simply to warn you that all diodes in KiCad's libraries
>>>>>>> have seen their pin numbers swapped. This is to be in line with most 
>&g

Re: [Kicad-developers] UPDATE: Diode pins swapped in KiCad Libraries

[Carl Poirier]

Thiadmer, your proposal would require to duplicate every .pretty repository
for every stable release. And I believe the schematics won't change because
of the cache.

Another solution would be to modify the github plugin to fetch a branch in
particular instead of the master. Then, we could create one branch in each
.pretty repository that would remain in the state at the time of the stable
release.

That, or we ship the stable release with local .pretty repositories as well.

On Fri, Apr 24, 2015 at 3:20 PM, Thiadmer Riemersma <
thiadmer.riemer...@gmail.com> wrote:

> For the stable release, I would vote for backward compatibility: have
> "deprecated" libraries with the diodes as they are right now (footprints +
> symbols), plus "standards-compliant" libraries with the cathode at pin 1
> and the anode at pin 2. It would not be good if old schematics change just
> because they are loaded in a new version of KiCad.
>
>
> On Fri, Apr 24, 2015 at 7:31 PM, Carl Poirier 
> wrote:
>
>> Maybe this could be implemented for the stable release.
>>
>> On Fri, Apr 24, 2015 at 1:30 PM, Bob Gustafson  wrote:
>>
>>>  Sounds professional.
>>>
>>> Bob G
>>>
>>>
>>> On 04/24/2015 12:24 PM, Adam Wolf wrote:
>>>
>>> For future things like this, what do people think of a webview that pops
>>> up on startup after checking a site for alerts?
>>> On Apr 24, 2015 12:14 PM, "Carl Poirier" 
>>> wrote:
>>>
>>>> All installations need a local kicad-library, not just OS X. They are
>>>> all in the same situation. The next OS X nightly will be good if you pull
>>>> the latest kicad-libary for the build.
>>>>
>>>>  Kerusey Karyu will announce the change on the users group on Yahoo to
>>>> warn people. If anyone has an account and wants to forward my message
>>>> before he does, feel free to do so.
>>>>
>>>> On Fri, Apr 24, 2015 at 12:55 PM, Adam Wolf <
>>>> adamw...@feelslikeburning.com> wrote:
>>>>
>>>>> Hmm.
>>>>>
>>>>> So the OSX builds use Github by default for footprints, and have
>>>>> symbols "baked in" at build time.
>>>>>
>>>>> Every OS X nightly build is going to produce bad boards, and there's
>>>>> no way to tell users to update or inform them about this change through 
>>>>> the
>>>>> program at all.
>>>>>
>>>>> I really wish I would have known about this earlier.
>>>>>
>>>>> Adam Wolf
>>>>> Cofounder and Engineer
>>>>> Wayne and Layne
>>>>>  On Apr 24, 2015 11:42 AM, "Carl Poirier" 
>>>>> wrote:
>>>>>
>>>>>>  Hi folks,
>>>>>>
>>>>>>  This is simply to warn you that all diodes in KiCad's libraries
>>>>>> have seen their pin numbers swapped. This is to be in line with most 
>>>>>> other
>>>>>> software and the IPC standard as well, which states that cathode should 
>>>>>> be
>>>>>> pin 1. This work is courtesy of the newest librarian, Ricardo Crudo.
>>>>>>
>>>>>>  If you are using Github libraries directly, the only thing you will
>>>>>> have left to do is update your schematic libraries to the latest revision
>>>>>> of https://github.com/KiCad/kicad-library before continuing your
>>>>>> work. If you have a local copy of the footprint repositories, then when 
>>>>>> you
>>>>>> are ready you will be able to pull the changes for both the schematic
>>>>>> libraries and the affected footprint libraries:
>>>>>>
>>>>>>  1. Diodes_SMD.pretty <https://github.com/KiCad/Diodes_SMD.pretty>
>>>>>> 2. Diodes_ThroughHole.pretty
>>>>>> <https://github.com/KiCad/Diodes_ThroughHole.pretty>
>>>>>> 3. LEDs.pretty <https://github.com/KiCad/LEDs.pretty>
>>>>>>
>>>>>>  Thank you for your understanding and sorry for the inconvenience.
>>>>>>
>>>>>>  Carl Poirier
>>>>>>
>>>>>>  ___
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to : kicad-developers@lists.launchpad.net
>>>>>> Unsubscribe : http

Re: [Kicad-developers] UPDATE: Diode pins swapped in KiCad Libraries

[Carl Poirier]

Maybe this could be implemented for the stable release.

On Fri, Apr 24, 2015 at 1:30 PM, Bob Gustafson  wrote:

>  Sounds professional.
>
> Bob G
>
>
> On 04/24/2015 12:24 PM, Adam Wolf wrote:
>
> For future things like this, what do people think of a webview that pops
> up on startup after checking a site for alerts?
> On Apr 24, 2015 12:14 PM, "Carl Poirier"  wrote:
>
>> All installations need a local kicad-library, not just OS X. They are all
>> in the same situation. The next OS X nightly will be good if you pull the
>> latest kicad-libary for the build.
>>
>>  Kerusey Karyu will announce the change on the users group on Yahoo to
>> warn people. If anyone has an account and wants to forward my message
>> before he does, feel free to do so.
>>
>> On Fri, Apr 24, 2015 at 12:55 PM, Adam Wolf <
>> adamw...@feelslikeburning.com> wrote:
>>
>>> Hmm.
>>>
>>> So the OSX builds use Github by default for footprints, and have symbols
>>> "baked in" at build time.
>>>
>>> Every OS X nightly build is going to produce bad boards, and there's no
>>> way to tell users to update or inform them about this change through the
>>> program at all.
>>>
>>> I really wish I would have known about this earlier.
>>>
>>> Adam Wolf
>>> Cofounder and Engineer
>>> Wayne and Layne
>>>  On Apr 24, 2015 11:42 AM, "Carl Poirier" 
>>> wrote:
>>>
>>>>  Hi folks,
>>>>
>>>>  This is simply to warn you that all diodes in KiCad's libraries have
>>>> seen their pin numbers swapped. This is to be in line with most other
>>>> software and the IPC standard as well, which states that cathode should be
>>>> pin 1. This work is courtesy of the newest librarian, Ricardo Crudo.
>>>>
>>>>  If you are using Github libraries directly, the only thing you will
>>>> have left to do is update your schematic libraries to the latest revision
>>>> of https://github.com/KiCad/kicad-library before continuing your work.
>>>> If you have a local copy of the footprint repositories, then when you are
>>>> ready you will be able to pull the changes for both the schematic libraries
>>>> and the affected footprint libraries:
>>>>
>>>>  1. Diodes_SMD.pretty <https://github.com/KiCad/Diodes_SMD.pretty>
>>>> 2. Diodes_ThroughHole.pretty
>>>> <https://github.com/KiCad/Diodes_ThroughHole.pretty>
>>>> 3. LEDs.pretty <https://github.com/KiCad/LEDs.pretty>
>>>>
>>>>  Thank you for your understanding and sorry for the inconvenience.
>>>>
>>>>  Carl Poirier
>>>>
>>>>  ___
>>>> 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
>
>
___
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] UPDATE: Diode pins swapped in KiCad Libraries

[Carl Poirier]

All installations need a local kicad-library, not just OS X. They are all
in the same situation. The next OS X nightly will be good if you pull the
latest kicad-libary for the build.

Kerusey Karyu will announce the change on the users group on Yahoo to warn
people. If anyone has an account and wants to forward my message before he
does, feel free to do so.

On Fri, Apr 24, 2015 at 12:55 PM, Adam Wolf 
wrote:

> Hmm.
>
> So the OSX builds use Github by default for footprints, and have symbols
> "baked in" at build time.
>
> Every OS X nightly build is going to produce bad boards, and there's no
> way to tell users to update or inform them about this change through the
> program at all.
>
> I really wish I would have known about this earlier.
>
> Adam Wolf
> Cofounder and Engineer
> Wayne and Layne
> On Apr 24, 2015 11:42 AM, "Carl Poirier"  wrote:
>
>> Hi folks,
>>
>> This is simply to warn you that all diodes in KiCad's libraries have seen
>> their pin numbers swapped. This is to be in line with most other software
>> and the IPC standard as well, which states that cathode should be pin 1.
>> This work is courtesy of the newest librarian, Ricardo Crudo.
>>
>> If you are using Github libraries directly, the only thing you will have
>> left to do is update your schematic libraries to the latest revision of
>> https://github.com/KiCad/kicad-library before continuing your work. If
>> you have a local copy of the footprint repositories, then when you are
>> ready you will be able to pull the changes for both the schematic libraries
>> and the affected footprint libraries:
>>
>> 1. Diodes_SMD.pretty <https://github.com/KiCad/Diodes_SMD.pretty>
>> 2. Diodes_ThroughHole.pretty
>> <https://github.com/KiCad/Diodes_ThroughHole.pretty>
>> 3. LEDs.pretty <https://github.com/KiCad/LEDs.pretty>
>>
>> Thank you for your understanding and sorry for the inconvenience.
>>
>> Carl Poirier
>>
>> ___
>> 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] UPDATE: Diode pins swapped in KiCad Libraries

[Carl Poirier]

Hi folks,

This is simply to warn you that all diodes in KiCad's libraries have seen
their pin numbers swapped. This is to be in line with most other software
and the IPC standard as well, which states that cathode should be pin 1.
This work is courtesy of the newest librarian, Ricardo Crudo.

If you are using Github libraries directly, the only thing you will have
left to do is update your schematic libraries to the latest revision of
https://github.com/KiCad/kicad-library before continuing your work. If you
have a local copy of the footprint repositories, then when you are ready
you will be able to pull the changes for both the schematic libraries and
the affected footprint libraries:

1. Diodes_SMD.pretty <https://github.com/KiCad/Diodes_SMD.pretty>
2. Diodes_ThroughHole.pretty
<https://github.com/KiCad/Diodes_ThroughHole.pretty>
3. LEDs.pretty <https://github.com/KiCad/LEDs.pretty>

Thank you for your understanding and sorry for the inconvenience.

Carl Poirier
___
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] More than 26 units in a symbol

[Carl Poirier]

On Apr 7, 2015 7:58 AM, "jp charras"  wrote:
>
> Le 06/04/2015 21:10, Carl Poirier a écrit :
> > Indeed, the custom sub-designators would be nice.
> >
> > For the close future, would it be possible to simply extend to "AA"?
Else,
> > are any of you aware of potential problems if the '[' character is used?
> >
>
> I extended the max units to 52 in rev 5579.
> (for practical reasons, like size of menus, this max count is set to 52,
> but can be up to 26x26).
>
Awesome!

> But how is it possible with previous versions to have more than 26 units
> (the lib component properties fix this limit to 26 units) ?
>
I'm not sure how the limit is imposed, but Alex Forencich, the contributor,
is generating Xilinx FPGA using scripts and depending on the part, there
are some going over 26 units.
> --
> Jean-Pierre CHARRAS
>
> ___
> 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] More than 26 units in a symbol

[Carl Poirier]

Indeed, the custom sub-designators would be nice.

For the close future, would it be possible to simply extend to "AA"? Else,
are any of you aware of potential problems if the '[' character is used?

On Thu, Apr 2, 2015 at 2:32 AM, Lorenzo Marcantonio <
l.marcanto...@logossrl.com> wrote:

> On Wed, Apr 01, 2015 at 07:50:45PM -0400, Carl Poirier wrote:
> > Hi peeps,
> >
> > KiCad doesn't seem to have a great nomenclature for the units above 26.
> Let
> > me quote Alex Forencich who is working on Xilinx FPGA
> > <https://github.com/KiCad/kicad-library/pull/149>:
> >
> > > XC5VTX240T-FF1759 in the virtex 5 library has exactly 27 symbols. It
> goes
> > A through Z and then [.
> >
> > Would it be possible to make it something like "AA" ?
>
> Could be a (little) problem due the way eeschema (at least at one time)
> 'desconstructed' the designator (i.e. simply took off the last
> character). Maybe when the other subdesignator styles where added it
> changed. Nothing particularily difficult to handle in any case.
>
> While we are on it, for the new library format, I'd like to have custom
> sub-designators for fixed part components. The problem is that while you
> go U1A, U1B, U1C, U1D for IC and stuff, for relays (just an example) you
> *should* use K1, K1-1, K1-2, K1-3 (first one is coil, following are
> contacts). Of course K1A, K1B, K1C works as well but that's not quite
> correct:P
>
> --
> 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

[Kicad-developers] More than 26 units in a symbol

[Carl Poirier]

Hi peeps,

KiCad doesn't seem to have a great nomenclature for the units above 26. Let
me quote Alex Forencich who is working on Xilinx FPGA
:

> XC5VTX240T-FF1759 in the virtex 5 library has exactly 27 symbols. It goes
A through Z and then [.

Would it be possible to make it something like "AA" ?

Thanks,

Carl
___
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] Library developers.

[Carl Poirier]

Hi folks,

This will be done in the future.

Regards,

Carl Poirier

On Tue, Mar 24, 2015 at 1:46 AM, Miguel Ángel Ajo 
wrote:

> I agree with Wayne,
>
> I watch the repositories, but I barely have the time to track all the
> discussions.
> So I join his request, if some of those discussions could affect a lot of
> people
> using the parts, please bring it to the development list.
>
> Looking into the future,  it would be awesome if at some point, we were
> able
> to track parts by the UUID, regardless of in which library is, so
> if the part is moved, as long as the library is imported, we can yet use
> the part (not 100% if that’s the case now. probably is?).
>
> Yet more amazing would be to have access to the footprint version history,
> or be able to pin the footprints to certain versions, I guess something
> like that would be possible the day we have some sort of footprint/design
> server, with metadata (versions, comments, votes..)
>
> Best regards,
> Miguel Ángel.
>
> Miguel Ángel Ajo
>
> On Monday, 23 de March de 2015 at 19:44, Samuel Dolt wrote:
>
> For people who want to follow any change in library, Github allow to watch
> a repo:
>
> > When you watch a repository, you get notifications (by email) for any
> new pull
> > requests and issues that  are created, including those not mentioning
> you.
> https://help.github.com/articles/watching-repositories/
>
> Significant changes often leads to discussion and decisions in issues or pull
> request.
>
> Best regards
> ___
>
> Samuel Dolt
>
>
>
> Le 23 mars 2015 à 16:50, Wayne Stambaugh  a écrit :
>
> A quick note to our library developers.  I really like some of the
> recent work you have been doing.  It would be nice in the future when
> you make big changes like renaming files and paths to give everyone a
> heads up on developers mailing list and possibly the users mailing lists
> so we don't get blindsided by unexpected changes which affect old projects.
>
> Thanks,
>
> Wayne
>
> ___
> 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
>
>
___
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] [RFC] Footprint wizard

[Carl Poirier]

On Mon, Mar 9, 2015 at 2:06 PM, Maciej Sumiński 
wrote:

> Hi Carl,
>
> The dialog would be common for both ways. If the user chooses local
> files option, then a file browser appears and then as the last step -
> the summary dialog.
>
> Regards,
> Orson
>

That's not what I want to say. I think the table presented in your dialog
and the table in this dialog
<https://lists.launchpad.net/kicad-developers/pngxHBG1VmMoN.png> should
have the same layout. That means maybe simplifying the latter and/or adding
more information in the former.


>
> On 03/09/2015 06:50 PM, Carl Poirier wrote:
> > Hi Orson,
> >
> > It looks great, but I have one comment. I think there should be one
> > template for both the table in "Review and confirm the changes to the
> > libraries" and the fp-lib-table presented in the parent dialog.
> >
> > My 2¢.
> >
> > Carl
> >
> > On Mon, Mar 9, 2015 at 1:23 PM, Maciej Sumiński  >
> > wrote:
> >
> >> As we are inevitably approaching the feature freeze, I would
> >> like to know your opinion about one last change to the footprint library
> >> wizard.
> >>
> >> We would like to make the library management as simple as possible.
> >> Therefore Tom has prepared an alternative set of dialog windows for the
> >> footprint wizard (attached to the message).
> >>
> >> There is no dialog to specify whether the libraries should be added with
> >> absolute/relative/based on environmental variable path. Instead it
> >> depends on the choice in the last dialog: global libraries use absolute
> >> paths, and "current project" option selects relative paths. There is no
> >> choice for environmental variables - the wizard is designed for
> >> beginners, and power users know how to take advantage of them.
> >>
> >> The plan foresees to change the file browser extension filter to handle
> >> all accepted file extensions simultaneously, so the user does not have
> >> to select appropriate plugin first. This way the plugin would be matched
> >> basing on the file extension (possibly verified by the file header
> >> contents).
> >>
> >> I am not going to give any hints on how to use the wizard. If the
> >> dialogs are not self-explanatory, then they are not good enough and have
> >> to be improved.
> >>
> >> I would like to know whether you consider the proposed changes
> >> advantageous and if we would like to have them in the upcoming stable
> >> release.
> >>
> >> Regardless of the answers, the current plan for the GAL canvases is to:
> >> - Add "select copper/connection net"
> >> - Add icons & missing entries to the context menu
> >> - Make the context menu translatable using the standard tools
> >> - Develop or adapt the hotkey editor for GAL (consistent with the legacy
> >> settings)
> >> - Clear the bug tracker
> >>
> >> Regards,
> >> Orso
> >>
> >> ___
> >> 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] [RFC] Footprint wizard

[Carl Poirier]

Hi Orson,

It looks great, but I have one comment. I think there should be one
template for both the table in "Review and confirm the changes to the
libraries" and the fp-lib-table presented in the parent dialog.

My 2¢.

Carl

On Mon, Mar 9, 2015 at 1:23 PM, Maciej Sumiński 
wrote:

> As we are inevitably approaching the feature freeze, I would
> like to know your opinion about one last change to the footprint library
> wizard.
>
> We would like to make the library management as simple as possible.
> Therefore Tom has prepared an alternative set of dialog windows for the
> footprint wizard (attached to the message).
>
> There is no dialog to specify whether the libraries should be added with
> absolute/relative/based on environmental variable path. Instead it
> depends on the choice in the last dialog: global libraries use absolute
> paths, and "current project" option selects relative paths. There is no
> choice for environmental variables - the wizard is designed for
> beginners, and power users know how to take advantage of them.
>
> The plan foresees to change the file browser extension filter to handle
> all accepted file extensions simultaneously, so the user does not have
> to select appropriate plugin first. This way the plugin would be matched
> basing on the file extension (possibly verified by the file header
> contents).
>
> I am not going to give any hints on how to use the wizard. If the
> dialogs are not self-explanatory, then they are not good enough and have
> to be improved.
>
> I would like to know whether you consider the proposed changes
> advantageous and if we would like to have them in the upcoming stable
> release.
>
> Regardless of the answers, the current plan for the GAL canvases is to:
> - Add "select copper/connection net"
> - Add icons & missing entries to the context menu
> - Make the context menu translatable using the standard tools
> - Develop or adapt the hotkey editor for GAL (consistent with the legacy
> settings)
> - Clear the bug tracker
>
> Regards,
> Orso
>
> ___
> 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] Module text height default

[Carl Poirier]

Suppose I install a fresh KiCad on a new computer. I need the default value
set to 1mm instead of 1.5mm.

On Mon, Mar 2, 2015 at 8:53 AM, jp charras  wrote:

> Le 02/03/2015 14:38, Carl Poirier a écrit :
> > I'm talking about the footprint editor. When I delete the config file,
> the
> > settings are reset to 1.5mm. We need 1mm.
>
> Again, you have to set the defaults by the Preferences/settings menu.
>
> Obviously, if you delete your config files after setting your
> preferences, you have to set your preferences again.
>
> This is true for all your settings.
>
> >
> >
> >
> > On Mon, Mar 2, 2015 at 7:01 AM, jp charras 
> wrote:
> >
> >> Le 02/03/2015 02:59, Carl Poirier a écrit :
> >>> I meant with the setting adjusted to 1mm.
> >>>
> >>> On Sun, Mar 1, 2015 at 7:36 PM, Carl Poirier  >
> >>> wrote:
> >>>
> >>>> I compiled with the setting adjusted to 1.5mm, uninstalled the
> previous
> >>>> KiCad, deleted manually the folder ~/.config/kicad and then installed
> >> the
> >>>> newer version, but I still get 1.5mm as the default when I fire up
> >> pcbnew.
> >>>>
> >>>> On Sun, Mar 1, 2015 at 1:06 AM, jp charras 
> >> wrote:
> >>>>
> >>
> >> Are you talking about the board editor or the footprint editor ?
> >> * the footprint editor has the default settings set by the user
> >> (Preferences/Settings) saved in its config file.
> >> * the board editor has some default settings (namely these settings)
> >> saved in the kicad_pcb file (they are often depending on the board
> >> currently designed).
> >>
> >> They are different, because now the footprint editor can be run outside
> >> pcbnew (from the Kicad manager) and saving the footprint editor default
> >> settings in a board file has no sense, and I am thinking they are not
> >> always related to the board or the project currently in use.
> >>
> >> --
> >> Jean-Pierre CHARRAS
> >>
> >
>
>
> --
> Jean-Pierre CHARRAS
>
___
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] Module text height default

[Carl Poirier]

I'm talking about the footprint editor. When I delete the config file, the
settings are reset to 1.5mm. We need 1mm.



On Mon, Mar 2, 2015 at 7:01 AM, jp charras  wrote:

> Le 02/03/2015 02:59, Carl Poirier a écrit :
> > I meant with the setting adjusted to 1mm.
> >
> > On Sun, Mar 1, 2015 at 7:36 PM, Carl Poirier 
> > wrote:
> >
> >> I compiled with the setting adjusted to 1.5mm, uninstalled the previous
> >> KiCad, deleted manually the folder ~/.config/kicad and then installed
> the
> >> newer version, but I still get 1.5mm as the default when I fire up
> pcbnew.
> >>
> >> On Sun, Mar 1, 2015 at 1:06 AM, jp charras 
> wrote:
> >>
>
> Are you talking about the board editor or the footprint editor ?
> * the footprint editor has the default settings set by the user
> (Preferences/Settings) saved in its config file.
> * the board editor has some default settings (namely these settings)
> saved in the kicad_pcb file (they are often depending on the board
> currently designed).
>
> They are different, because now the footprint editor can be run outside
> pcbnew (from the Kicad manager) and saving the footprint editor default
> settings in a board file has no sense, and I am thinking they are not
> always related to the board or the project currently in use.
>
> --
> Jean-Pierre CHARRAS
>
___
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] Module text height default

[Carl Poirier]

I meant with the setting adjusted to 1mm.

On Sun, Mar 1, 2015 at 7:36 PM, Carl Poirier 
wrote:

> I compiled with the setting adjusted to 1.5mm, uninstalled the previous
> KiCad, deleted manually the folder ~/.config/kicad and then installed the
> newer version, but I still get 1.5mm as the default when I fire up pcbnew.
>
> On Sun, Mar 1, 2015 at 1:06 AM, jp charras  wrote:
>
>> Le 28/02/2015 22:36, Carl Poirier a écrit :
>> > Hi peeps,
>> >
>> > I was looking to change the module text (value and reference) height
>> > default so that it is in sync with the KiCad Library Convention, but I
>> > can't seem to figure out what's missing. I changed this define in
>> > pcbnew/class_board_design_settings.cpp to have 1.0 instead of 1.5:
>> >
>> > #define DEFAULT_TEXT_MODULE_SIZEMillimeter2iu( 1.5 )  <-- original
>> value
>> >
>> > But still, when I create a new footprint, the value and ref are 1.5mm
>> high.
>> > What am I missing here?
>> >
>> > Carl
>>
>> Default values used in Footprint creation are now user definable in
>> ModEdit.
>> You have to define them in Modedit, Preferences/Settings
>> (size, layers ...)
>>
>> DEFAULT_TEXT_MODULE_SIZE is the default value for a fresh Kicad install
>> (i.e. without any existing config file) and then replaced by your
>> personal settings.
>>
>>
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> 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] Module text height default

[Carl Poirier]

I compiled with the setting adjusted to 1.5mm, uninstalled the previous
KiCad, deleted manually the folder ~/.config/kicad and then installed the
newer version, but I still get 1.5mm as the default when I fire up pcbnew.

On Sun, Mar 1, 2015 at 1:06 AM, jp charras  wrote:

> Le 28/02/2015 22:36, Carl Poirier a écrit :
> > Hi peeps,
> >
> > I was looking to change the module text (value and reference) height
> > default so that it is in sync with the KiCad Library Convention, but I
> > can't seem to figure out what's missing. I changed this define in
> > pcbnew/class_board_design_settings.cpp to have 1.0 instead of 1.5:
> >
> > #define DEFAULT_TEXT_MODULE_SIZEMillimeter2iu( 1.5 )  <-- original
> value
> >
> > But still, when I create a new footprint, the value and ref are 1.5mm
> high.
> > What am I missing here?
> >
> > Carl
>
> Default values used in Footprint creation are now user definable in
> ModEdit.
> You have to define them in Modedit, Preferences/Settings
> (size, layers ...)
>
> DEFAULT_TEXT_MODULE_SIZE is the default value for a fresh Kicad install
> (i.e. without any existing config file) and then replaced by your
> personal settings.
>
>
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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] Module text height default

[Carl Poirier]

Hi peeps,

I was looking to change the module text (value and reference) height
default so that it is in sync with the KiCad Library Convention, but I
can't seem to figure out what's missing. I changed this define in
pcbnew/class_board_design_settings.cpp to have 1.0 instead of 1.5:

#define DEFAULT_TEXT_MODULE_SIZEMillimeter2iu( 1.5 )  <-- original value

But still, when I create a new footprint, the value and ref are 1.5mm high.
What am I missing here?

Carl
___
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] Global fp-lib-table path

[Carl Poirier]

> I thought default fp-lib-table files that ship with the default
> libraries are correct.  Are there libraries missing from the table?  If
> so, that needs to be fixed.

The official fp-lib-table.for-github and fp-lib-table.for-pretty are kept
in sync with the .pretty repositories at https://github.com/KiCad. If a
repo is not included in the fp-lib-tables, it's because it's not meant to
be used. For example, I added a repo minutes ago which was empty
beforehand, thus it would have caused an error during loading.

> And, there have been lengthy discussion whether you want to use github
libraries or not.
> I don’t… I like to know that the parts I order will fit the PCB at first
try.

We librarians are doing our best to have the highest quality libraries. We
approve every pull request. If your fp-lib-table is filled with official
.pretty repos, you can be confident as long as you are using the right
footprint with the right part. That being said, if you find an issue,
please open a ticket on Github or create a pull request with the fix.

Carl Poirier
___
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] fp-lib-tables UI question

[Carl Poirier]

Couldn't you pull the preconfigured fp-lib-tables from Github instead of a
local directory? This way, it will be easy for the user to get the latest
and greatest footprints!

On Thu, Jan 22, 2015 at 4:23 PM, Adam Wolf 
wrote:

> Great, thanks!
> On Jan 22, 2015 4:20 PM, "Wayne Stambaugh"  wrote:
>
>> As of right now, the preloaded fp-lib-table files are installed in
>> ${CMAKE_INSTALL_PREFIX}/share/kicad/template on Linux and Windows.  On
>> OSX they appear to be installed in
>> ${OSX_BUNDLE_INSTALL_DIR}/${OSX_BUNDLE_SUP_DIR}/template where ever that
>> works out to be.  The fp-lib-table files themselves are part of the
>> kicad-library source so hopefully the install path is the same for them
>> on OSX as well.
>>
>> On 1/22/2015 4:10 PM, Adam Wolf wrote:
>> > This is going to be slick, Wayne.  Is there any particular place that
>> > seems decent to put the preconfigured fp-table-libs?  In my mind,
>> > they're almost templates...
>> >
>> > Adam Wolf
>> >
>> > On Thu, Jan 22, 2015 at 4:01 PM, Wayne Stambaugh > > > wrote:
>> >
>> > On 1/22/2015 3:56 PM, Adam Wolf wrote:
>> > > Do you mean /fp-table-lib? (i.e., on
>> > > Linux ~/.config/kicad/fp-lib-table?)
>> >
>> > Yes.
>> >
>> > >
>> > > I really like this idea.  The wizard already does a good job
>> explaining
>> > > what each type of fp-lib-table entry is.
>> >
>> > Then it should be possible to add the code to copy a pre-configured
>> > fp-lib-table file to the proper path.  The only tricky part would be
>> > setting up any environment variables.  I have a patch that sets
>> default
>> > environment variables for KIGITHUB and KISYS3DMOD on start up.  I
>> > haven't designed the dialog to edit them yet.  It needs tested on
>> OSX so
>> > I will post it some time tomorrow to get some feed back.  The
>> > environment variables are saved in the kicad_common config file so
>> you
>> > could simple add new config entry for something like KISYSMOD from
>> the
>> > fp-lib-table wizard for footprint libraries stored on the system
>> once I
>> > commit the code.
>> >
>> > >
>> > > Adam Wolf
>> > >
>> > > On Thu, Jan 22, 2015 at 3:33 PM, Wayne Stambaugh <
>> stambau...@gmail.com 
>> > > >>
>> wrote:
>> > >
>> > > Maybe you could add an "Initialize Global Table" mode to the
>> > > fp-lib-table wizard where a predefined table file is copied
>> to ~/.  You
>> > > could test for ~/fp-lib-table and enter this mode
>> automatically or enter
>> > > the "Edit Table" mode when ~/fp-lib-table is already
>> defined.  This
>> > > would also prevent further cluttering of the library table
>> editor.
>> > >
>> > > On 1/22/2015 10:53 AM, Adam Wolf wrote:
>> > > > The new fp-lib-table wizard is great for adding new entries
>> to the
>> > > > current table, but does not appear to have a "load
>> defaults" type option.
>> > > >
>> > > > However, this is based on using it, not reading the code,
>> so it is
>> > > > possible the feature is included somewhere I did not see.
>> > > >
>> > > > Adam Wolf
>> > > >
>> > > > On Thu, Jan 22, 2015 at 1:27 AM, Nick Østergaard <
>> oe.n...@gmail.com 
>> > >
>> > > > 
>> > > > > >
>> > > > How does this compare to the new fp lib table wizard?
>> > > >
>> > > > 2015-01-22 6:09 GMT+01:00 Adam Wolf <
>> adamw...@feelslikeburning.com 
>> > > > >
>> > > > > > 
>> > > > > > > > > > Hi folks!
>> > > > >
>> > > > > I have a question about adding another feature to the
>> > > > fp-lib-tables manager,
>> > > > > which is already pretty crowded and I want to get
>> buy-in
>> > > before even
>> > > > > attempting a patch.
>> > > > >
>> > > > > Background:
>> > > > >
>> > > > > Running into another issue with the KiCad Mac
>> experience.
>> > > Just to
>> > > > recap, I'm
>> > > > > trying for 2 DMGs.
>> > > > >
>> > > > > One is called "KiCad Extras" and currently includes
>> > the modules
>> > > > from github,
>> > > > > and the fp-table-lib.for-pretty renamed just
>> > 

Re: [Kicad-developers] [Kicad-lib-committers] KLC - courtyard

[Carl Poirier]

Thanks for the explanation. It also seemed odd to me that SMD aluminum
capacitors would have a bigger clearance than THT ones, but I guess it
makes sense now.

I am amending the same rules as stated above but explicitly specifying the
crystals.

- Courtyard line has a width 0.05mm. This line is placed so that its
clearance is measured from its center to the edges of pads and body, and
its position is rounded on a grid of 0.05mm.
- Courtyard clearance is 0.25mm except for components smaller than 0603 at
0.15mm, connectors, SMD canned capacitors and crystals at 0.5mm and BGA at
1.0mm. (IPC-7251, IPC-7351B)

On Mon, Jan 19, 2015 at 2:55 AM, Lorenzo Marcantonio <
l.marcanto...@logossrl.com> wrote:

> On Thu, Jan 15, 2015 at 04:44:38PM -0500, Carl Poirier wrote:
> > Because that's what IPC-7351B says about can components. I don't think
> they
> > include the THT cans in this standard, but Lorenzo can confirm that one.
> > (Or anyone else with access to the documents)
> >
> > On Thu, Jan 15, 2015 at 4:32 PM, nnn  wrote:
> >
> > >  I don't understand the exception for aluminum capacitors. Does it
> apply
> > > to both THT and SMD? Why clearance for THT capacitors should be greater
> > > than clearance for other THT?
>
> First thing: 7351 is only for SMD; THT are covered by 7251 (draft freely
> available). AFAIK in 7251 you only have to decide if pinning is radial
> or axial. However both the LP designer and the slides on the net are
> based on the unpublished 7351C and the work-in-progress 7070 standard.
>
> If you look here
> http://www.ipc.org/CommitteeDetail.aspx?Committee=5-21A, the Hausherr
> guy is one of the leader so I'm expecting that some of the information
> and stuff from LP designer is a preview for the incoming standard. In
> other words, Mentor/PCB Libraries will always be ahead on the
> implementation since they actually ratify the standards :P
>
> Second thing: the IPC tables are done by *experiment*, i.e. they
> soldered an hellish number of board with different spacing and
> statistically derived the optimal spacing/values/whatever. It's one of
> the main reason for having them paying for the standard AFAIK.
>
> Also, the rule for canned capacitors applies to canned (2 pin) crystal too.
>
> The reason for the spacing isn't explained, but I think is due to the
> balance/form factor of these parts (in fact, there is a specific
> table for the taller parts).
>
> If you look at the construction for the L-ribbon leaded pins in
> a typical canned capacitor, the body *doesn't* touch the board. It's all
> suspended above the thin and reasonably tall pins, so there is
> considerable leverage available for the cap (a common fault is the cap
> tearing off the pads...). Also the pins are not flats but slightly
> 'tented', unlike wound coils (no idea why). See here:
>
> http://s3-blogs.mentor.com/tom-hausherr/files/2010/10/under_bodyoutward_l_lead.png
>
> I think that the biggest courtyard is to allow for a slight movement of
> the parts while unsoldered (paste is tacky, but it's not glue). Also if
> the capacitor is tilted (other common failure during inspection) you
> need a bigger space for rework it into position...
>
> --
> 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

Re: [Kicad-developers] Recent Kicad library changes.

[Carl Poirier]

Thanks Michal for taking care of this.

On Fri, Dec 12, 2014 at 6:00 PM, Wayne Stambaugh 
wrote:

> Can someone explain to me what the contents of modules/package3D/unused
> is for?  The ridiculously long file names of the 7 segment led files is
> causing my msys2 package build to barf.  If this folder is redundant,
> please get rid of it.  If not, please rename the files to something sane
> so I can finish up the full mingw64 and mingw32 packages.  I'm willing
> to take on the task if no one objects to the changes.
>
> Thanks,
>
> Wayne
>
> ___
> 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] Bug in footprint keyword search function

[Carl Poirier]

Thanks for the heads up.

This has to be fixed, IMO.

On Tue, Nov 11, 2014 at 8:54 AM, Bob Gustafson  wrote:

> It appears that the search term has to include the comma !!
>
> But the last item on the list has no comma.
>
> For the searchee, this is non-intuitive behavior.
>
> Bob G
>
>
> On 11/11/2014 01:22 AM, jp charras wrote:
>
>> CNY17,
>> RevA,
>> 31Mar2011
>>
>> They are just a copy of the comment, and I am thinking very very badly
>> defined, at least because many keywords have no sense.
>>
>> If you type the keyword actually defined in this list: "CNY17," you have
>> a list of footprints.
>>
>> -- Jean-Pierre CHARRAS
>>
>
>
> ___
> 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] Bug in footprint keyword search function

[Carl Poirier]

Hi all,

I noticed the keyword search function does not work for some cases, unless
there is something I don't understand.

In pcbnew, hit "Add footprints". In the textbox, write "CNY17" and hit
"Search by keyword". I get "No footprint found". I would expect some
opto-devices to come out, for example the Optocoupler_6pin_wide_Stile-I
which has "CNY17" in its keywords field.

I can place it using the "List All" or "Select by browser", however, and if
I create a footprint with a single keyword, then I can search for it.

Can anyone confirm this issue or tell me if it's a normal behavior?

Thanks,

Carl
___
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] PATCH: Underlays

[Carl Poirier]

> What do you mean by not the adhesive layers not being use? They are
used in e.g. [choke].

Adhesive in KiCad's libraries was discussed in September. It was decided to
leave it out of our libraries. These chokes haven't been reworked to fit
our Library Convention yet.

https://lists.launchpad.net/kicad-lib-committers/msg00221.html

On Mon, Nov 10, 2014 at 4:17 PM, Nick Østergaard  wrote:

> 2014-11-10 21:08 GMT+01:00 jp charras :
> > Le 10/11/2014 20:57, Carl Poirier a écrit :
> >> Is there any predefined use of the ECO layers? It says "user defined" or
> >> something like that IIRC (I don't have access to KiCad right now). If
> >> there is no such predefined use, I'd go for that instead of the adhesive
> >> layer which does have one.
> >>
> >
> > There is no predefined use for ECO1 and ECO2.
> > I talked of adhesive layers just because they are paired and not used in
> > our footprint libraries.
>
> What do you mean by not the adhesive layers not being use? They are
> used in e.g. [choke].
>
> [choke]
> https://github.com/KiCad/Choke_SMD.pretty/blob/master/Choke_Double_SMD_Wuerth-WE-DD-Typ-L-Typ-XL-Typ-XXL.kicad_mod
>
> ___
> 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] PATCH: Underlays

[Carl Poirier]

Is there any predefined use of the ECO layers? It says "user defined" or
something like that IIRC (I don't have access to KiCad right now). If there
is no such predefined use, I'd go for that instead of the adhesive layer
which does have one.

On Mon, Nov 10, 2014 at 2:27 PM, Cirilo Bernardo 
wrote:

> On Mon, Nov 10, 2014 at 7:18 PM, jp charras  wrote:
>
>> Le 09/11/2014 21:34, Cirilo Bernardo a écrit :
>> > The reason other layers were used is that there are spare layers and
>> > people use the drawing layer for their own purposes; if a user makes use
>> > of the Drawing layer and this Underlay tool then the tool will interfere
>> > with their normal use.
>>
>> Yes, but I agree with Carl, creating 2 new layers (and modifying current
>> code in Pcbnew) for a so specific and temporary use is not very useful.
>>
>> ECO1, ECO2, adhesive layers (rarely used) could be temporary easily
>> used for this purpose.
>>
>> I am perhaps wrong, but I am thinking to show an image of existing PCB
>> on these layers is only temporary, and this image will be removed from
>> the final board, after placing footprints and routing them.
>>
>>
> OK, I'll look into making use of the ECO or Adhesive layers. You're right
> about the images only being temporary; the idea is to use an image to
> route a board or to use an image to create a footprint.  The image is
> deleted when it is no longer needed.
>
> - Cirilo
>
>
>
>> >
>> > - Cirilo
>> >
>> > On Sun, Nov 9, 2014 at 12:23 PM, Carl Poirier > > <mailto:carl.poirie...@gmail.com>> wrote:
>> >
>> > Cirilo,
>> >
>> > I tried your patch. I don't see any problems with it, but I just
>> > began wondering why not use a user layer for that purpose, for
>> > example the drawings layer, instead of adding another one to the
>> list.
>> >
>> > Allowing the bitmap2component tool to export to another layer than
>> > silk might be nice for people who don't want to edit the text file
>> > manually, however.
>>
>> Yes but not to any other layer:
>> Edges cut, courtyard layers and some other cannot be used because they
>> have a special meaning or special properties, and therefore using them
>> to put a logo on them is a bad idea (bad idea = bug reports, later)
>>
>> >
>> > Regards,
>> >
>> > Carl
>>
>> Regards,
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> 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

Re: [Kicad-developers] PATCH: Underlays

[Carl Poirier]

Cirilo,

I tried your patch. I don't see any problems with it, but I just began
wondering why not use a user layer for that purpose, for example the
drawings layer, instead of adding another one to the list.

Allowing the bitmap2component tool to export to another layer than silk
might be nice for people who don't want to edit the text file manually,
however.

Regards,

Carl

On Tue, Nov 4, 2014 at 9:07 AM, Carl Poirier 
wrote:

> You know it would be useful for many designs in which the layout is
> crucial. As a hobbyist, I've never done RF, but I messed up a few
> high-frequency switching regulators by not quite following the template
> shown in the datasheet. I give a thumbs up to this patch by Cirilo and will
> try it shortly.
>
> Regards,
>
> Carl
>
> On Sun, Nov 2, 2014 at 5:08 PM, Nick Østergaard  wrote:
>
>> Hi Cirilo
>>
>> That was indeed my problem. I had downloaed the patch earlier, and did
>> not notice the ther files. I applied and built successfullt after I
>> followed the instrucitons in the README.
>>
>> I don't have much to comment on it, I think one needs to try it out on
>> a real design to tell if it is any good in practice. I guess it would be.
>>
>> Nick
>>
>> 2014-11-01 10:48 GMT+01:00 Cirilo Bernardo :
>> > Hi Nick,
>> >
>> >  I just tried the patch against rev 5247 and had no problems. Did you
>> follow
>> > the instructions in the README file? Thanks for checking out the patch.
>> >
>> > - Cirilo
>> >
>> >
>> > On Fri, Oct 31, 2014 at 10:33 PM, Nick Østergaard 
>> wrote:
>> >>
>> >> Sorry for the late response Cirilo, but I just tried to patch this
>> >> against latest 5241 and get errors, here is a snippet from it.
>> >>
>> >>
>> >>
>> /home/nickoe/PKGBUILDs/kicad-bzr/src/kicad/bitmap2component/bitmap2cmp_gui.cpp:
>> >> In constructor 'BM2CMP_FRAME::BM2CMP_FRAME(KIWAY*, wxWindow*)':
>> >>
>> >>
>> /home/nickoe/PKGBUILDs/kicad-bzr/src/kicad/bitmap2component/bitmap2cmp_gui.cpp:176:9:
>> >> error: 'm_radio_PCBLayer' was not declared in this scope
>> >>  m_radio_PCBLayer->Enable( true );
>> >>
>> >>
>> >> 2014-09-29 23:48 GMT+02:00 Cirilo Bernardo > >:
>> >> > I have put a patch on github to introduce 2 Underlay layers to help
>> with
>> >> > reconstructing
>> >> > PCB artwork from images of existing PCBs. This can be useful for
>> people
>> >> > involved in legacy product support or for people who want to create
>> >> > Gerber
>> >> > files from published artwork in magazines.
>> >> >
>> >> > The patch modifies the bitmap2component tool to allow an image to be
>> >> > placed on the Underlay1 or Underlay2 layer in addition to the past
>> >> > behavior
>> >> > of placing images on the Front.SilkS layer. Generic instructions for
>> >> > applying
>> >> > the patch are in the README.md file from my patch project on github.
>> >> >
>> >> > The patch is available at:
>> >> >
>> >> > https://github.com/cbernardo/kicad-patches
>> >> >
>> >> > I have tested the patch with pcbnew and checked that there are no
>> >> > unintended effects in the print, plot, and export functions of
>> pcbnew.
>> >> > The patch is against rev. 5151
>> >> >
>> >> > - Cirilo
>> >> >
>> >> >
>> >> >
>> >> > ___
>> >> > 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

Re: [Kicad-developers] PATCH: Underlays

[Carl Poirier]

You know it would be useful for many designs in which the layout is
crucial. As a hobbyist, I've never done RF, but I messed up a few
high-frequency switching regulators by not quite following the template
shown in the datasheet. I give a thumbs up to this patch by Cirilo and will
try it shortly.

Regards,

Carl

On Sun, Nov 2, 2014 at 5:08 PM, Nick Østergaard  wrote:

> Hi Cirilo
>
> That was indeed my problem. I had downloaed the patch earlier, and did
> not notice the ther files. I applied and built successfullt after I
> followed the instrucitons in the README.
>
> I don't have much to comment on it, I think one needs to try it out on
> a real design to tell if it is any good in practice. I guess it would be.
>
> Nick
>
> 2014-11-01 10:48 GMT+01:00 Cirilo Bernardo :
> > Hi Nick,
> >
> >  I just tried the patch against rev 5247 and had no problems. Did you
> follow
> > the instructions in the README file? Thanks for checking out the patch.
> >
> > - Cirilo
> >
> >
> > On Fri, Oct 31, 2014 at 10:33 PM, Nick Østergaard 
> wrote:
> >>
> >> Sorry for the late response Cirilo, but I just tried to patch this
> >> against latest 5241 and get errors, here is a snippet from it.
> >>
> >>
> >>
> /home/nickoe/PKGBUILDs/kicad-bzr/src/kicad/bitmap2component/bitmap2cmp_gui.cpp:
> >> In constructor 'BM2CMP_FRAME::BM2CMP_FRAME(KIWAY*, wxWindow*)':
> >>
> >>
> /home/nickoe/PKGBUILDs/kicad-bzr/src/kicad/bitmap2component/bitmap2cmp_gui.cpp:176:9:
> >> error: 'm_radio_PCBLayer' was not declared in this scope
> >>  m_radio_PCBLayer->Enable( true );
> >>
> >>
> >> 2014-09-29 23:48 GMT+02:00 Cirilo Bernardo :
> >> > I have put a patch on github to introduce 2 Underlay layers to help
> with
> >> > reconstructing
> >> > PCB artwork from images of existing PCBs. This can be useful for
> people
> >> > involved in legacy product support or for people who want to create
> >> > Gerber
> >> > files from published artwork in magazines.
> >> >
> >> > The patch modifies the bitmap2component tool to allow an image to be
> >> > placed on the Underlay1 or Underlay2 layer in addition to the past
> >> > behavior
> >> > of placing images on the Front.SilkS layer. Generic instructions for
> >> > applying
> >> > the patch are in the README.md file from my patch project on github.
> >> >
> >> > The patch is available at:
> >> >
> >> > https://github.com/cbernardo/kicad-patches
> >> >
> >> > I have tested the patch with pcbnew and checked that there are no
> >> > unintended effects in the print, plot, and export functions of pcbnew.
> >> > The patch is against rev. 5151
> >> >
> >> > - Cirilo
> >> >
> >> >
> >> >
> >> > ___
> >> > 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

Re: [Kicad-developers] Footprint python plugin: Is it possible to merge ?

[Carl Poirier]

> I wonder if you could you set up a local github server on your system
> (assuming the github server software is freely available) and point the
> github plugin to 127.0.0.1?

Of course it will work, Simply set KIGITHUB with the local address.

> I know this is problematic, if it actually do perform COW and will not
sync anymore.

If you set your local repositories with git clone, then it will simply be a
matter of doing:

for prettyfolder in *
do
cd prettyfolder
git pull
cd ..
done

On Mon, Nov 3, 2014 at 4:52 PM, Nick Østergaard  wrote:

> Aha, I did not know that the COW was working like that. Seems to work
> fine from the limited testing I just did. I do think that the need for
> existing dirs that allow_pretty_writing_to_this_dir specify is a bit
> strange, but I guess it is well thought out. It would become quite
> tedious to create the handfull of libs (or all) manually.
>
> I wonder if there is any posibility or scheme to make it cache by
> default somewhere. I know this is problematic, if it actually do
> perform COW and will not sync anymore. I hope I have understood the
> COW functionality correctly.
>
> 2014-11-03 21:56 GMT+01:00 Wayne Stambaugh :
> > It's called copy on write and it already exits in the github plugin.  No
> > tuning necessary.  You just need to configure your fp-lib-table to take
> > advantage of it.  It is well documented the "Using the GitHub Plugin"
> > section of both the CvPcb and Pcbnew reference manuals.
> >
> > On 11/3/2014 3:27 PM, Jean-Paul Louis wrote:
> >> Hi Nick,
> >>
> >> The best would be to tune the github plugin to do just that. Access the
> footprints from git and have them stored locally, so changes would be
> faster, and user could work when not online.
> >> I thought that it was planned to have that working already (github
> access with local storage of data).
> >>
> >> Just my $0.02,
> >> Jean-Paul
> >> AC9GH
> >>
> >> On Nov 3, 2014, at 1:25 PM, Nick Østergaard  wrote:
> >>
> >>> Hi Jean-Samuel
> >>>
> >>> Aha, that makes sense.
> >>>
> >>> Maybe the following is a bad idea, but anyway -- here goes.
> >>> With that I guess one could even make a script that is cloning and
> >>> updating the kicad footprints from github and chaching them also.
> >>>
> >>> Nick
> >>>
> >>> 2014-11-03 18:28 GMT+01:00 Jean-Samuel Reynaud :
>  Hi Nick,
> 
>  Sorry I'm not always clear in my explaination...
> 
>  This plugin provide a gateway to custom plugin writen in python.
>  For example you can write a new plugin in python to fetch some
> footprint
>  from a database for example...
> 
>  Thanks,
>  Le 03/11/2014 17:37, Nick Østergaard a écrit :
> > Hi Jean-Samuel
> >
> > What exactly does this do? I guess a section for the documentation
> has
> > to be written to describe the purpose or functionality of this
> option.
> >
> > Does this plugin then run a python script that magically creates the
> > footprint you have in mind or? Does this provide a gateway to make
> > some custom plugin to fetch footprints from various sources from a
> > simple python?
> >
> > Sorry for all the questionmarks, but I don't quite get what exactly
> > this is. (I have not tried it yet)
> >
> > Nick
> >
> > 2014-11-03 15:14 GMT+01:00 Jean-Samuel Reynaud  >:
> >> Hi All,
> >>
> >> I wrote few months ago an extension to be able to write in python a
> >> footprint library plugin.
> >> ie: for the moment for footprint you have to choice between:
> >> - Kicad
> >> - Legacy
> >> - GitHub
> >> ...
> >> And I had write a "Python". You choose the python module to load
> (the
> >> module name as an option of the python plugin) and this python
> >> module have to implement some functions to do the job.
> >>
> >> This code is currently under a branch :
> >> lp:~kicad-developers/kicad/python_plugin
> >>
> >> Specific code is mainly in pcbnew/fppython/ and there is a python
> >> example in pcbnew/fppython/fppython_example.py.
> >>
> >> I regularly merge with upstream to maintain this branch up to date.
> >> I cleanned up the code to meet coding standard.
> >>
> >> Is it possible to merge on main branch ?
> >>
> >> Regards,
> >>
> >>
> >> ___
> >> 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] Global Search Paths and fp-lib-table Entries?

[Carl Poirier]

Anyway, when you start working with the new system and beginning to know
its content, you quickly discover that typing a partial or complete
footprint name in the search box gets much faster than going through the
whole list, looking for it. I am not sure if such a sorting mechanism would
be that beneficial.

If offline use is required, then the fp-lib-table.forpretty can be used
along with the new footprint format.

On Mon, Nov 3, 2014 at 11:13 AM, LordBlick  wrote:

> In response to a message written on 03.11.2014 16:17, from Wayne Stambaugh:
>
>> On 11/3/2014 10:06 AM, LordBlick wrote:
>>
>>> In response to a message written on 03.11.2014 15:27, from Carl Poirier:
>>>
>>>> Why use the legacy footprints (…)?
>>>>
>>> In legacy footprints have stay cleanup by user preferable order(I've own
>>> footprint editor developed much time, then new, messy format arrives).
>>> Alphabetically sorted is not the same, that somebody needs… It's bad
>>> idea, because it's easy to end with many doubled/tripled footprints.
>>>
>>>  Duplicate footprints are no longer an issue with fp-lib-table.  Prior to
>> fp-lib-table, is was possible to load the wrong footprint if the path
>> search order was not correct.  This cannot happen with fp-lib-table not
>> matter how many duplicate footprint names you have.
>>
>> I'm not sure what "messy" new format you are speaking of but the current
>> board and footprint library formats are significantly better the legacy
>> format and the fp-lib-table is far superior to the old path search
>> method of looking up footprint in libraries.
>>
> I mean, it would be nice if every directory has a file named something
> like ".sort", which would result in the footprints of the library would be
> displayed in the desired, not necessarily alphabetical order(Something like
> body of „$Index/$EndIndex” legacy format). Absence of the file, or its
> invalid format, would result in only the default sorting.
>  For example, I have a library of IDC, in which I have the elements are
> arranged according to the amount of pins, when the names of the version
> with the hooked-snaps start with SCM, not IDC. This is the true order, when
> you can sequentially arranged according to your preferences. Until I had my
> own program to manage legacy library, I had no problem with it - all the
> elements are in one file, so inevitably they were stored in the desired
> order.
> Such a small blueprint. ;)
> --
> Best Regards,
> LordBlick
>
> ___
> 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] Global Search Paths and fp-lib-table Entries?

[Carl Poirier]

Why use the legacy footprints for OSX? We are working hard on a set of
improved ones. They are miles ahead of the old ones now. If you build the
github plugin and use the corresponding fp-lib-table
(kicad-library/template/fp-lib-table.forgithub), it should work straight
away.

On Mon, Nov 3, 2014 at 8:53 AM, Wayne Stambaugh 
wrote:

> On 11/3/2014 3:22 AM, Cirilo Bernardo wrote:
> > On Mon, Nov 3, 2014 at 6:19 PM, Bernhard Stegmaier
> > mailto:stegma...@sw-systems.de>> wrote:
> >
> > OK, got it.
> > However, I am still trying to get some kind of “best practice” on
> > how to configure things.
> >
> > So, for pcbnew search stacks are already legacy.
> > That is, as a starting point for pcbnew I have the fp-lib-table file
> > which lives in the preferences folder (which is
> > ~/Library/Preferences/kicad on OSX).
> > Via the fp-lib-table I reference all my modules/footprints - I can
> > use absolute paths, environment variables, etc. as I like.
> > The 3D-models referenced by modules/footprints are also always
> > absolute paths but may contain environment variables.
> > Correct?
> >
> >
> > Not quite correct. For 3D models the code will use the environment
> > variable KISYS3DMOD in place of the legacy SOMEDIR/modules/packages3d -
> > this is the only environment var which the code will check and this is
> > hard-coded. If there is no environment var set then the code attempts to
> > look in the legacy default paths; I don't have KiCad source installed on
> > the computer I'm sitting at so I can't check what that path is of OSX.
> > If you attach a model which is not in the default 3d model search path,
> > then the full path will be recorded. If the model is in the default
> > search path then a truncated path is recorded, which I think is bad
> > behavior but this was the legacy behavior and it will persist until
> > someone finds time to fix things.
> >
> >
> > How am I supposed to configure libraries for eeschema?
> >
> >
> > Not sure - it's been a long time since I looked at that part of the code.
>
> Eeschema will use the path search stack to find component libraries.
> Eeschema will append /library to each valid path in the search stack so
> as long as your base path is in the search stack and your component
> libraries are in base_search_path/library then they will be found.  Of
> course you can also configure the library paths in your project.
>
> >
> >
> >
> > I currently seem to have two working options:
> > (1) Use default kicad.pro  to point it to your
> > library path and your libraries. E.g.:
> > [eeschema]
> > LibDir=~/…somewhere…/Library
> >
> > [eeschema/libraries]
> > LibName1=AtmelCorporation
> > The default kicad.pro  seems to be found in
> >   …/templates
> > with “…” again being one of the search stack paths (which in
> > contrast to pcbnew/fp-lib-table is at least on OSX not the
> > preferences path).
> > (2) Just put your libraries to
> >   …/library
> >
> > In general, is there anywhere a list of “supplemental” files
> > (libraries, 3d-models, footprints, various kinds of templates,
> > scripts, xml-Files for BOM, etc.) and where they should be located?
>
> base_search_path/share/kicad/library => Schematic component libraries.
> base_search_path/share/kicad/module => Pcb footprint libraries.
> base_search_path/share/kicad/module/packages3d => 3D models libraries.
> base_search_path/share/kicad/template => project templates.
>
> >
> >
> > No. In principle some global configuration files should be used to
> > enumerate search paths in a manner similar to the footprint management
> > code, but when that will happen is anyone's guess. At the moment we all
> > tolerate the current nuisances of the legacy behavior.
> >
> > - Cirilo
> >
> >
> >
> > Regards,
> > Bernhard
> >
> > On 03.11.2014, at 00:33, Wayne Stambaugh  > > wrote:
> >
> >> On 11/2/2014 4:25 PM, Bernhard Stegmaier wrote:
> >>> Hi all,
> >>>
> >>> I am still trying to find out/optimize where what is being loaded
> >>> from (especially for OS X).
> >>> In common/kiface_i.cpp the global search stack for pcbnew is
> >>> initialized with
> >>>  …/modules
> >>>  …/modules/packages3d
> >>> with “…” being some OS specific base paths.
> >>>
> >>> The global search stack seems to be used for eeschema libraries
> >>> and I also found a piece of code which made me think that it is
> >>> also used for loading 3D-models.
> >>> However, fp-lib-table doesn’t seem to use it but only the path
> >>> given for a library in fp-lib-table itself (maybe with some
> >>> environment variables).
> >>>
> >>> Am I missing something or does loading of modules currently
> >>> ignore the global search paths?
> >>
> >> You are not missing anything.  This is by design.  The
> >> fp-l

Re: [Kicad-developers] Stable release version numbers.

[Carl Poirier]

I feel like we wouldn't use the last digit much in a triplet number
because, IIRC, backporting of fixes is not planned. That being said, I
would also begin with at least 2.1, as Cirilo said.

However, I personally vote for numbering the versions a la MATLAB.

On Mon, Oct 20, 2014 at 1:34 AM, Nick Østergaard  wrote:

> 2014-10-20 7:19 GMT+02:00 Cirilo Bernardo :
> > On Mon, Oct 20, 2014 at 8:58 AM, Wayne Stambaugh  >
> > wrote:
> >>
> >> In the past we have used the repo commit number as the stable version
> >> number.  I'm not sure this is the best idea as there can be overlapping
> >> commit numbers in separate branches.  I would like to propose using
> >> something that we can clearly identify as a release version to prevent
> >> confusion due to duplicate commit version numbers.  I recently committed
> >> the stable release policy to the developers documentation but I
> >> intentionally left out the version number section because I wanted to
> >> make sure we are on board with the idea.  It would make it clear to
> >> developers, users and packagers that they are using a stable release
> >> versus a development release.  It also makes it easier to name source
> >> and binary packages.  I'm perfectly happy using the good old fashioned
> >> numerical triplet (#.#.#).  It's easy for most version comparison
> >> functions to deal with.  I suggest for the next stable release we start
> >> at the beginning 1.0.0.  If no one objects, I will update the stable
> >> release policy and add the code to CMakeLists.txt before we get to the
> >> next stable release.
> >>
> >> Thanks,
> >>
> >> Wayne
> >
> >
> > I'm not in favor of 1.0.0 because this suggests that this is the first
> > release after Beta.
> > KiCad has a much longer history of  productive use.  I think at least
> 2.1.x
> > - 2 because
> > this is very different from what many Linux distributions consider as the
> > last KiCad
> > stable (old pcb format) and .1 because there has also been a revision of
> the
> > new
> > pcb file format to support 32 copper + 32 tech layers. I don't really
> have
> > any strong
> > preference for the '.1' part, but we definitely need at least '2' for the
> > major version;
> > humans are funny creatures and tend to associate version 1 with an
> inferior
> > product.
> >
> > - Cirilo
>
> I am actually also in favor of the 2 in the major version, just after
> the fact that KiCad has had releases before, and that it has all these
> major changes we all love.
>
> Nick
>
> ___
> 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] kicad-install.sh requiring python-wxgtk3.0

[Carl Poirier]

> i did try this and it said it couldn't satisfy the dependancies..

Hi Jake, you can still install the package this way, inserting the
dependencies that need to be ignored. I built recent KiCads this way.

sudo dpkg --install --ignore-depends=___ python-wxgtk3.0.deb

> If I can find a few savvy volunteers here who use their 14.04 machines
regularly and also want to test this for me, I can propose it be included
in official backports.

Hi Adam,

My main machine is running Xubuntu 14.04. I can test this for you during a
few weeks. After that, I plan tu update to 14.10 myself.

Do I have to compile with KICAD_SCRIPTING_WXPYTHON, or only KICAD_SCRIPTING?

Let me know when the backports are ready.

Regards,

Carl

On Sat, Oct 18, 2014 at 9:40 AM, Nick Østergaard  wrote:

> Hi Adam
>
> I have an ubuntu 14.04 (trusty) available, but I don't use it daily
> though. I can still test the packages for you.
>
> Nick
>
> 2014-10-18 15:20 GMT+02:00 Adam Wolf :
> > *sigh*
> >
> > I have begun the backports process.
> https://wiki.ubuntu.com/UbuntuBackports
> >
> > What this means is that I am creating a PPA of packages that are needed
> for
> > KiCad and are already in 14.10 (utopic), but rejiggering the packages so
> > they're meant for 14.04 (trusty).
> >
> > If I can find a few savvy volunteers here who use their 14.04 machines
> > regularly and also want to test this for me, I can propose it be
> included in
> > official backports.
> >
> > Hopefully this goes as smoothly as getting wxWidgets 3.0 working on this
> > week's OS X release.  (Sometimes I feel we spend more time working on our
> > dependencies than on KiCad!)
> >
> > Adam Wolf
> > Cofounder and Engineer
> > Wayne and Layne, LLC
> >
> > On Sat, Oct 18, 2014 at 5:21 AM, Jake  wrote:
> >>
> >> i did try this and it said it couldn't satisfy the dependancies..
> >>
> >>
> >> On Sat, 18 Oct 2014, Nick Østergaard wrote:
> >>
> >>> So did you ever try what Moses suggested?
> >>>
> >>> https://lists.launchpad.net/kicad-developers/msg15067.html
> >>>
> >>> 2014-10-18 10:30 GMT+02:00 Jake :
> 
>  so i'm trying to install kicad on a fresh install of Ubuntu 14.04,
> which
>  is
>  this years' long-term support version of Ubuntu.
> 
>  it should be easy right?
> 
>  but immediately, the kicad-install.sh script says
>  E: Unable to locate package python-wxgtk3.0
>  E: Couldn't find any package by regex 'python-wxgtk3.0'
> 
>  i looked into it and i see that python-wxgtk3.0 is only available for
>  bleeding-edge installs of Ubuntu 14.10 which only just now came out.
> 
>  this is very frustrating and basically means that anyone not running
>  literally the latest system software can't install kicad.  Is this
>  really
>  necessary?  I have python-wxgtk2.8 available to me, is that not
>  sufficient?
> 
>  I am not an expert with aptitude and sources, and i have no idea how
> to
>  get
>  python-wxgtk3.0 onto my system, so i just installed python-wxgtk2.8
>  and i took out that line from kicad-install.sh and i'm trying again.
> 
>  but if possible, i think it would be ideal if this requirement were
>  taken
>  out.  I can't in good conscience keep telling people that they should
>  switch
>  to kicad if i can't even figure out how to install it myself.
> 
>  apologies if i'm missing something basic, or if my tone is frustrated.
> 
>  thank you,
>  -jake
> 
>  ___
>  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
>
___
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] Library Editor naming consistency

[Carl Poirier]

Well, going back to what the manual states it was before is indeed a good
point.

If this is the final decision, I'll update the library convention.

On Tue, Oct 14, 2014 at 5:20 PM, Brian Sidebotham <
brian.sidebot...@gmail.com> wrote:

> On 14 October 2014 22:16, Mark Roszko  wrote:
> > Be it just semantics but for me
> >
> > Documentation != Manual != Specifications
> >
>
> It is probably just semantics, but then this is wrong because
> apparently Documentation != Manual !?
>
> > I wish the manuals were plain text based, I would be more than happy
> > to update documentation as I change things. I do it all the time with
> > the Linux kernel patches I upstream where its a requirement ;)
>
> Best Regards,
>
> Brian.
>
> ___
> 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] Library Editor naming consistency

[Carl Poirier]

Benoît, this is exactly what I tried to say. I wasn't talking about symbols
in Altium, but about components. They are already associated with
footprints and so on, thus making them components. The drawing that we are
working on in the schematic library editor is a symbol. In the component
properties, we can only put a filter on footprints for it, but AFAIK,
that's about it. So I'd say it still stands as a symbol. If some more
pairing is going to be done in this editor, such as a unique footprint, a
SPICE model, and so on, then we might as well call the editor a component
editor. But what if it's used to create only a symbol?

Furthermore, how would the symbol and component libraries be
differentiated, once some more serious associations are done? Will they all
be mixed together? I think that's also part of the problem.

On Mon, Oct 13, 2014 at 8:10 AM, Benoît Roehr 
wrote:

> In KiCAD each project can have its own library of footprints, so this idea
>> duplicates, that exist already.
>>
> OK thanks ! I did not know about it before :)
>
> Le 13/10/2014 13:21, LordBlick a écrit :
>
>> In response to a message written on 13.10.2014 12:04, from Benoît Roehr:
>>
>>> Le 13/10/2014 11:40, LordBlick a écrit :
>>>
 In response to a message written on 13.10.2014 08:01, from Benoît
 Roehr:

> For kicad, it could be a good thing to be able to embed a single
> footprint to a
> component if the footprint is really special, but it's non sens if you
> can
> appropriately tag the footprint and put it with the others.
>
 There is a special field to assign footprint to schematic element…

>>> Yes i know, I was meaning if you need a very special footprint just for
>>> one
>>> component, you may not want to pollute your existing pcblibrary with this
>>> footprint. For example, you have just one component packaged in a 2 rows
>>> QFN
>>> package. You don't want this in your standard QFN lib.
>>> So the ability to attach a single footprint directly to the component
>>> without
>>> creating or modifying a PCBLib can be useful.
>>> But it is new feature and it doesn't have to be implemented yet. Not
>>> important.
>>> Footprint have to be well named, and all searchable in the same place,
>>> not
>>> hidden. ;) More important for me would be a footprint preview in schlib
>>> editor.
>>>
>> In KiCAD each project can have its own library of footprints, so this
>> idea ​​
>> duplicates, that exist already.
>>
>
>
> ___
> 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] Library Editor naming consistency

[Carl Poirier]

Is component" the official naming? What about symbol? As was discussed in
the other thread, I am convinced the former should be reserved for a future
feature consisting of the marriage of different things, such as a symbol, a
footprint, a SPICE and 3d model. Else, how are we going to call these? I
have used Altium, and as Andy Peters said, this is how these guys call it,
too.

On Sun, Oct 12, 2014 at 9:14 PM, Mark Roszko  wrote:

> Very minor but the main KiCAD window calls it "Schematic Library
> Editor", eeschema calls it "Library Editor" and the window itself is
> "Parts Library Editor".
>
> Can the name be standardized?
>
> It might be better to just call it "Component Library Editor" because
> that's what the schematic symbols are called instead of Parts. Just
> like PCB Footprint Editor is for Footprints.
> --
> Mark
>
> ___
> 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] [PATCH] Rename instances of "module" to "footprint" for consistency

[Carl Poirier]

I totally agree with Andy Peters.

Symbol for the schematic parts and footprint for the PCB parts. If KiCad
ever gets to the point of having predefined symbol-footprint-3D-SPICE-etc.,
then it would be great to be able to describe these as components, without
disturbing the nomenclature of something else.

Whatever the final decision is, I'll make sure consistency extends to the
libraries.

On Wed, Oct 8, 2014 at 1:40 PM, Andy Peters  wrote:

> On Oct 8, 2014, at 5:08 AM, Mark Roszko  wrote:
> >> I use footprint myself.  Though footprint seems to imply what a PCB
> >> must have in order to accommodate a part, eg, pads, silk.  Are the 3d
> >> models part of this?  If they are, then footprint might not be the
> >> best term.
> >> I agree with this. What you want to rename "Footprint" is more or less
> a container unifying different PCB objects (pads, lines, 3d model...), but
> may not be a footprint (logos, mounting holes, screws...)
> >
> > Personally I think "Components" may be an even better word than
> > "modules" or "footprints" but suggesting that may have been even more
> > radical and conflicting agaisn't the next point
>
> My two cents, based on the terminology used by every employer for whom
> I've worked:
>
> a) A footprint is what defines how a part gets attached to a PCB. It
> includes the pad/holes for lead attach, as well as silkscreen for refdes
> and outline, and the other assembly layers such as soldermask, solder paste
> and glue dots. "Land patterns" really only describe the lead attach, and
> not the other stuff.
>
> I think Pads calls this a "decal." The only context I've seen the term
> "module" refer to a PCB footprint is in Kicad.
>
> "Footprint" is the term used by most of us here in the colonies.
>
> b) A symbol is what defines a part for a schematic.
>
> c) A component is the marriage of the footprint and the symbol, and
> possibly a 3D model, a SPICE model, a VHDL entity or Verilog module, and so
> forth. This is the Altium nomenclature.
>
> d) A module is a completed assembly or subassembly which is installed as
> one unit on a PCBA. The various DC-DC converters you can buy from TI and
> Linear Tech are modules.
>
> So my vote, if there's a move to change Kicad terminology, is to replace
> the term "module" with "footprint."
>
> -a
>
>
> ___
> 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] 3d models in .pretty repositories?

[Carl Poirier]

Hi,

Thanks all for your input. Wayne, if the I/O is abstracted and well
maintainable, as you mentioned, would you support this? If no, what are the
reasons?

Carl

On Mon, Sep 22, 2014 at 6:56 PM, Wayne Stambaugh 
wrote:

> On 9/22/2014 5:37 PM, Cirilo Bernardo wrote:
> >> 
> >> From: Carl Poirier 
> >> To: Cirilo Bernardo 
> >> Cc: KiCad Developers 
> >> Sent: Tuesday, September 23, 2014 7:23 AM
> >> Subject: Re: [Kicad-developers] 3d models in .pretty repositories?
> >>
> >>
> >>
> >> 3D models could be retrieved only as needed, like footprints. I don't
> see how this would be more polluting than in kicad-library which is
> installed locally.
> >>
> >>
> >> I know the github plugin serves only footprints. That's why I wonder
> how hard it would be to adapt it.
> >>
> >
> >
> > The issue is how to adapt things so that they are useful and not make
> the code
> > unmaintainable. If 3D models are to be retrieved from the network then
> this
> > will touch the 3Dviewer, VRML exporter, and in the future the IDF
> exporter; no
> > one wants to maintain network related code in all these tools.
> > So first of all we need to abstract things so that at least these 3 tools
> > are not really aware that they are performing a network access - so I
> would
> > look into abstracting the file loading operation and investigate if it is
> > possible to do this for the current footprint code as well as the VRML
> and IDF
> > code. To speed up operation it would be good to create local copies as
> data is
> > downloaded and this local cache must be checked before downloading a
> model on
> > the network - once again this can be done via a file loading abstraction.
> > It would also be good to check md5 hashes of the data and allow the
> users to
> > update a model if desired.
> >
> > This file loading abstraction might also serve eeschema in the future for
> > accessing schematic symbol files. I think that doing a good job of
> implementing
> > 3d model downloads via the net is not a small job. Although a quick hack
> will
> > not be that difficult I don't believe it would be maintainable either,
> especially
> > not as tools using 3d models are added in the future; I don't think
> anyone
> > wants to create yet another refactoring job.
> >
> > - Cirilo
>
> I do not support the idea of saving models in pretty libraries.  I also
> reject the idea of using PCB_IO for loading 3D models.  I do support the
> idea of abstracting out any useful low level code from the IO_MGR object
> to create an I/O architecture for 3D models or any other place where it
> makes sense.  3D model I/O and footprint library I/O are not
> interchangeable and I do not want the 3D I/O polluting the footprint I/O
> code.  I know that Tom has proposed a plug in model that may serve this
> purpose as well.  I don't know if he has made any progress on this front.
>
> At some point the IO_MGR concept will be used for schematics and
> component libraries.  I believe I added this development road map
>
> Wayne
>
>
> ___
> 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] 3d models in .pretty repositories?

[Carl Poirier]

3D models could be retrieved only as needed, like footprints. I don't see
how this would be more polluting than in kicad-library which is installed
locally.

I know the github plugin serves only footprints. That's why I wonder how
hard it would be to adapt it.

On Mon, Sep 22, 2014 at 4:49 PM, Cirilo Bernardo 
wrote:

> >____
> > From: Carl Poirier 
> >To: KiCad Developers 
> >Sent: Tuesday, September 23, 2014 4:03 AM
> >Subject: [Kicad-developers] 3d models in .pretty repositories?
> >
> >
> >
> >Hi folks,
> >
> >
> >Is there any reason to have the 3d models in the kicad-library
> repository? They are tied to footprints actually, so why no putting them
> alongside? I think it would make for a much cleaner library.
> >
> >
> >Also, when retrieving a footprint from github automatically, it could
> pull the model as well. If it makes sense, is anyone familiar enough with
> the github plugin to chime in and give an insight on the work that would
> need to be done?
> >
> >
>
>
> I had commented on the 3d models many months ago. I do not believe
> they should be in the .pretty directories since they will only
> pollute; I think they should be in their own top level directory
> and separate from the .pretty and schematic symbol files since
> many people don't want 3D models.
>
> At the moment the github plugin only serves the footprints; it has
> absolutely nothing to do with 3D models. There is code there which
> can be used to retrieve generic files via git/github but any
> proposal for retrieval of files from the network has to be
> carefully thought out.
>
> - Cirilo
>
>
___
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] 3d models in .pretty repositories?

[Carl Poirier]

I was thinking of simply moving the actual files in the .pretty
repositories, and keep them separate from the .kicad_mod files. They could
then get retrieved only when the user asks for the board's 3D
representation, and as such, not put an extra burden on the retrieval of
the footprints.

On Mon, Sep 22, 2014 at 2:11 PM, Jean-Paul Louis  wrote:

> Carl,
>
> I agree 100% with you. The 3D model of the package should be tied to the
> shape library.
> The only concern is the size of the 3D model file, and the fact that some
> users will never use the 3D capability.
> I have no idea on what mechanism will allow to include the 3D shape unless
> the format used is text based, so it could be then part of the part itself.
> I know IGES is text based, but I do not know what is the format of the
> current files (wings?)
>
> Just my $0.02
>
> Jean-Paul
> AC9GH
>
> On Sep 22, 2014, at 2:03 PM, Carl Poirier 
> wrote:
>
> > Hi folks,
> >
> > Is there any reason to have the 3d models in the kicad-library
> repository? They are tied to footprints actuall
>
>
___
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] 3d models in .pretty repositories?

[Carl Poirier]

Hi folks,

Is there any reason to have the 3d models in the kicad-library repository?
They are tied to footprints actually, so why no putting them alongside? I
think it would make for a much cleaner library.

Also, when retrieving a footprint from github automatically, it could pull
the model as well. If it makes sense, is anyone familiar enough with the
github plugin to chime in and give an insight on the work that would need
to be done?

Regards,

Carl
___
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 for reference and value text

[Carl Poirier]

Thanks for the explanation, I see now how it can be useful to change it. I
will specify the default in the convention.

Regards,

Carl

On Sun, Sep 14, 2014 at 10:12 AM, Lorenzo Marcantonio <
l.marcanto...@logossrl.com> wrote:

> On Sun, Sep 14, 2014 at 09:52:53AM -0400, Carl Poirier wrote:
> > So it now makes sense to add to the library convention that value and
> > reference must be on silk?
>
> It make sense because it's the default; I personally I'd have greater
> use for reference on fabrication (since the refdes on silk it's meant to
> be moved on, more often than not, hidden). It's a library convention you
> should decide on.
>
> Before they were fixed on the silk of the layer the component was
> mounted to. Now they *defaults* there but can be 'relayered' freely.
>
> One application for this is the following: when having pushbuttons on
> the back layer (hand soldered usually), you really don't spend money for
> a secondary silk just for them. Relocating the silk on front (while the
> component is back) you could have a useful silk for assembly and
> troubleshooting.
>
> When the expansion routinee will be in place that could ever be some
> user text like (%R) that would give the reference in parenthesis.
>
> --
> 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

Re: [Kicad-developers] Layer for reference and value text

[Carl Poirier]

So it now makes sense to add to the library convention that value and
reference must be on silk?

On Sun, Sep 14, 2014 at 4:55 AM, Brian Sidebotham <
brian.sidebot...@gmail.com> wrote:

> On 14 September 2014 06:17, Lorenzo Marcantonio
>  wrote:
> > On Sun, Sep 14, 2014 at 12:39:33AM -0400, Carl Poirier wrote:
> >> Is there any way to have it not on silkscreen, besides editing the
> >> .kicad_mod file by hand?
> >
> > Committed yesterday; now the text module dialog contains the layer combo
> like
> > for graphics item.
> >
> > Like graphic items, starts by default on silk, after that you can change
> > the layer. This is for both reference/value and user text, so you can
> > add module text to comments or whatever.
> >
> > Heavy testing is of course appreciated :D
> >
> > --
> > Lorenzo Marcantonio
> > Logos Srl
> >
>
> Thanks for taking on this work Lorenzo - looks like it's underway
> nicely. Thank-you
>
> Best Regards,
>
> Brian.
>
> ___
> 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] Layer for reference and value text

[Carl Poirier]

Is there any way to have it not on silkscreen, besides editing the
.kicad_mod file by hand?

On Fri, Sep 12, 2014 at 12:19 PM, Lorenzo Marcantonio <
l.marcanto...@logossrl.com> wrote:

> During coding and after pondering on my finding I realized the
> following:
>
> "There is *nothing* mandating reference and values to be on silk"
>
> They are simply put there by default. So we can just let the user put
> them on another layer if he wants; I personally would put the master
> reference on assembly and another reference (to be macroexpanded) on
> a user text on silk.
>
> Of course that would be a library convention. But it would solve all of
> my use cases, for example.
>
> Another thing: the layer processing for modules on text is *exactly* the
> same as the one for graphic items (not a surprise). In fact the big fat
> warning for entities on copper is still there! Do we already have
> some cpp file where to put these misc utilities refactored around?
>
> --
> 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

Re: [Kicad-developers] How to track down an exception?

[Carl Poirier]

Hi Lorenzo,

Did you try with the option "allow_pretty_writing_to_this_dir" for the
corresponding entry in the fp-lib-table ? This way, the writing should be
saved locally in there, and next time you load the module, you should see
your changes.

There is more information about that in the documentation for the github
plugin.

Carl

On Thu, Sep 11, 2014 at 8:14 AM, Lorenzo Marcantonio <
l.marcanto...@logossrl.com> wrote:

> On Thu, Sep 11, 2014 at 01:52:24PM +0200, Lorenzo Marcantonio wrote:
> > Still wrestling with the random fault when doing a module change.
> > Sometimes it segfaults, sometimes it throws a std:bad_alloc exception.
> >
> > Usually symptoms of an heap smash...
>
> Update: I finally found a way to throw it reliably.
>
> Open in pcbnew a 'library board' (a board containing the modules for
> a library). I'm using the newer .pretty libraries. Pick a module and
> open it for edit.
>
> Choose from the toolbar the library and re-write the module in the
> library (with the save button in the module editor). This seems to be
> the operation that triggers the initial corruption (I think).
> The interesting thing is that I don't see a write on the .kicad_mod
> file... shouldn't it be happen at this time or is there some caching
> mechanism?
>
> Close the module editor. Go to the same module (it's important!) and do
> a 'change module' operation on it. It should reload the same module but
> instead it throws that exception...
>
> The last things I see in strace are statting the .kicad_mod file (*not*
> opening it) and then updating the pcbnew and kicad_common config files
> (triggered by stack unwinding, I presume)
>
> I hate these things...
>
> --
> 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

Re: [Kicad-developers] Configuration file relocation.

[Carl Poirier]

It's done.

Initially I was getting the message "patch does not apply" from git. I ran
it again with "--ignore-whitespace" and it applied, but IDK why it inserted
carriage returns. I thus removed them by hand.

Let me know if it's not alright.

Carl

On Tue, Sep 9, 2014 at 2:28 PM, Wayne Stambaugh 
wrote:

> On 9/6/2014 1:20 PM, Moses McKnight wrote:
> > On 09/06/2014 09:52 AM, Wayne Stambaugh wrote:
> >> On 9/5/2014 10:56 PM, Moses McKnight wrote:
> >>> On 09/05/2014 04:31 PM, Wayne Stambaugh wrote:
> >>>> I just committed Moses' configuration file relocation patch in r5114.
> >>>>
> >>>> On Linux the configuration files are now located in
> $HOME/.config/kicad
> >>>> per the FreeDesktop.org specification.  To preserve you current
> >>>> settings, you can move the kicad configuration files for your $HOME
> >>>> folder to the new location.  You must drop the leading . from the file
> >>>> name.  You must also move the fp-lib-table file.  You will have to
> make
> >>>> copies of these files if you plan on using any version of kicad
> >>>> prior to
> >>>> r5114.
> >>>>
> >>>> Sorry windows users but you will have to reconfigure KiCad.  There was
> >>>> no easy way to extract the registry keys into configuration files.
> The
> >>>> configuration files on Windows will be saved in the same folder as
> >>>> fp-lib-table which is %APPDATA%\kicad.  You may want to clean the
> kicad
> >>>> cruft from the registry if your not going to use any versions of kicad
> >>>> prior to r5114.
> >>>>
> >>>> There should be no change for OSX users.
> >>>
> >>> Hi Wayne, I'm pretty sure this is not true?  I just dug through the
> >>> wxWidgets source, and it looks like before wxFileConfig wrote the files
> >>> on OSX in ~/Library/Preferences, but they now go in
> >>> ~/Library/Preferences/kicad.
> >>>
> >>> It appears the same was true for fp-lib-table.  As such, the patch I
> had
> >>> come up with for the library install is attached to this email.  I had
> >>> not sent it before because I was not certain the new config location
> for
> >>> OSX was the best place, and then kind of forgot about it.
> >>>
> >>> Thanks, Moses
> >>
> >> Thanks for the heads up.  Will someone who knows where the configuration
> >> files on OSX are supposed to go according to Apple's guideline please
> >> confirm this before I apply any more patches?
> >
> > FYI, the patch I attached was just for the fp-lib-table install, the
> > patch you already applied is already looking for fp-lib-table in the new
> > location (~/Library/Preferences/kicad)  The patch that you sent and Carl
> > Poirier applied to the kicad library repository, installs the
> > fp-lib-table in ~/Library/Preferences/.config/kicad instead.
> >
> > I noticed that there were tabs in the patch I sent, so I've attached
> > another one that should be formatted correctly.
> >
> > Moses
> >
>
> Would someone with commit access to the kicad library repo on github
> please apply this patch when they get a chance.
>
> Thanks,
>
> Wayne
>
>
> ___
> 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] new person onboarding

[Carl Poirier]

Hi Mitch,

You can find links to two documents that will help you get started if you
want to give a hand as well, here
<https://github.com/KiCad/kicad-library/wiki>.

On Mon, Sep 8, 2014 at 9:24 PM, Mitch Davis 
wrote:

> Hi Carl,
>
> On Tue, Sep 9, 2014 at 6:34 AM, Carl Poirier 
> wrote:
> >
> > One area you can easily give a hand is in the libraries. We have devised
> a
> > set of rules a few months ago which form our Library Convention.
>
> Can you please tell me where the rules are?
>
> Thanks,
>
> 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] new person onboarding

[Carl Poirier]

My bad, it looks like you first have to be part of the kicad-lib-committers
team to subscribe. What I suggest is you do a first contribution without
it, and if you wish to contribute further, we will add you to the team.

We will continue this in a personal conversation.

Carl

On Mon, Sep 8, 2014 at 5:37 PM, A. V. Dolganoff  wrote:

> Well, this is one fine place to start, why not. Is this list by invite
> only? I cannot see a "subscribe to " anywhere:
> https://launchpad.net/~kicad-lib-committers ?
>
> Alexei
>
> On Mon, Sep 8, 2014 at 10:34 PM, Carl Poirier 
> wrote:
> > Hi Alexei,
> >
> > One area you can easily give a hand is in the libraries. We have devised
> a
> > set of rules a few months ago which form our Library Convention. We have
> yet
> > to adjust all the symbols and footprints to respect these rules, and we
> need
> > as well to approve all the pull requests coming in. There is therefore no
> > development experience needed.
> >
> > If this is of interest to you, I suggest you join the
> kicad-lib-committers
> > mailing list, and we can start off something from there.
> >
> > Regards,
> >
> > Carl Poirier
> >
> > On Mon, Sep 8, 2014 at 3:18 PM, A. V. Dolganoff 
> wrote:
> >>
> >> Hello, everybody,
> >>
> >> I've joined the team and the list just few hours ago after quite some
> >> time spent in kicad-users list/group and other forums because I think
> >> Kicad has great future and is worth to contribute too.
> >> Few words about me: I live near Paris and work in software industry, I
> >> am an ERP consultant by trade (ERP=Enterprise Ressource Planning,
> >> mainly SAP, Oracle Apps and Peoplesoft, my job has nothing to do with
> >> electronics whatsoever), and I am an electronics hobbyist and musician
> >> during my off-hours, so naturally my electronics projects always
> >> gravitate to music-related electronics.
> >> I've switched to Kicad few years ago because it does most of I want
> >> from an EDA, is free and evolves constantly!
> >> I am starting to release my projects under Open Hardware license and
> >> Kicad fits there perfectly. At the same time I am able to sell some of
> >> my designs, nothing to blow your mind financially, I am just able to
> >> offset some of my hobby expenses...
> >>
> >> Now, I would like to contribute something. The thing is I am not a
> >> great developer (not a developer at all in fact...), but I could take
> >> some tasks related to documentation, tutorials and such.
> >> My English is not my native language, maybe I could start with some
> >> French translations or something of the sorts?
> >>
> >> If you have any docs introducing new participants to the toolchain,
> >> general practices, what steps to take at first etc., I am happy to
> >> start anywhere!
> >>
> >> Cheers, Alexei
> >>
> >> ___
> >> 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] new person onboarding

[Carl Poirier]

Hi Alexei,

One area you can easily give a hand is in the libraries. We have devised a
set of rules a few months ago which form our Library Convention. We have
yet to adjust all the symbols and footprints to respect these rules, and we
need as well to approve all the pull requests coming in. There is therefore
no development experience needed.

If this is of interest to you, I suggest you join the kicad-lib-committers
mailing list, and we can start off something from there.

Regards,

Carl Poirier

On Mon, Sep 8, 2014 at 3:18 PM, A. V. Dolganoff  wrote:

> Hello, everybody,
>
> I've joined the team and the list just few hours ago after quite some
> time spent in kicad-users list/group and other forums because I think
> Kicad has great future and is worth to contribute too.
> Few words about me: I live near Paris and work in software industry, I
> am an ERP consultant by trade (ERP=Enterprise Ressource Planning,
> mainly SAP, Oracle Apps and Peoplesoft, my job has nothing to do with
> electronics whatsoever), and I am an electronics hobbyist and musician
> during my off-hours, so naturally my electronics projects always
> gravitate to music-related electronics.
> I've switched to Kicad few years ago because it does most of I want
> from an EDA, is free and evolves constantly!
> I am starting to release my projects under Open Hardware license and
> Kicad fits there perfectly. At the same time I am able to sell some of
> my designs, nothing to blow your mind financially, I am just able to
> offset some of my hobby expenses...
>
> Now, I would like to contribute something. The thing is I am not a
> great developer (not a developer at all in fact...), but I could take
> some tasks related to documentation, tutorials and such.
> My English is not my native language, maybe I could start with some
> French translations or something of the sorts?
>
> If you have any docs introducing new participants to the toolchain,
> general practices, what steps to take at first etc., I am happy to
> start anywhere!
>
> Cheers, Alexei
>
> ___
> 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] Configuration file relocation.

[Carl Poirier]

I'm applying the patch to the library install.

Thanks a bunch for all of that.

Carl


On Fri, Sep 5, 2014 at 6:20 PM, Wayne Stambaugh 
wrote:

> Glad we could lower your blood pressure a little. :)
>
> On 9/5/2014 6:18 PM, Adam Wolf wrote:
> > Amazing, excellent work folks.  I was getting a little blood pressure
> > spike with these little droppings all over my home directory...
> >
> > Adam Wolf
> >
> > On Sep 5, 2014 4:59 PM, "Wayne Stambaugh"  > > wrote:
> >
> > I just committed Moses' configuration file relocation patch in r5114.
> >
> > On Linux the configuration files are now located in
> $HOME/.config/kicad
> > per the FreeDesktop.org specification.  To preserve you current
> > settings, you can move the kicad configuration files for your $HOME
> > folder to the new location.  You must drop the leading . from the
> file
> > name.  You must also move the fp-lib-table file.  You will have to
> make
> > copies of these files if you plan on using any version of kicad
> prior to
> > r5114.
> >
> > Sorry windows users but you will have to reconfigure KiCad.  There
> was
> > no easy way to extract the registry keys into configuration files.
> The
> > configuration files on Windows will be saved in the same folder as
> > fp-lib-table which is %APPDATA%\kicad.  You may want to clean the
> kicad
> > cruft from the registry if your not going to use any versions of
> kicad
> > prior to r5114.
> >
> > There should be no change for OSX users.
> >
> > Can someone please apply the attached patch to the library install in
> > the github repo so the fp-lib-table file gets installed in the
> correct
> > path by anyone using the kicad-install.sh script.
> >
> > Thank you Moses for contributing to KiCad.
> >
> > Sorry about the inconvenience but this change fixes the $HOME folder
> > configuration file pollution on Linux and removing the configuration
> > from the Windows registry which both users and developers have been
> > pushing for.
> >
> > Cheers,
> >
> > Wayne
> >
> > ___
> > 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

Re: [Kicad-developers] Compilation error

[Carl Poirier]

That did it.

Thanks for all the information,

Carl


On Wed, Sep 3, 2014 at 11:31 AM, Andrew Zonenberg <
azonenb...@drawersteak.com> wrote:

> The specific issue at hand, for your reference, is
> http://trac.wxwidgets.org/ticket/16423. I found this while debugging a
> segfault while running the DRC but it could happen anywhere that the
> "busy" cursor is used.
>
> On Wed, 2014-09-03 at 17:01 +0200, Maciej Sumiński wrote:
> > Hi Carl
> >
> > Recently there was a discussion about bugs in 3.0.1 (topic: Segfault
> > when running DRC). It might be a better choice to switch to the
> > bleeding edge.
> >
> > Regards,
> > Orson
> >
> > On 09/03/2014 04:59 PM, Carl Poirier wrote:
> > > I will try that. Thanks.
> > >
> > >
> > > On Wed, Sep 3, 2014 at 9:51 AM, Wayne Stambaugh
> > >  wrote:
> > >
> > >> On 9/3/2014 9:49 AM, Carl Poirier wrote:
> > >>> Hi people,
> > >>>
> > >>> I am trying to compile KiCad from source on a fresh Xubuntu
> > >>> installation. I started off by compiling and installing
> > >>> wxWidgets 3.0.1.Then, for KiCad, I get this error:
> > >>>
> > >>> [ 45%] Building CXX object
> > >>> common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o In file included
> > >>> from
> > >>> /home/thesmith/kicad/kicad/common/draw_panel_gal.cpp:38:0:
> > >>> /home/thesmith/kicad/kicad/include/gal/opengl/opengl_gal.h:62:1:
> > >>> error: expected class-name before ‘{’ token { ^
> > >>> /home/thesmith/kicad/kicad/include/gal/opengl/opengl_gal.h:256:12:
> > >>>
> > >>>
> > error: ‘wxGLContext’ does not name a type
> > >>> static wxGLContext* glContext;  ///< OpenGL
> > >>> context of wxWidgets ^ make[2]: ***
> > >>> [common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o] Error 1
> > >>> make[1]: *** [common/CMakeFiles/gal.dir/all] Error 2 make: ***
> > >>> [all] Error 2
> > >>>
> > >>> Is anyone aware of a reason and/or solution?
> > >>>
> > >>> Carl
> > >>>
> > >>
> > >> Did you build wxWidgets with the --with-opengl flag?  If memory
> > >> servers, this is not enabled by default.
> > >>
> > >>
> > >>
> > >> ___ 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
>
> --
> Andrew Zonenberg
> PhD student, security group
> Computer Science Department
> Rensselaer Polytechnic Institute
> http://colossus.cs.rpi.edu/~azonenberg/
>
___
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] Compilation error

[Carl Poirier]

I will try that. Thanks.


On Wed, Sep 3, 2014 at 9:51 AM, Wayne Stambaugh 
wrote:

> On 9/3/2014 9:49 AM, Carl Poirier wrote:
> > Hi people,
> >
> > I am trying to compile KiCad from source on a fresh Xubuntu
> > installation. I started off by compiling and installing wxWidgets
> > 3.0.1.Then, for KiCad, I get this error:
> >
> > [ 45%] Building CXX object common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o
> > In file included from
> > /home/thesmith/kicad/kicad/common/draw_panel_gal.cpp:38:0:
> > /home/thesmith/kicad/kicad/include/gal/opengl/opengl_gal.h:62:1: error:
> > expected class-name before ‘{’ token
> >  {
> >  ^
> > /home/thesmith/kicad/kicad/include/gal/opengl/opengl_gal.h:256:12:
> > error: ‘wxGLContext’ does not name a type
> >  static wxGLContext* glContext;  ///< OpenGL context
> > of wxWidgets
> > ^
> > make[2]: *** [common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o] Error 1
> > make[1]: *** [common/CMakeFiles/gal.dir/all] Error 2
> > make: *** [all] Error 2
> >
> > Is anyone aware of a reason and/or solution?
> >
> > Carl
> >
>
> Did you build wxWidgets with the --with-opengl flag?  If memory servers,
> this is not enabled by default.
>
>
>
> ___
> 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] Compilation error

[Carl Poirier]

Hi people,

I am trying to compile KiCad from source on a fresh Xubuntu installation. I
started off by compiling and installing wxWidgets 3.0.1.Then, for KiCad, I
get this error:

[ 45%] Building CXX object common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o
In file included from
/home/thesmith/kicad/kicad/common/draw_panel_gal.cpp:38:0:
/home/thesmith/kicad/kicad/include/gal/opengl/opengl_gal.h:62:1: error:
expected class-name before ‘{’ token
 {
 ^
/home/thesmith/kicad/kicad/include/gal/opengl/opengl_gal.h:256:12: error:
‘wxGLContext’ does not name a type
 static wxGLContext* glContext;  ///< OpenGL context of
wxWidgets
^
make[2]: *** [common/CMakeFiles/gal.dir/draw_panel_gal.cpp.o] Error 1
make[1]: *** [common/CMakeFiles/gal.dir/all] Error 2
make: *** [all] Error 2

Is anyone aware of a reason and/or solution?

Carl
___
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] git repository for eeschema lib files ?

[Carl Poirier]

Hi Yann,

The process for contributing to the symbols library is the same, which is
explained here
. The
repository Wayne mentioned is the right place.

Carl


On Tue, Aug 26, 2014 at 11:31 AM, Wayne Stambaugh 
wrote:

> On 8/26/2014 10:53 AM, yann jautard wrote:
> > Hi all,
> >
> > I wonder if we can't add lib files to the footprint repository, or to
> > another repository. Even if there is not at the moment the same
> > fp-lib-table system for eeschema, it could be a convenient way to
> > distribute and contribute to library files.
> >
> > Just an idea coming while I found an IRF2104 lib file just after making
> > my own...
> >
> > regards,
> >
> > yann
> >
>
> They are in the GibHub repo at:
>
> https://github.com/KiCad/kicad-library/tree/master/library
>
> I don't see any reason not to improve the component libraries as well as
> the footprint libraries.  Check with Carl about contributing.  I'm sure
> any help would be welcomed.
>
>
> ___
> 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] New Project Leader

[Carl Poirier]

Greetings Dick,

Thanks a bunch for all the big contributions you made for KiCad. I have
followed all what has happened on the mailing list since I subscribed, and
it's amazing to see how KiCad has come a long way from then. And I am sure
you have been as influential before then. Many thanks for your helpful
attitude towards the newcomers and also the more seasoned developers.

Since you are going to continue using KiCad, I beg you to send us your
newly created footprints and symbols. The work I have started with your
help will greatly benefit from this.

I wish you the best of all, and take care.


On Fri, Aug 22, 2014 at 1:11 PM, Peter Voorhees  wrote:

> Hi Dick,
>
> On behalf of all the grateful anonymous users/lurkers who watch the
> list.
>
> Thank you for all your effort; we appreciate everything you've done on
> our behalf and for our benefit.
>
> All the best in your next endeavor.
>
> --Everyone
>
>
> *"Give me six lines written by the most honorable of men, and I will
> find an excuse in them to hang him." -- Cardinal Richelieu*
>
> On Fri, Aug 22, 2014, at 12:41 PM, Dick Hollenbeck wrote:
> > Ladies and Gentlemen:
> >
> > With great respect and humility I am turning over KiCad project
> > leadership to
> >
> >Mr. Wayne Stambaugh.
> >
> > Wayne has established himself as a seasoned leader and software
> > architect.
> >
> > His software architectural skills and leadership skills make him in my
> > opinion the best of
> > available persons to fill this role.  We should hope and wish that he
> > finds the job
> > rewarding and fulfilling in a way that leads to an extended term in this
> > volunteer position.
> >
> > I obviously have confidence in his abilities, but I don't over estimate
> > his staying power,
> > nor should you.  Please be kind and respectful to him.
> >
> >
> > It is time for me to move out of the top spot and off the mailing list.
> >
> >
> >
> > I want to acknowledge Brian Sidebotham with special thanks for his faith
> > in my leadership
> > and his exceptional contributions in the realm of KiCad Winbuilder.  It
> > was his faith in
> > my vision that motivated him to do an unspeakable volunteer effort from
> > which hundreds of
> > KiCad users benefit.  While I thank him for his confidence in that vision
> > of mine, you all
> > should thank him for his actual time and leadership in making KiCad on
> > Windows worth
> > using.  His efforts in promoting CMake as a build engine warrant industry
> > and world-wide
> > acclaim and he is due a bonus from Kitware.
> >
> >
> > I want to acknowledge and thank Fabrizio Tappero, who's graphics/icons,
> > and user manual
> > efforts should go down as some of the most important contributions in
> > KiCad's history.
> >
> >
> > I want to acknowledge and thank Carl Poirier who is overseeing what is
> > quickly becoming a
> > world-wide resource.  At my egging, he stepped up and is now overseeing
> > what is becoming
> > something truly exceptional along with the efforts of generous
> > contributors.  I wish him
> > the best, I encourage him to be a leader and encourager among reluctant
> > volunteers. I am
> > proud to have been an inspiration in something that he can proudly put on
> > his resume some day.
> >
> >
> > I want to thank Javier Serano, whose confidence in our project direction
> > and leadership
> > inspired him to join and bring in some additional world class talent and
> > team players, Tom
> > and Orson, as well as KiCad team leadership and seasoned experience.
> >
> >
> > Lastly I want to thank Jean-Pierre for his friendship, for his faith and
> > confidence in my
> > sometimes loud and brash leadership.  But were it not for his stabilizing
> > influence in all
> > things KiCad, we'd all be making less PCB boards, or doing them more
> > expensively.
> >
> >
> > Please take care of my good friend Wayne Stambaugh.  I have prayed with
> > Wayne, I know his
> > son.  You could not have a better man at the helm.
> >
> >
> > Appreciation goes a long way towards keeping this project healthy, and
> > for it to be
> > healthy you need a class act at the top, you have one in Wayne.
> >
> >
> > Dick
> >
> >
> > P.S.
> >
> > *) The project has SoftPLC Corporation's permission to re-license its
> > copyrights under GPL3.
> >
> > *) When s