| Thread Previous • Date Previous • Date Next • Thread Next |
jean-pierre.charras@... wrote:
Dick Hollenbeck a écrit :Jean-Pierre, 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 <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 explanation. .....I must say I forgot this mail... I apologize. 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. / I apologize! 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 dialog editor.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 reservation. Thanks, DickYou 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
(2)<-(1) (3)<-(2) (4)<-(2) (A)<-(3) (B)<-(3) (C)<-(4)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 round trip. 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 classes.
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 configuration file.
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.
Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
