kicad-developers team mailing list archive

[Matt Wright <ausinine@...>]

--0016e64699522986560468c2e170 Content-Type: multipart/alternative; boundary=0016e64699522986460468c2e16e

--0016e64699522986460468c2e16e Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi all,

I've recently started using Kicad, and so far I've found it the best of the
alternatives I've tried. I'll probably be using it a lot in the future so
I'd like to contribute to the project, if there's anything I can do to help.

My name is Matt Wright. I'd probably count as a relative beginner programmer
of C++ - I don't have much experience working on team projects or
contributing to open source programs.

While I was using Kicad there were a few features that would have improved
my own personal usage, particularly in gerbview. One of these is the ability
to mirror blocks (maybe not much use if you're getting the pcb manufactured,
but I use it for home etching). I've attached a small patch, if you're
interested. I've tried to follow existing code style, but please let me know
if there's anything you'd like done differently.

On a related note, I know this has been asked a few times on the mailing
list, but just to double-check my understanding, what is the etiquette with
changes to the program? It seems like there are a few locations for work to
be done - TODO.txt and the bug and feature tracking pages. Any I've missed?
I think it's been said before that small changes can just be submitted (for
people with svn write permissions of course). Is this still accurate? What's
the suggested procedure for larger changes like most additional features?
Bouncing the idea and implementation plan off the mailing list first? Adding
an entry to the feature tracker and waiting for comment?

Thanks
Matt
 --0016e64699522986460468c2e16e Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,<br><br>I&#39;ve recently started using Kicad, and so far I&#39;ve f=
ound it the best of the alternatives I&#39;ve tried. I&#39;ll probably be u=
sing it a lot in the future so I&#39;d like to contribute to the project, i=
f there&#39;s anything I can do to help.<br>
<br>My name is Matt Wright. I&#39;d probably count as a relative beginner p=
rogrammer of C++ - I don&#39;t have much experience working on team project=
s or contributing to open source programs.<br><br>While I was using Kicad t=
here were a few features that would have improved my own personal usage, pa=
rticularly in gerbview. One of these is the ability to mirror blocks (maybe=
not much use if you&#39;re getting the pcb manufactured, but I use it for =
home etching). I&#39;ve attached a small patch, if you&#39;re interested. I=
&#39;ve tried to follow existing code style, but please let me know if ther=
e&#39;s anything you&#39;d like done differently.<br>
<br>On a related note, I know this has been asked a few times on the mailin=
g list, but just to double-check my understanding, what is the etiquette wi=
th changes to the program? It seems like there are a few locations for work=
to be done - TODO.txt and the bug and feature tracking pages. Any I&#39;ve=
missed? I think it&#39;s been said before that small changes can just be s=
ubmitted (for people with svn write permissions of course). Is this still a=
ccurate? What&#39;s the suggested procedure for larger changes like most ad=
ditional features? Bouncing the idea and implementation plan off the mailin=
g list first? Adding an entry to the feature tracker and waiting for commen=
t?<br>
<br>Thanks<br>Matt<br>
 --0016e64699522986460468c2e16e----0016e64699522986560468c2e170 Content-Type: application/octet-stream; 
name="20090430_gerbview_mirror_block.patch"
Content-Disposition: attachment; 
filename="20090430_gerbview_mirror_block.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_fu5ak65e0

[Attachment content not displayed.] --0016e64699522986560468c2e170--