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 wrote:
>
> On 7/9/20 7:09 PM, Tomasz Wlostowski wrote:
>>
Jon,
The alternate origins themselves (Place & Drill / Aux origin, and Grid
origin) in Pcbnew are stored in the BOARD_DESIGN_SETTINGS class and
saved in the board file. Of course, the Page origin location doesn't
need to be stored; it's always (0,0).
My initial thought last year was to
It would be preferable to make it possible to call GetSelectMenuText
(or really, any facility that needs access to the current units and
coordinate transform) without a frame.
We have recently been putting a lot of effort into separating the
logic code from the UI / frame code in KiCad, and it
Even if it's just a view transform, should moving the file to a
different computer result in the view transform changing?
On Fri, Jul 10, 2020 at 1:59 PM Jeff Young wrote:
>
> I think that depends on whether the data is stored independently or not. For
> instance, our internal values are
OK, I see.
I have mostly stayed out of this conversation before so I will
probably step back, but I would suggest that I think that display
units and origin choice should be a project-level setting, not
system-level.
Probably it makes sense to change GetSelectMenuText so that it has
this context
I agree on both points: units and transform should be saved in the project
file, and they should be passed to GetSelectMenuText as parameters.
Cheers,
Jeff.
> On 10 Jul 2020, at 19:35, Jon Evans wrote:
>
> OK, I see.
>
> I have mostly stayed out of this conversation before so I will
>
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
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
The units selection and the origin transforms are both available through
the EDA_DRAW_FRAME. I haven't looked at every call in detail (there are
a combined 118 calls and function declarations), but it appears that
when the caller has access to an EDA_DRAW_FRAME then the call is some
variant
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
The way I see it, there is one package of information that we should
be delivering: how to turn internal units into real text for display.
That information includes both a units selection and whatever
transform to apply in case there are coordinates involved.
I see no benefit into splitting that
Callers of the form:
GetSelectMenuText( EDA_UNITS::MILLIMETRES );
are most likely test cases.
Dialogs also know what the user units are, so you can get it from there too if
you don’t have a frame.
But yes, I spent a lot of time divorcing GetSelectMenuText() from global
variables and
Could we do as Jon suggests and bundle the full affine transformation as
a class that we pass to GetSelectMenuText() instead of the current
EDA_UNITS? This class could be stored in EDA_DRAW_FRAME for now,
replacing the m_userUnits. Once we get around to separating the units
from the frame,
Presumably the combination of units+transform is also needed for
things like plotting, no? (where the chosen set of units and transform
may be different from those used for display)
On Fri, Jul 10, 2020 at 4:56 PM Ian McInerney wrote:
>
> I view the package of information need as the arguments
Doesn't the origin transform operate on the IU and not use the units
directly (so the units are only needed by the actual menu text generation
function)? If they are separate, then we should pass them as two
individual arguments to the GetSelectMenuText function.
-Ian
On Fri, Jul 10, 2020 at
I view the package of information need as the arguments to the function. If
information isn't needed, then it shouldn't be passed in. Creating a new
wrapper type that just holds the EDA_UNITS and the ORIGIN_TRANSFORMS object
seems like an extra level of abstraction that is not needed. The point of
16 matches
Mail list logo
