kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/14/2010 7:28 AM, Lorenzo wrote:
> Dear developers,
>         I'm an electronic developer and I found in the Kicad project an
> extremely interesting EDA suite. Even it is obvious that (in this
> moment) it cannot compete in productivity with most important EDA
> systems (e.g. Altium, OrCAD, PADS...), it is growing fast and it has the
> power to be used in production environments proportionally to its
> growth. It is probably the only industrial EDA application that is
> multi-platform, open source, and released in a stable version.
> 
> It's about two years I'm trying to give my small contribute to this
> project; we had a discussion about additional features some time ago,
> and I was probably too enthusiast to identify and imagine a proper
> implementation work flow for my ideas. The first time I saw the code I
> was discouraged not only by the lack of comments and the French language
> used to write the application, but also by the dirty folder structure,
> file names, and function positions. This is pretty changed now, and the
> code looks generally better.
> 
> I've tried to use Kicad in some of my projects. However I found tricky a
> set of functionalities that needs to be improved. I see that the
> community is working hard to correct and improve functions. But now I'm
> trying to implement features that I found important for my job. This is
> a quite difficult task, since the code is huge and it is the first time
> I hope to be useful in a collaborative open source project (but I write
> C++ code nearly everyday). I understand that code improvement (such as
> structure clarification, doxification of comments and bug fixing) is
> more important than adding new features now; however the new features
> are needed to make the jump from a wonderful hobbist EDA suite to a
> good, stable and productive capturing and PCB design software. I hope
> that the bug fixing can be parallel to the feature addition.
> 
> The feature set I wish to implement is related to the way items are
> selected in eeschema. This is now starting to get shape in my code, but
> it is a complex task and needs to be discussed.
> I'm preparing an introductory document to describe my implementation;
> however basic functionalities are described below.
> Before going on, I want to hear from you what you think about (I hope
> I'm not wasting my time in features that are not needed at the moment
> and/or that someone is building up better than me...). If you think it
> is useful, it's a good idea to identify how this functions can be
> inserted in the new code (conditional compilation inside the current
> development version or new code branch; wait until the functions are
> completed or step-by-step implementation...).
> 
> This is no more than a proposal: it should be stated that I am ready to
> discuss on every single sentence I wrote (and I will write) and every
> coding choice.
> 
> ALREADY IMPLEMENTED (to be tested):
> point and click selection: lines become highlighted (inverted color) and
> ends are drawn as squares; other objects are drawn inverted
> one click unselection: responding to command “ESC”, click on free area
> and click over selected object. No redraw seems to be necessary (clean
> toggle with color inversion)
> CTRL+click, multiple object selection and unselection
> dragged square selection. The selected elements are the ones returned by
> PickItemsInBlock() function.
> CTRL+dragged square selection, adds to the selected elements list the
> picked elements
> Answer to the CANC keyboard command
> 
> YET TO BE IMPLEMENTED:
> answer to every control key
> OnRightClick for each picked item type (element or list of elements),
> operations on the list of selected elemets
> PickItemsInBlock() behavoir discussion, if not already modified
> Drag selected items
> Discussion on the way nets are dragged
> Drag net ends and nodes
> 
> As you see, the job I've done is less than 1/10 of the whole, but it is
> still something (As you'll see, there is not so much coding effort in my
> implementation, less than 1k lines including headers and comments...).
> If this is the right way, I'll continue hearing from your advices. You
> can see a sample of the actual result at this link:
> http://www.glowfoto.com/static_image/14-060522L/9240/png/09/2010/img4/glowfoto
> 
> This feature set should solve and build basis for a set of bug fixing
> and wish implementation, such as the following:
> #593997  Selection improvement (and 3 connected wishes)
> #594073 Highlight Nets
> 
> Hope to “hear” from you what you think about that.

Lorenzo,

First let me start by saying thank you for your interest in helping out with
Kicad development.  I also want to commend you for the way you introduced
yourself and made your intentions known to the other Kicad developers on this
list.  This step alone will put you in good standing with the primary
developers who have the authority to commit your patches and maybe some time in
the future consider giving you commit access to the launchpad repos.  It is
obvious that you have thought this through and considered other developers
investment in the project.  Maybe we should add a link to this message to the
getting started FAQ as an example of the appropriate way to introduce yourself
on the developers list.

Submitting a small patch that resolve a problem or part of a problem is
definitely the way to go.  I doubt anyone on the list has the time or the
desire to evaluate a 10,000 line patch.  It gives others a chance to patch
their local branches and see how your changes work.  They can comment and give
suggestions to improve you patch or commit it as is should it be deemed
acceptable.  Then you can code your next change and repeat this cycle.  This is
in fact how I work even though I can directly commit code.  I typically
implement the low level infrastructure code first like modifying existing
classes and functions even if the code isn't used until later when the actual
feature is implemented.  Done in small logical steps will allow other
developers to quickly figure where you are heading with your changes.  The only
time I commit large changes is when I'm implementing a new feature doesn't
require any changes to the underlying code and it resides in a new source file.

Before you submit your patch, make sure your check out the "How do I submit a
[PATCH} FAQ on the Kicad project page at launchpad and the proposed "Coding
Style Guide" that Dick just sent out to the developer list.

Wayne

> 
> L. Farina