kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

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 <reece@xxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp