kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

I think that depends on whether the data is stored independently or not.  For instance, our internal values are independent of units, and the display units are only shown in the EDA_BASE_FRAME.

If the origin is similar (ie: it’s a view transform), then it should be passed as a parameter to GetSelectMenuText().

However, if the origin affects how to interpret the data in the file, then it should be in the BOARD/SCHEMATIC like Jon said (which is easy to access from the BOARD_ITEM or SCH_ITEM).

Cheers,
Jeff.


> On 10 Jul 2020, at 18:25, Jon Evans <jon@xxxxxxxxxxxxx> wrote:
> 
> 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