Attached, tested(on PLD Linux) patch implements the following changes:
- not finished python scripting issue - brings pad.GetZoneConnection() and in
example pad.SetZoneConnection(pcbnew.PAD_ZONE_CONN_FULL) to full workable.
- cleanup namespace pretty artistic disorder in enum ZoneConnection in
pcb
Hi Wayne,
The patch export_idf_20150815_B.patch should be fine to commit;
it's been tested on Linux and MS Windows and behaves as expected.
I haven't received any feedback from OSX users but I don't foresee any
problems.
Thanks,
Cirilo
On Tue, Aug 18, 2015 at 9:15 AM, Wayne Stambaugh
wrote:
Cirilo, is this patch ready to be committed. I have not had time to
test it.
Cheers,
Wayne
On 8/14/2015 7:48 PM, Cirilo Bernardo wrote:
> OK, once more ...
> The attached patch (export_idf_20150815_B.patch) adds an option
> for the legacy Grid Reference behavior of the IDF exporter. I believe
>
Patch committed in r6098. Thanks.
On 8/17/2015 4:56 PM, Chris Pavlina wrote:
> Crap. Been working on other projects lately. Here you go
>
>
> On Mon, Aug 17, 2015 at 04:54:30PM -0400, Wayne Stambaugh wrote:
>> Please check your curly bracket formatting.
>>
>>
>> On 8/17/2015 4:52 PM, Chris Pavl
Using git directly in a plugin would also make the git library a
dependency to build KiCad which in not without it's own set of issues.
On 8/17/2015 3:39 PM, Matthew Beckler wrote:
> Hi Andy,
>
> What you say makes sense. For the purposes of this discussion, git vs
> svn is irrelevant. I also pre
Just my 2c worth but that 'huge history' problem can be solved with
using the
"shallow clone" capability of git.
i.e. git clone --depth 1
Also, I think that all the individual repositories could be combined
as sub modules of a larger master repository and then you just clone
a single repositor
On 8/17/2015 3:26 PM, Andy Peters wrote:
>
>> On Aug 17, 2015, at 12:05 PM, Wayne Stambaugh wrote:
>>
>> If someone wants to write a git plugin, I'm sure some users would find
>> it useful. I'm not sure most users will want to learn git to maintain
>> their footprint libraries even though it's a
The github API is used to get the list of all repositories on the
KiCad group on github. git alone cannot do that.
However the zips from github are requested instead of checking out the
repo via cloning. Theres definitely arguments for cloning vs not. One
of the annoyances I see is some repos can
Here, have another vote of confidence. Very few GUI builders aren't
crap, and most are fairly inflexible. wx is not a difficult toolkit to
work with in general and any developer who can write decent code should
be able to interact with it directly. Perhaps it is not a bad thing for
"can write w
On Tue, Aug 18, 2015 at 3:26 AM, Wayne Stambaugh
wrote:
> On 8/17/2015 9:14 AM, David Novak wrote:
> >> To be honest, I've never been a big fan of dialog box layout tools.
> >> Their strength is there weakness. They promote designing quick dialog
> >> box layouts that makes reuse difficult. Tak
Hi to all,
would it be possible to commit Cirilo's patch?
thank you
Maurice
On 15/08/2015 01.48, Cirilo Bernardo wrote:
OK, once more ...
The attached patch (export_idf_20150815_B.patch) adds an option
for the legacy Grid Reference behavior of the IDF exporter. I believe
that this time I am us
Crap. Been working on other projects lately. Here you go
On Mon, Aug 17, 2015 at 04:54:30PM -0400, Wayne Stambaugh wrote:
> Please check your curly bracket formatting.
>
>
> On 8/17/2015 4:52 PM, Chris Pavlina wrote:
> > Hi,
> >
> > project_rescue creates invalid library files for projects wit
Please check your curly bracket formatting.
On 8/17/2015 4:52 PM, Chris Pavlina wrote:
> Hi,
>
> project_rescue creates invalid library files for projects with
> whitespace in the name (I mistakenly thought that these would be escaped
> on export). Here's a patch to find and replace whitespace
Hi,
project_rescue creates invalid library files for projects with
whitespace in the name (I mistakenly thought that these would be escaped
on export). Here's a patch to find and replace whitespace.
--
Chris
commit 66f634e13576ac682ae20c2d90851ad18aba030b
Author: Chris Pavlina
Date: Mon Aug
W odpowiedzi na wiadomość z dnia 17.08.2015, 22:33, od timofonic timofonic:
Hello.
I'm not a developer at all, but I got curious about this.
KiCad is 500KLOC and 80% of it is about GUI, right? Would rewriting dialog code
by hand require to change a lot of code too? Would it reduce LOC?
I see L
Any more comments on this patch? Or is it good to be committed?
Jon
On Mon, Aug 10, 2015 at 4:42 PM, Jon Neal wrote:
> Suggestion implemented. New version attached.
>
> Jon Neal
>
> On Fri, Aug 7, 2015 at 4:39 AM, Maciej Sumiński
> wrote:
>
>> If I may suggest something, how about wrapping the
Hello.
I'm not a developer at all, but I got curious about this.
KiCad is 500KLOC and 80% of it is about GUI, right? Would rewriting dialog
code by hand require to change a lot of code too? Would it reduce LOC?
I see Libreoffice has some kind of similar issue, but the situation is even
worse. It
"A vendor neutral git API"
Yeah, a git executable client.
I'm not sure why it wasn't made to use a git client in the first place.
I like the idea of KiCad being smart about retrieving the footprints
from github, I'm just not sure why it needed to use the github APIs that
only work with github.
On 18 August 2015 at 07:39, Matthew Beckler
wrote:
>
> Hi Andy,
>
> What you say makes sense. For the purposes of this discussion, git vs svn
is
> irrelevant. I also prefer to keep all my kicad libraries in an svn/git
repository
> and just have to remember to "svn up" / "git pull" on each machine
I hope this isn't a resolved issue. I wanted to put my 2 cents in too.
I think this should be a warning in ERC. If you are methodology based
designer, then you likely do not tie local nets together and if you do,
it was a mistake. This is the only feature in KiCad that has every
burned me a
Hi Andy,
What you say makes sense. For the purposes of this discussion, git vs svn
is irrelevant. I also prefer to keep all my kicad libraries in an svn/git
repository and just have to remember to "svn up" / "git pull" on each
machine I use. As you said, this requires no support from KiCad except
> On Aug 17, 2015, at 12:05 PM, Wayne Stambaugh wrote:
>
> If someone wants to write a git plugin, I'm sure some users would find
> it useful. I'm not sure most users will want to learn git to maintain
> their footprint libraries even though it's a good thing. The gihub
> server implementation
If someone wants to write a git plugin, I'm sure some users would find
it useful. I'm not sure most users will want to learn git to maintain
their footprint libraries even though it's a good thing. The gihub
server implementation was written because KiCad's libraries are
maintained on github whic
I don't really have any stock in this, but *yes* to what this guy said.
On 8/17/2015 2:52 PM, Matthew Beckler wrote:
It seems very strange to target our software at specific
implementations of git front-end websites. It seems even stranger to
suggest to end users to install a web server to act
It seems very strange to target our software at specific implementations of
git front-end websites. It seems even stranger to suggest to end users to
install a web server to act as a proxy to improve performance.
It seems like a simpler approach would be to support local git repositories
in the fi
Wouldn't you also want to test the footprints on the board as well?
Let's say you have multiple "smt_resistor_lib:r0805" footprints on your
board and you modified more than one of them with same changes but
different from the original footprint imported from the library. You
would still have mult
Parameters (or properties as they are defined internally) are passed
defined in the footprint library table. They are simple key=value pairs
that are passed to the plugin defined by each footprint library table
entry. The person that wrote this code thought that it would be more
effort to code a
Lance,
Thank you for interest in helping KiCad. Please keep in mind that KiCad
is 500K or so lines of C++ code so I'm not sure it's the best place to
start learning C++. There is also a lot of legacy code in KiCad that
should *not* be emulated so as a learning project you need to be looking
the
On 8/17/2015 9:14 AM, David Novak wrote:
>> To be honest, I've never been a big fan of dialog box layout tools.
>> Their strength is there weakness. They promote designing quick dialog
>> box layouts that makes reuse difficult. Take a look at the padding and
>> overall layout in KiCad's dialogs.
Hi Lance,
Thank you for considering KiCad as a place to spend some of your time
to help out KiCad.
For general information on how to get started, please have a look at
[1] and look at [2] for some ideas on where to start. I have tried to
list some possible "easy" issues on [2]. But other than tha
On Mon, Aug 17, 2015 at 09:14:43AM -0400, David Novak wrote:
> >To be honest, I've never been a big fan of dialog box layout tools.
> >Their strength is there weakness. They promote designing quick dialog
> >box layouts that makes reuse difficult. Take a look at the padding and
> >overall layout
To be honest, I've never been a big fan of dialog box layout tools.
Their strength is there weakness. They promote designing quick dialog
box layouts that makes reuse difficult. Take a look at the padding and
overall layout in KiCad's dialogs. They are all over the map. I prefer
hand coding di
32 matches
Mail list logo
