← Back to team overview

kicad-developers team mailing list archive

Re: Patch set: Display Origin Transforms rebase

 

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 <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
> 
> _______________________________________________
> 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


Follow ups

References