kicad-developers team mailing list archive
Mailing list archive
Re: Patch set: Display Origin Transforms rebase
Wayne Stambaugh <stambaughw@xxxxxxxxx>
Sun, 26 May 2019 17:57:20 -0400
addr=stambaughw@xxxxxxxxx; keydata= mQGiBEM0hxQRBAC2fNh3YOVLu1d5GZ0SbrTNldGiGnCJPLqzEnqFX9v6jmf33TMt6EmSLkl6 Wtfkoj0nVwKxcYmJkA8DX0QAokBkwNIzhSsBzQvthBLIk/5LnPVVKrEXOcL4mUyH1doKlkaE slgJozNa6Av+oavcvD02o1zJOloBbaHlNlyRt7fKswCgtIFlVjWggVH/15KfWk+Qo5JVPbME AIUBAQyL2OAx0n60AWec2WHnO9buHuG0ibtICgUMkE+2MRmYyKwYRdyVwGoIUemFuOyHp0AJ InX4T+vy2E7vkwODqjtMLfIoRkokW74Fi4nrvjlhOAw/vdq/twLbAmR9MOfPTpR4y7kQy1O2 /n+RkkRvh26vTzfbQmrH7cBJhk6aA/9Uwvu3E4zNJgHVZeS0HyWtmR1eOPPRbnkPgJTToX5O KMKzTJI/FX6kT7cFoCamitHrW3BJP4Dx+cMMsa47EGxqVTdbVJ4LjogsXTXxb+0Fn1u4zBdx x3Cer6O7+hqWy7zvpzeC6nSREjqDKa5CgHtv/GLm5uFPOmsjAsnHj2tlBrQmV2F5bmUgU3Rh bWJhdWdoIDxzdGFtYmF1Z2h3QGdtYWlsLmNvbT6IeAQTEQIAOBYhBOffs6CbblRzBkv33BtR cWlZ+CReBQJbFBS2AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBtRcWlZ+CReMI8A nRbrLkzp7+c2f0vX7sfg4ICX8LAKAJ9uClo4uJajmZa5zZrL2nKdZlUwIrkCDQRDNIcxEAgA gCru+3/aOC6RCjpvYC72wY+d5SmHphC6yeiV2/mOumyt5MLo/Ps2GznZr11JspqFk5K/Zpvp MMLqqjDZ39+50a2iKRQFJ6NlK+hJWMmj6eJygQrCwYo3Gjc6CqfrqUv+8VSnf/i5sIZmtOVA 4ZjML18MuBvMSsNdVLFJd5HNnYb1iOECpvqdPVh/21LLCEw7MUUGGnHBhCrmk2aJe5hFmcSN g4ldBcXrgMQBwf7aMVoobXBMFDb/IENByXn0llB7Gr2IFMRmNS9/p8s/II1Yl2bTqyX4FSz8 cfn7C9KEz7faZ7wzAcpwHFC/zs3JoAjJ0IEKdNUpIwAlKMzT3CzctwADBQf/cxpG28MKyrqk nNmq/8LQLy+x6FSYXBLjxQz9BiBNYeesDZQ6J5UbL1mjpJzMa5tLZypPYo4bbGyR22hrbyDF K7m6AcVaMIJKl98g4ukMutFfAJyRDaREH5Zl/X1P4u1Z/yaAIy9mKaNbaK1/5djNJ5wCTFen TUgAp9xdc30kGkFDdLJFp5uxDY4P0vaZiZdjUCvDM3Zjv5IzpNOfxVqTUBQNUP/BnnKhkk0p DTD6s3X8S+D0rOtEBQ8K0cwERI/E8EFa8nj0TNw4e2MYGR8wg+SxqJ7z5f0zPY0bO6G9DDFB wYCqzzPWGqdAh9vA5971TAbPERtdFybhkurozp2SfYhJBBgRAgAJBQJDNIcxAhsMAAoJEBtR cWlZ+CResHUAniULLCWiT26ieRTl7N2vS6vBo/DuAJ4m7Ss/gyiW6ybTn1ctDXAUgm2QVQ==
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
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.
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.
> 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.
>> On Sun, May 26, 2019 at 2:08 PM Reece R. Pollack <reece@xxxxxxx>
>>> 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