kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Shouldn't the origin be stored in the design data (BOARD / SCHEMATIC)
rather than the base frame?

It seems like all data about objects, including their coordinates in
the coordinate space defined by the user, should be available just by
parsing a board or schematic file (which should be independent of the
EDA_BASE_FRAME)

-Jon

On Fri, Jul 10, 2020 at 1:18 PM Reece R. Pollack <reece@xxxxxxx> wrote:
>
> Jeff,
>
> Thanks for the follow-up.
>
> I'm finding some of the GetSelectMenuText() implementations format
> coordinate addresses for display. That means they need to use display
> origin transforms so the displayed coordinate matches what the user sees
> on the status line and elsewhere. However, there does not appear to be a
> path from these functions to the EDA_BASE_FRAME class where these
> transforms are currently available.
>
> Might someone more familiar with the data structures and calling
> sequences could suggest how this can best be accomplished?
>
> Seth, I'd appreciate it if you could bring your knowledge and expertise
> to bear.
>
> -Reece
>
> On 7/10/20 6:35 AM, Jeff Young wrote:
> > No, the DRC re-write won’t affect GetSelectMenuText().  It originated for describing items in the Clarify Selection menu, but it’s now used whenever we want to describe an item to the user.
> >
> >> On 10 Jul 2020, at 00:51, Reece R. Pollack <reece@xxxxxxx> wrote:
> >>
> >> On 7/9/20 7:09 PM, Tomasz Wlostowski wrote:
> >>> On 10/07/2020 00:58, Reece R. Pollack wrote:
> >>>> I'm looking at display origin transformations for DRC reports.
> >>>>
> >>>> With the 5.1.x branch Pcbnew, the DRC report dialog box message texts
> >>>> contained the Cartesian coordinates of each flagged item. It appears
> >>>> that the 5.99 branch no longer displays the coordinates of DRC items.
> >>>> However, the Cartesian coordinates are still listed in the report file.
> >>>> Unlike the display in a dialog box, this report is persistent and could
> >>>> be passed to someone using different display origin settings.
> >>>>
> >>>>   1. Should these coordinates be reported relative to the page origin, or
> >>>>      transformed per the user-selected origin and axis directions?
> >>>>   2. If the coordinates are transformed, should the report include the
> >>>>      user settings?
> >>>>
> >>>> -Reece
> >>>>
> >>> Reece,
> >>>
> >>> I wouldn't introduce any changes to the current DRC code, we're
> >>> designing a new DRC engine for KiCad V6 and many things in DRC interface
> >>> will likely change.
> >>>
> >>> IMHO the DRC coordinate transform belongs to the UI, not the DRC itself:
> >>> - the DRC engine generates an internal report with coordinates in board
> >>> coordinate space
> >>> - whatever displays the report to the user (i.e. the DRC dialog)
> >>> converts the board coordinates to UI coordinates.
> >>>
> >>> - my 5 cents
> >>> Tom
> >>>
> >>>
> >> Tom,
> >>
> >> I'm not hard to convince, especially when it means doing less work.
> >>
> >> This sounds like the RC_ITEM::ShowCoord function will be removed or replaced. It's one of the two troublesome function groups.
> >>
> >> The other troublesome function group is the GetSelectMenuText function. Last year I knew what they did but I've forgotten in the interim. Will this DRC rewrite replace these?
> >>
> >> -Reece
> >>
> >> _______________________________________________
> >> 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