Seth, I'm fine with this approach. I like your idea of deriving a new UNIT_BINDER object so that it doesn't impact the other frames that do not use ORIGIN_TRANSFORMS.
Cheers, Wayne On 5/26/19 4:15 PM, Seth Hillbrand wrote: > Hi All- > > If Reece can separate this so that it doesn't affect eeschema, cvpcb, > pagelayout_editor, gerbview or libedit, I'm fine with merging as is and > refactoring more later. If we merge this as is, it become much more > difficult to fix it later. > > Since these are all GetMsgPanelInfo() calls, the fix is simply to > overload the base instance and then any call that doesn't use > ORIGIN_TRANSFORMS should not pass it as a parameter. > > Once this change is implemented, the rebasing should not be nearly so > painful, so the extra holds on commits should not be required. > > -Seth > > The fix for this is simply overloading > > On 2019-05-26 15:54, Jon Evans wrote: >> Hi Reece, Wayne, Seth, >> >> Can you clarify the path forward here? Are we going to merge the >> second patchset and then do follow-ons to take care of the issues Seth >> raised, or will there be another full patchset coming? >> I have a backlog of things to cherry-pick from 5.1 to master that I've >> been holding on to until this is resolved. >> >> Thanks, >> >> -Jon >> >> On Sun, May 26, 2019 at 2:08 PM Reece R. Pollack <re...@his.com> >> wrote: >> >>> So now it occurs to me that what I should have done was create >>> classes derived from UNIT_BINDER that handle the different types of >>> data (X-abs, Y-abs, X-rel, Y-rel) and instantiated those, rather >>> than adding a parameter to the UNIT_BINDER class. >>> >>> However, that would have also required changing UNIT_BINDER to >>> accept and return _double_ values rather than _int_ to avoid the >>> _int_ -> _double_ -> _int_ -> _double_ conversion sequence >>> formatting for display, and _double_ -> _int_ -> _double_ -> _int_ >>> conversions parsing from display. >>> >>> Maybe I'll do that another time. Too many changes too late for this >>> iteration, I think. >>> >>> On 5/26/19 11:01 AM, Reece Pollack wrote: >>> >>>> The specific problem with UNIT_BINDER is that it doesn't know what >>>> sort of data it's handling. It could be a value like a track width >>>> which shouldn't be altered, a relative coordinate delta which may >>>> need a sign flip, or an absolute coordinate which needs both >>>> translation and sign flip. Nor does it know whether relative or >>>> absolute coordinate is an X or a Y axis. Thus it must either have >>>> a parameter identifying the type of data it's handling or a >>>> different set of methods to transfer that data in or out based on >>>> the type. I chose a constructor parameter, and I chose to pass an >>>> object implemented to handle that type of data. >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp