kicad-developers team mailing list archive

[Greg Smith <ecomputerd@xxxxxxxxx>]

A few things I've been thinking about recently and wondering what reasonbehind some of these characteristics:
I've been working with pcbnew Python for a few months now, and havewondered about the consistency in getting the object collectionson module and board as well as proper final orientation for the various objects, text and pads.
Is there any desire to make objects more consistentin this regard?
Here is the current state of affairs:
board.GetDrawings()module.GraphicalItems()
Is there a reason these are differently named collections?It seems they can hold substantially the same types of objects.
TEXTE_MODULE - text that exists on a module.GraphicalItems() and               returned by module.GetValue() and module.GetReference()
TEXTE_PCB - top level text that exists in board.GetDrawings()
It would be nice to have a GetFinalOrientation() on all objectsthat returns the orientation after it's parent orientation, if any,is taken into account.
GetBoundingBox() on any object can be relied on to get theorthogonal box that surrounds the object regardless of finalrotation. However, to get the close-fitting rectangle thatsurrounds an object in the proper orientation takes a differentapproach based on the object:
TEXTE_PCB - GetTextBox() with            angle GetTextAngleDegrees() rotated around GetCenter()
TEXTE_MODULE - GetTextBox() with angle rotated around GetCenter()               of degrees GetTextAngleDegrees() +                GetParent().GetOrientationDegrees()
PADS - Corners defined by GetSize() and GetCenter()       rotated around GetCenter() with angle GetOrientationDegrees() 
Note the following inconsistencies:
    TEXTE_PCB and TEXTE_MODULE of needing to get the Parent    of a TEXTE_MODULE to get the "final" orientation.
    TEXTE_MODULE and PADS, again of needing to get the Parent    of a TEXTE_MODULE while PADS (also a child of a module) of    GetOrientationDegrees() returns the final orientation without    needing the Parent's orientation.
    Also note the lack of getting a "close-fitting" rectangle from    PAD is done atomically with GetSize() and GetCenter() rather than    a convenience function equivalent to GetTextBox(). It would be    nice if there were the same function call (name) for Pads and Text    for a close-fitting rectangle.
A possible solution for resolving TEXTE_PCB and TEXTE_MODULE is torefactor most if not all functions into EDA_TEXT. A TEXTE_PCB parent,perhaps, is the BOARD object. And maybe that could have a functionGetOrientation() that always returns 0. Alternatively, aGetFinalOrientation() function could exist and overridden on theTEXTE_MODULE to include a call to GetParent().GetOrientation().It seems better if both TEXTE_PCB and TEXTE_MODULE could be refactoredaway and leave EDA_TEXT as the sole implementation, if possible.
I'm sure other refactorings could resolve the inconsistency as well.
It would be nice if there were consistency between the shapes availableas PADS could be the same (or closer) to the shapes available ina DRAWSEGMENT. Even better might be the ability to optionally FILLshapes in DRAWSEGMENT. Then it could be used for all the shapeswithin a PAD as well.
Thoughts?