← Back to team overview

kicad-developers team mailing list archive

Re: Display origin transforms for DRC reports?

 

It sounds like the consensus approach is to add a second parameter to the GetSelectMenuText() function, which will be a pointer or reference to an ORIGIN_TRANSFORMS object. Those implementations of this function that format coordinates will use this to display the coordinates relative to the user-selected origin.

I propose that if it is desired to move the user origin and in/mm selection from the user display options to the project be deferred to a separate patch set so this can be discussed independently.

Does this sound right to everyone?

-Reece

On 7/10/20 4:56 PM, Ian McInerney wrote:
I view the package of information need as the arguments to the function. If information isn't needed, then it shouldn't be passed in. Creating a new wrapper type that just holds the EDA_UNITS and the ORIGIN_TRANSFORMS object seems like an extra level of abstraction that is not needed. The point of my original question about the IU is that if the transform operates on the IU, then these two items are probably not needed together anywhere else. Adding a struct solely to hold these two datatypes will add code/understanding overhead to the functions and its callsite, specifically: * Having to create the actual struct and populate it's fields before calling the function * In the function the struct has to be unpacked/continually referenced (so the variable names become longer) * It hides the fact that we are passing these two items (one of which is already an opaque type) inside another opaque type when someone just views the prototype for the function

To me, it seems like there is not enough here to justify the creation of a new layer of abstraction to pass these two items into this function. If these two datatypes are needed in other places at the same time, then I could see the justification.

-Ian




References