kicad-developers team mailing list archive
Mailing list archive
Re: Net Classes
Dick Hollenbeck <dick@...>
Sun, 19 Jul 2009 10:47:37 -0500
Thunderbird 220.127.116.11 (X11/20090608)
Dick Hollenbeck a écrit :
I am astonished, and disappointed, that you would begin coding "net
classes" without any discussion, considering that I had stated an
intention to code this myself in this posting:
http://tech. groups.yahoo. com/group/ kicad-devel/ message/2936
My problem with your action is the lack of respect for my stated desire
to contribute this design and capability. Although one can argue that
we should operate on a "first to code, first to implement," free for
all, I find the *lack of discussion* about your start astonishing. This
is in view of my effective "reservation" of the contribution.
You apparently don't feel that I have the right to reserve the
implementation or design of this feature. But if that is the case, then
that should have been expressed by you before you began coding it.
So unless you simply missed my posting, I ask you kindly for an
I must say I forgot this mail...
Now, I reread you mail and you clearly said you wand to code net classes.
I believe the first time i read this mail i missed this:
/I want to code net classes. I cannot get to it soon however. I want
them to work well with the specctra export/import. I have a plan to do
this work, but am busy for the next few months.
In fact, last week I download TopoR and tested it.
The results of the autorouter were curious (i am not sure such tracks
are usable in an actual design), but i was pleased by the Design Rules
And i just wrote a dialog to do the same thing.
(There is no code in pcbnew to use the Net Classes)
I was in fact interested by using wxGrid in dialogs (I did not know
wxGrid) and this Design Rule dialog editor that handles some important
design parameters (and not specifically a net classes dialog) seems me
a good sample.
The issue here is not whether we need the capability. We do. And I am
happy to get the capability. But there were any number of things that
you could have started, including UNDO support.
I hoped you forgot this. Alas!
(But the Undo is in my Todo list...)
My lack of discussion often come from difficulties to write long mails
in English, that sometimes take a lot of time.
My actual complaint here is the lack of discussion, and disregard for my
You always must remember English is not my mother tongue.
I know now you *want* to do the job.
And because i have no specific idea and no experience about net
classes, please, feel free to change, modify or remove code relative
to these net classes
Well how about we split this into two parts consisting of *my* part:
(1) data structures
(2) member functions to access the data structures
(3) persistence: loading and saving to disk
(4) specctra import/export enhancements
(5) switching the existing (soon to be insufficient) DRC code (track
routing) to use the new member functions
And *your* part:
(A) user interface to create, modify, delete net classes.
(B) user interface to add a net to a class, remove a net from a class.
(C) DRC or routing enhancements which will take into consideration the
net classes of both objects in a near collision, and chose the most
restrictive distance of the two when coordinating the allowed spacings.
I see these task dependencies, where "<-" means "depends on" the task(s)
to its right
It would be my preference to try and stay with a net class object which
is similar to the one given in the specctra dsn format, in terms of
conceptual attributes or fields.
Additional fields beyond what are used by an external router such as
freerouter, are likely to cause problems of compatibility during the
There is much to be admired about the specctra format, and much to be
learned from it.
My design ideas:
The interface to (or access to) net classes should be through the net
itself. Calling code such as DRC should *ask the net* what class it is
in, i.e. how it wants to be treated.
Also, fields in a net class object should be either "specified" or
"unspecified". When "unspecified", they should be "inherited" from a
(board global) default net class. So if a user modifies the "default"
net class, he may be modifying all the like named fields in all the net
classes which are not "specified" or over-ridden.
To keep the calling code clean, the stacking of net classes (inheritance
of default values) needs to be encapsulated in the design of the member
functions. The member functions know how to do this, calling code
should not have to worry about it. We can use a value of say -1 to
indicate "inherit from the default net class". Or if the rule is its
own child data structure, its absence or NULL-ness serves the same
purpose. And again, the main access to a net class should be through a
net. It may be relatively easy to extend the inheritance beyond the one
level of stacking that I have described here: derived <- default. If
we do this, then your user interface must show a tree, not a list of net
All existing DRC rule globals values should be deleted from the source
code and moved into the default net class. The default net class should
be created automatically without user interaction for any board. All
net classes should always reside in the board file, not in any global
I can code my part within the next month, say completing it by mid August.
If you can wait, and agree with this plan, in the mean time there is the
"layer visibility" design thread that we invested time into, and UNDO
for you to consider working on.
Please let me know your thoughts on this division of responsibility and
the scheduling. My commitment to code my part in 4 weeks is contingent
on your agreement, and is also a reflection of how busy I am. I don't
see more than 3 days work for me, and this is about 3 Saturdays, hence
the 4 weeks.