kicad-developers team mailing list archive
Mailing list archive
Re: About Zones
Dick Hollenbeck <dick@...>
Mon, 05 Nov 2007 11:31:54 -0600
Thunderbird 18.104.22.168pre (X11/20071023)
Dick Hollenbeck a écrit :
As part of the zone re-design, we should also "abstract out" the track
to track "electrical continuity testing". For the time being this can
be as simply as putting the existing end point match testing, which is
done with == tests, into member functions. And for the time being
those member functions can still use end point == testing, but can later
be enhanced to test for any kind of physical overlap / electrical
bool TRACK::ConnectsTo( const TRACK& track ) const
bool TRACK::ConnectsTo( const ZONE& zone ) const
bool TRACK::ConectsTo( const SEGVIA& via ) const
bool TRACK::ConnectsTo( const D_PAD& pad ) const
bool SEGVIA::ConnectsTo( const ZONE& zone ) const
// bi-directional should be equivalently valid:
bool ZONE::ContectsTo( const SEGVIA& via ) const
bool ZONE::ConectsTo( const TRACK& track ) const
With these black box functions, you could conceptualize a top-down
design and defer implementation of all of these until you know exactly
what is needed above, and worth investing in time-wise.
The top-down design is largely done by identifying member function
stubs, identifying their arguments and return values.
The UI editing of zone perimeters and ratsnest functions are the bulk of
the work up near the top of the design.
jean-pierre charras - INPG wrote:
I'm sure its too early, but I am hoping not to forget the idea, so
consider what follows the first of a brainstorm:
Maybe we should get rid of TRACK::start and TRACK::end pointers and
replace them both with a single
The connectivity algos (a part of ratsnest functions) are very sensible
to the end point testing only,
because in this case, for a given segment, handle 2 (one per end) other
connected items (a pad,via or an other segment end) is sufficient.
And when searching a connected item (when building the connectivity),
the search is made for only unconnected ends, and is stopped when the
first connected item is found.
(So, for a given segment, the search is not exhausive, but all the
connections are found because something like a connectivity chain is built)
(search is made first with pads and after with tracks).
The connectivity algorithms must be redesigned if we change this (only 2
ends are tested), so they are very near the top of the design.
Problems can be in algos, in connect.cpp, so i must finish the
translation of some french comments, and add more comments, to explain
Then any two connected BOARD_ITEMs would always have entries in their
vectors, pointing to back to each other.
Say A and B are connected. Then A.m_ConnectsTo contains and entry for
B. And B.m_ConnectTo contains an entry for A. If you move B, you can
see that A's vector might become obsolete if you move B too far. (And
possibly other BOARD_ITEMS too.) But you know that A must be updated
because it is in B.m_ConnectTo for now.
If you move an item, you know who's other m_ConnectsTo fields are
subject to change as well.