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?
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
