kicad-developers team mailing list archive

[Dan Chianucci <trump211dev@xxxxxxxxx>]

> 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.

calling it "gr_line" etc. seems more intuitive to me.  I was confused
and thought that there was board edges (the board outline)  inside of
modules for some reason.
Or that the modules held on to a bounding box called edges.

> 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 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.

My two cents would be to unify the objects inside of the stored file.
This way everything can be read the same way.  For instance there
would only need to be a single "readText" function which would get
various information about the text, line, or whatever it is that is
being loaded.  The same argument holds for writing it to disk, and
even to the function which actually draws it on screen.

Additionally, having the objects be saved differently depending on
where they are encourages having the different limitation on the
object internally to the program.  For example, right now depending on
where text  is on the board, the user has different amounts of control
over it.  For instance in a Module, text is centered over the center,
and can only be rotated at 0 or 90 degrees.  On the Board itself
however it can be justified to the left, right or center, and it can
be rotated in 90 degree increments.  If it was unified internally it
would make it a lot easier to add functionality to each type of bboard
object.

>
> >>>      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.)

I didn't word what I was trying to say correctly.  If you look closely
at the current file format you will find that even though the file
format definitions says that it holds on to the endpoints of the arc,
and the center is computed internally, in actuality it doe the
opposite.  What is actually saved is the center of the arc and an
endpoint of the arc.  Prove it by drawing an arc in the board, record
the points where the endpoints and the center are located, then save
it and look at the file  startX startY is actually centerX and
centerY.

To Cirilo:
I agree with what you are saying, about being difficult to associate
individual pieces to a single module if they were all saved the same
way.  However the module "text" will still be inside of a module 'tag
block'.  I would say that the parts that make up a module should be
saved as if the module were centered at (0,0) with a rotation of 0.
Then the module itself would hold onto where it is on the board, and
at what rotation. Internally, it would be trivial to calculate the
actual positions of the each module's pieces.