kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #02460
Re: Joining the dev group
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
Dick Hollenbeck <dick@...>
-
Date:
Fri, 01 May 2009 06:38:27 -0500
-
In-reply-to:
<2f3ef42d0904300308i41b3ecd5i47ddf1db9a95a278@...>
-
Scanners:
none
-
User-agent:
Thunderbird 2.0.0.21 (X11/20090318)
Matt Wright wrote:
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.
Matt,
Thanks for the patch. It looks pretty good. I have two suggestions:
1) change your two while loops to for loops:
for( TRACK* track = m_Pcb->m_Track; track; track = track->Next() )
This way we can see the track = track->Next() which is part of the
iteration. If the iterated block was smaller this would not be as big
of a concern.
2) Put in a Doxygen compatible comment in the header file. The Doxygen
config file is setup for header file precidence so we want nice comments
in the header. I usually don't put any comment in the *.cpp file, as it
means duplicate maintenance.
See function INSPECTOR::Inspect() in base_struct.h as a good example.
Then run Doxygen on your project and look at the HTML results of your
comment and others. You can use the <p> to put in a paragraph into the
output.
If you resubmit the patch I will commit it.
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?
Yes.
What's the suggested procedure for larger changes like most additional
features? Bouncing the idea and implementation plan off the mailing
list first?
Since you are a beginner it would be appreciated if you can post the
patches any larger than say 10 lines to this list for awhile.
Adding an entry to the feature tracker and waiting for comment?
Well if you don't plan on coding it yourself, putting it on the tracker
will keep it from getting lost. Things on this list get lost, and in
fact anybody that is not subscribed to this list will never even see any
attachments to it. Those that subscribe can get the whole attachment as
I recall.
Dick
Thanks
Matt
Follow ups
References