On 04/20/2012 05:57 AM, jean-pierre charras wrote: > Le 20/04/2012 10:24, Dick Hollenbeck a écrit : >>> With this patch, DRC recognizes that the vias are connected, and doesn't >>> complain at all >>> about them. >> >> Dan& Tom, >> >> Please re-test the revised patch, which has a better chance of being >> committed if it still >> works. >> >> And Dan, if you are interested in learning about what was changed, you might >> apply this to >> a pristine testing checkout, then compare that branch to the other one you >> have now. >> >> >> Thanks, >> >> Dick > About this patch, if it fixes an issue, it creates some important others. > This is not only a matter of coding, this is the approach that creates issues: > > 1 - Keep netcode when a track is not connected to a pad (or a track connected > to a pad) > can create not connected copper areas (floating copper zones). > This is the main drawback. > Note this could be fixed by a better code, but this is not fixed by the patch. > The initial patch had this issue, and this is the main reason I did not > accept it. > ( Pcbnew removes all floating copper areas, and to do that, checks for each > copper area if > there is at least one track end inside the area, assuming all tracks are > connected to something ) > 2 - tracks that are *really* not connected keep also a netcode. I am pretty > sure this is bad. > 3 - If a zone has its net changed, the net of stitching vias are not updated. > this is also an issue, because a board is usually modified and edited > during its life time. > > An alternate way could be: > when a track/via is created starting to a zone, it is linked to the > corresponding zone (the time stamp could be a good link) > If the full track is connected to a pad/track it is no linked to the zone. > Therefore, when a zone is deleted, moved... the linked tracks can be also > updated, and keep their net. > And these tracks could be ignored by test functions which test floating > copper areas. > > > However because it is so easy to connect stitching tracks/vias to a pad, > I am not volunteer to write this code, just to spare 1 second of working time > of some users..
Jean-Pierre, Thanks for looking at the patch. I did not commit it because I was not 100% sure it was conceptually solid, nor did I have enough time to delve deeper. But to be honest, normally I cannot even read C++ code that does not conform to our coding standards, since it sends my head into a fourth dimension. So that was simply a starting point, to make it readable. It is apparent that your time is valuable Jean-Pierre, and we appreciate you taking the time to look at it. Dan, is there a bug report for this, flagged as wishlist? I will add it to the bottom of my todo list. Being at the bottom could be temporary, because if I get bit by this, then it would elevate in a hurry. In the mean time, you can also contemplate a better solution, this time hopefully one that meets with the coding standards. I promise not to look at the next patch if it does not. I promise to fix this myself if it ever bothers me enough. This is where it stands from my perspective. At least we got a look at it from Jean-Pierre, who in shortest period of time was able to assess pitfalls. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
