kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/12/2012 01:53 PM, Wayne Stambaugh wrote:
> On 4/12/2012 9:05 AM, Dick Hollenbeck wrote:
>> On 04/11/2012 06:41 PM, Dan Chianucci wrote:
>>> This new format looks great, I have a few comments/questions
>>>
>>>      1) in some spots like module pads there is (net <nutNum> <netName>) and in other
>>> spots like track segments it only has (net <netNum>).
>>>      2)What do the edge tags represent in the Module
>> Exactly.  It might not be the first English tag that comes to mind for this. eh?  I'm not
>> even sure these are limited to "edges".
> This is one of those areas where I am relying on the knowledge of
> someone who know about the BOARD_ITEM internals that I do.  If there is
> a more descriptive name or way to present this information, I am
> certainly open to suggestion.

class EDGE_MODULE is derived from DRAWSEGMENT and comes in types
S_SEGMENT, S_CIRCLE, S_ARC, S_POLYGON.

So it is basically a graphical line, circle, arc, or polygon.

Basically a "graphic", so that word is one candidate.  It is not confined to the module's
edge, but is often used to delineate the bounds of the footprint.

However you would use one of these to designate PIN 1 on the footprint.

It is nearly the same discussion we had about (draw line  ....) before.

You could go with "gr_line" for S_SEGMENT, "gr_circle" for S_CIRCLE, etc.


The discussion about why not (text..) for both BOARD and MODULE is almost the same
discussion about (draw...)  [now edge] for BOARD and MODULE.

There is an argument to try and unify them.

There is also an argument to keep in mind some solution for the case where you pull this
text off the clipboard, and now you have to know whether it is for a BOARD or MODULE, and
one way to do this is to have unique keywords, but not the only way.

Off the top of my head I do not know what class EDGE_MODULE does differently than DRAWSEGMENT.



>>>      3)Draw arc has tags start and end.  I'm not sure if this has changed, but the file
>>> format before this held onto the center of the arc, and an endpoint of the arc...
>>>         The file format definitions also say it holds onto the starting point and the
>>> ending point, which caused a lot of headaches when I wrote my file format converter
> I've saved the object information as defined in the current file format
> document as closely as possible.  If arcs are defined this way in
> current file format, then they will be defined that way in the new file
> format.  Otherwise, some transformation will have to be made when
> reading the file.

If it can be or is readily computed, then perhaps we don't need to save it?

Jean-Pierre?  (I am too busy to check code right now.)