← Back to team overview

kicad-developers team mailing list archive

Re: New Pcbnew file format.

 

On 04/13/2012 10:18 AM, Wayne Stambaugh wrote:
> On 4/13/2012 8:39 AM, Dick Hollenbeck wrote:
>> On 04/13/2012 02:04 AM, jean-pierre charras wrote:
>>> Le 12/04/2012 20:53, Wayne Stambaugh a écrit :
>>>> 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.
>>>>
>>>>>>       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.
>>>>
>>>>>>       4) What are the two (at) tags in module_text for? why not only 1
>>>>>>                Is one a position relative to the module and one a position relative to
>>>>>> the board?
>>>> Good question.  It appears that TEXTE_MODULE::m_Pos0 which is relative
>>>> to the anchor position of the module is the only position saved in the
>>>> current format and EDA_TEXT::m_Pos is the absolute position on the board
>>>> which I'm guessing is determined from the position of the module.  I'm
>>>> not sure why it was done this way.  Is there any reason not to dump
>>>> TEXTE_MODULE::m_Pos0 and just use EDA_TEXT::m_Pos?
>>> All items inside a MODULE have a position on board (m_Pos, m_Start ...
>>> and the corresponding parameter relative to the module anchor.
>>> The reason is m_Pos *should always* be calculated from m_Pos0 after a rotation transform,
>>> due to rounding issues.
>>> Only 90 degrees rotations do not have rounding issues.
>>> Therefore, after some rotations (for instance 10 rotations each for 9 degrees),
>>> when using only m_Pos, there is a significant error between one 90 deg rotation
>>> and 10 x 9 deg rotations.
>>>
>>> Because absolute coordinates are calculated from relative coordinates,
>>> only relative coordinates need to be saved on files.
>>> (absolute position and rotation of the MODULE are known)
>>>
>>> I have not a strong opinion about how flipped footprints should store relative coordinates,
>>> but I am thinking the stored values (coordinates, text mirroring, layers and layer masks) could be
>>> stored as non flipped values, i.e. a flipped footprint is "un-flipped", saved and flipped (restored).
>>> Actual values will be restored after reading the file.
>>>
>>> Eeschema stores (in lib) shapes in position 0, orientation/mirroring 0,
>>> and stores the geometric transform for each component.
>>>
>>> This is perhaps not a bad idea to do the same in Pcbnew.
>>>
>>> Some other files format use the same thing,
>>> and this could make file format conversion more easy.
>>
>>
>> We seem to have no extraneous C++ objects.  And this conversation should not diverge into
>> changing C++ objects, but should remain largely focused on file format.
>>
>>
>> However, I will not let go of the importance of this format's effect on our ability to
>> perform clipboard operations later.  From day one going back 4-5 years ago, this has
>> always been a main objective of the s-expression format of mine.
>>
>>
>> Within a BOARD C++ object, there are two kinds of text C++ objects, two kinds of line C++
>> objects, two kinds of arc objects, etc, with one relative to the board and one relative to
>> the module/footprint.  This is status quo.
>>
>>
>> We need:
>>
>>
>> 1) to differentiate these later when pulling them off the clipboard,
>> 2) to create different C++ objects at file load and at clipboard parsing time.
>> 3) to augment them with different trailing s-expression elements.
>>
>>
>> So I suggest:
>>
>> pcb_text, pcb_line, pcb_arc, pcb_circle, pcb_poly
>>
>>
>> fp_text, fp_line, fp_arc, fp_circle, fp_poly
> Sounds reasonable.  I'm assuming fp is short for footprint.  If we drop
> the module prefix from the file format, I think we should internally
> rename all things MODULE to FOOTPRINT for the same symmetry reasoning.
> This gives developers a clearer understanding between the file format
> and the objects they are related to.  If we keep module concept in
> source code and footprint in the file format, that will just add to the
> confusion.  A simple global search and replace can resolve this issue.
> If no one objects, I'll go ahead and rename the board objects when I
> change the s-expression token for these objects.
>
> Wayne


I agree that what we have is a footprint, i.e. class MODULE is better named FOOTPRINT.

However, I think that although renaming the class MODULE to FOOTPRINT might be easy,
renaming all the automatic variables which are spelled "module" and "Module", and keeping
them separated from other comments, is not easy.  Then one asks, how helpful is this if we
have class FOOTPRINT, but variables named "module"?


I would not be in favor of having class FOOTPRINT with variables named "module" and "Module".


Agreed, what we have looks like footprints to me.

At some point in the future, what would a genuine module look like?

A "module" could be a fragment of a BOARD consisting of a number of footprints and tracks.

This is good homework for my grandkids, because that's about the time it would get done, IMO.

Until then, what we have looks like footprints, but I could be blind and not know it.

Do you want to rename both variables and the class name?  If not, then maybe wait until we
have actual modules, and simply comment the class header with this information.


All or none is my suggestion.  The compiler won't care, and you probably won't after the
PCB_IO class is done.

Where it is more important is in the UI, consisting of dialogs and documentation.


Dick






Follow ups

References