kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/11/2012 10:23 AM, Wayne Stambaugh wrote:
> On 4/11/2012 11:00 AM, jean-pierre charras wrote:
>> Le 11/04/2012 16:19, Wayne Stambaugh a écrit :
>>> On 4/11/2012 6:47 AM, jean-pierre charras wrote:
>>>> Le 10/04/2012 18:31, Dick Hollenbeck a écrit :
>>>>> I updated this to support the PCBNEW nanometers.
>>>>>
>>>>> Might have broken something on the non-nanometer build, did not test
>>>>> that.
>>>>>
>>>>>
>>>>>
>>>>> Also, Jean-Pierre,
>>>>>
>>>>> I think there is still some incompatibility in the zone hatches.
>>>>> There may be too many of
>>>>> them being constructed.
>>>>>
>>>>> Might want to instrument the perimeter crosshatch line building code
>>>>> with some printf()s
>>>>> and see how many are being built in both compile modes.
>>>>>
>>>>> There is a lot of CPU cycles being burned in crosshatch line drawing
>>>>> from what I can tell.
>>>> I fixed this.
>>>> I also moved in convert_to_biu.h the function DMils2iu( int dmils ),
>>>> and added a new function Mils2iu( int mils ),
>>>> because we have *a lot* of constant values (in decimil and sometimes
>>>> mils)
>>>>   in constructors and dialogs we need to convert to new units.
>>>> I am thinking all these values should be converted using one of these
>>>> functions, and never assigned
>>>> using something like:
>>>> #if defined( USE_PCBNEW_NANOMETRES )
>>>>      ...
>>>> #else
>>>>      ...
>>>> #endif
>>>>
>>>> So if we have issues with nanometers, it will be more easy later to
>>>> modify pcbnew.
>>>>
>>>> Also these functions could be useful in Cvpcb and Gerbview (in export to
>>>> pcbnew functions)
>>>>
>>>>
>>> JP,
>>>
>>> Please let me know if you are planning to add any more internal unit
>>> conversion macros or functions to convert_to_iu.h.  I had already
>>> created a base_units.h/cpp in my development tree with almost the exact
>>> same conversion macro.  I want to prevent duplication as much as
>>> possible.  For now, go ahead and keep convert_to_iu.h.  We can reconcile
>>> the duplicate conversion code at a later date.  Also, you may want to
>>> change Mils2iu to use wxRound() so it will work for negative values.  I
>>> am also thinking that should use internal units for everything as much
>>> as possible.  This would eliminate the need to constantly scale things
>>> such as grid sizes, sheet references, and title blocks.  That way, all
>>> scaling and offsetting is done in the base units which should simplify
>>> things significantly.  I'm not sure when I will finish killing off
>>> m_internalUnits.  It is proving more difficult that I had anticipated.
>>>
>>> Wayne
>> Currently, Mils2iu() and DMils2iu() are enough to replace hard coded
>> constants
>> in dialogs and constructors (mainly DMils2iu(), previously existing in
>> pcbnew.h),
>> when needed.
>> More functions are needed to handle grid and zoom lists,
>> but I am thinking you are working on.
>>
>> Perhaps you should commit your base_units.h/cpp files, to avoid
>> duplicate work.
>>
>> Thanks.
>>
> JP,
>
> I will as soon as I get the old internal unit stuff removed and have it
> reasonably bug free.  It will be a much larger change than I typically
> like to commit but the it was the only way I could get rid of the
> internal units in one shot.  It was amazing how many places in the code
> that internal units conversions were made.  It has been a arduous process.
>
> Wayne


Having some temporary duplication in functions is pretty easy to fix later, especially
since they are such simple functions.  JEdit is one tool up to the task.

The larger the set of changes, the more nervous one gets about straying off the farm, or
having the farm move out from underneath you.  That is understood.  But your work is
certainly important and if I can help in any way let me know.

I am good with JEdit.

Our objective is to de-couple EESCHEMA from PCBNEW to the extent possible.  The "units" in
EESCHEMA will ultimately be "one standard pin spacing".  So trying to reconcile this with
common code was going to be harder than breaking the bond.


I was planning on a separate "GRID" class, a break out from BASE_SCREEN, some of which
could be stored in a BOARD, at least the retentative grid origin work that was contributed.

That was on my todo list, but anything you are doing to shorten my todo list just gives me
the freedom to get back to my next item on my list, in TODO.txt

Later this week will look at the abstraction opportunities for footprint libraries within
the context of PLUGIN.

Dick