I guess that lbr files are for the schematic symbols. If that is the
case, I think the reason is nothing with licensing, but rather that
there is no "plugin" implemented for eeschema as there is in pcbnew,
where one would implement this conversion.
2016-04-08 3:28 GMT+02:00 Daniel Wilches :
> Hell
Hello,
I noticed that to use Eagle's lbr files in Kicad we need to export them
from eagle using an ulp (https://github.com/lachlanA/eagle-to-kicad).
I think it would be beneficial to have Kicad read directly the lbr files,
as that saves time to the user and doesn't require the user to have Eagle.
I'm working on creatign a dummy board with only a few footprint features
on it to aid in aligning models:
https://drive.google.com/open?id=0By_XTJN-s8aXMzdrOF93eXlJelE
At the moment the edge of the board has bad normals - I find the bad
normals a little annoying but I don't think they ruin the u
Committed in rev 6673. Thank you.
On Fri, Apr 08, 2016 at 08:31:50AM +1000, Cirilo Bernardo wrote:
> The attached patch fixes a problem reported by coverity (thanks to Mario
> for the fix):
>
> * CID 143740: Null pointer dereferences (NULL_RETURNS)
> /plugins/3d/vrml/x3d/x3d_appearance.cpp: 122
The attached patch fixes a problem reported by coverity (thanks to Mario
for the fix):
* CID 143740: Null pointer dereferences (NULL_RETURNS)
/plugins/3d/vrml/x3d/x3d_appearance.cpp: 122 in
X3DAPP::readFields(wxXmlNode *)()
A few minor cut/paste and style issues in the 3D code are also fixed.
tys Chris !
I'll try to solve this if you not solved this yet.
Best Regards,
De: Chris Pavlina [pavlina.ch...@gmail.com]
Enviado: terça-feira, 5 de abril de 2016 21:50
Para: Pereira, Patrick
Cc: kicad-developers@lists.launchpad.net
Assunto: Re: RES: [Kicad
Hello,
Attached there is a couple of new possible example scripts in python.
They change the reference designator text size of all the refdes in the
open pcb. The scripts are:
simpleSetAllReferenceSizes.py: simple text only version (as a
simple example)
setAllReferenceSizes.py : uses wx
If there are more than one commit in a given day, add a lower case alpha to the
timestamp
like 20160407, then 20160407a, then 20160407b, and so on.
Just my $0.02
Jean-Paul
N1JPL
> On Apr 7, 2016, at 2:13 PM, Wayne Stambaugh wrote:
>
> I like it. It's more meaningful than an
that we have never made more than one file format change on a
> single day, I think we are safe. :)
>
> On 4/7/2016 2:04 PM, Chris Pavlina wrote:
> > What about using the date the change was made as a "version number"? Can
> > integerize it like 20160407 for example
t; What about using the date the change was made as a "version number"? Can
> integerize it like 20160407 for example. This allows easy cross-referencing of
> a format version with the revision that it was made in, and is guaranteed to
> increase monotonically if you use a YMD for
Le 07/04/2016 20:04, Chris Pavlina a écrit :
> What about using the date the change was made as a "version number"? Can
> integerize it like 20160407 for example. This allows easy cross-referencing of
> a format version with the revision that it was made in, and is guara
I like the date idea, gEDA PCB uses that too
On Thu, Apr 7, 2016 at 1:04 PM, Chris Pavlina wrote:
> What about using the date the change was made as a "version number"? Can
> integerize it like 20160407 for example. This allows easy cross-referencing of
> a format version wit
What about using the date the change was made as a "version number"? Can
integerize it like 20160407 for example. This allows easy cross-referencing of
a format version with the revision that it was made in, and is guaranteed to
increase monotonically if you use a YMD format :)
On T
I guess the documentation you are talking about is:
http://docs.kicad-pcb.org/en/plugins.html
I would like to see the support for this kind of out of tree plugins,
but I am not sure about where it is most wise to put the headers.
2016-04-06 4:17 GMT+02:00 Cirilo Bernardo :
> With the recent merge
Le 07/04/2016 18:42, Chris Pavlina a écrit :
> On Thu, Apr 07, 2016 at 06:36:40PM +0200, jp charras wrote:
>> Le 07/04/2016 17:52, Wayne Stambaugh a écrit :
>>> On 4/7/2016 9:47 AM, Chris Pavlina wrote:
Hi all,
I'm targeting this email primarily at Wayne as versioning and release
>>
On Thu, Apr 07, 2016 at 06:36:40PM +0200, jp charras wrote:
> Le 07/04/2016 17:52, Wayne Stambaugh a écrit :
> > On 4/7/2016 9:47 AM, Chris Pavlina wrote:
> >> Hi all,
> >>
> >> I'm targeting this email primarily at Wayne as versioning and release
> >> policy is
> >> involved.
> >>
> >> We've got
Le 07/04/2016 17:52, Wayne Stambaugh a écrit :
> On 4/7/2016 9:47 AM, Chris Pavlina wrote:
>> Hi all,
>>
>> I'm targeting this email primarily at Wayne as versioning and release policy
>> is
>> involved.
>>
>> We've got a bit of a problem right now. We're currently adding features to
>> the
>> pc
Personally I'm in favor of bumping the version with every feature. I can't see
it getting too annoying on the development branch, as people who use that
generally keep it up to date anyway - and I think it's sane to require them to.
Either use a release, or use development head. :)
On Thu, Apr 07,
On Thu, Apr 07, 2016 at 11:30:18AM -0400, Chris Pavlina wrote:
> I think you misunderstand my suggestion, then. What I want to push into a
> minor
> release is a check to make sure the version is valid - nothing that changes
> the
> format. I want the minor release to start checking the version,
On 4/7/2016 9:47 AM, Chris Pavlina wrote:
> Hi all,
>
> I'm targeting this email primarily at Wayne as versioning and release policy
> is
> involved.
>
> We've got a bit of a problem right now. We're currently adding features to the
> pcbnew format - JP just merged rounded-rect pads and has a pa
I think you misunderstand my suggestion, then. What I want to push into a minor
release is a check to make sure the version is valid - nothing that changes the
format. I want the minor release to start checking the version, so that when we
put out the major release later (which *does* add things to
On Thu, Apr 07, 2016 at 11:01:26AM -0400, Chris Pavlina wrote:
> I'm not sure what you mean by that.
>
> On Thu, Apr 07, 2016 at 04:52:52PM +0200, Marco Ciampa wrote:
> > On Thu, Apr 07, 2016 at 09:47:41AM -0400, Chris Pavlina wrote:
> > [...]
> > > Thoughts?
> >
> > I am not a dev. I KNOW.
> >
I'm not sure what you mean by that.
On Thu, Apr 07, 2016 at 04:52:52PM +0200, Marco Ciampa wrote:
> On Thu, Apr 07, 2016 at 09:47:41AM -0400, Chris Pavlina wrote:
> [...]
> > Thoughts?
>
> I am not a dev. I KNOW.
>
> But... such a change (file and footprint format change) IMHO is not apt
> to (o
On Thu, Apr 07, 2016 at 09:47:41AM -0400, Chris Pavlina wrote:
[...]
> Thoughts?
I am not a dev. I KNOW.
But... such a change (file and footprint format change) IMHO is not apt
to (only) a minor version change...
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
Good point about the footprint files. I'll prepare a patch within a couple days.
On Thu, Apr 07, 2016 at 04:35:05PM +0200, jp charras wrote:
> Le 07/04/2016 15:47, Chris Pavlina a écrit :
> > Hi all,
> >
> > I'm targeting this email primarily at Wayne as versioning and release
> > policy is
> >
Le 07/04/2016 15:47, Chris Pavlina a écrit :
> Hi all,
>
> I'm targeting this email primarily at Wayne as versioning and release policy
> is
> involved.
>
> We've got a bit of a problem right now. We're currently adding features to the
> pcbnew format - JP just merged rounded-rect pads and has a
2016-04-07 16:06 GMT+02:00 jp charras :
> Le 07/04/2016 15:43, Nick Østergaard a écrit :
>> Hi JP
>>
>> It seems that this was merged in 6671, thank your for your work on
>> this, but I think you might have missed one crucial part to this.
>> Namely the board file version bump. To me this does not
Le 07/04/2016 15:43, Nick Østergaard a écrit :
> Hi JP
>
> It seems that this was merged in 6671, thank your for your work on
> this, but I think you might have missed one crucial part to this.
> Namely the board file version bump. To me this does not look like this
> is backward compatible to 4.0
Hi all,
I'm targeting this email primarily at Wayne as versioning and release policy is
involved.
We've got a bit of a problem right now. We're currently adding features to the
pcbnew format - JP just merged rounded-rect pads and has a patch in development
for custom pads, and I'm looking at a pa
Hi JP
It seems that this was merged in 6671, thank your for your work on
this, but I think you might have missed one crucial part to this.
Namely the board file version bump. To me this does not look like this
is backward compatible to 4.0.2 in any sensible way. (I have not
tested nor reviewed the
30 matches
Mail list logo
