kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/9/2012 1:10 AM, Dick Hollenbeck wrote:
> On 03/27/2012 12:55 PM, Dick Hollenbeck wrote:
>> On 03/27/2012 04:56 AM, Edwin van den Oetelaar wrote:
>>> Hello everyone,
>>> My name is Edwin, I have some motivation and skill to help with your project.
>>> Although I am not very old yet, I do have some deep knowledge of
>>> PCB's, data-formats, workflow and related software.
>>> (I have been working in this field for more than 15 years)
>>>
>>> I can program in almost anything, and have some visions on how to make
>>> this project even better.
>>>
>>> Just throw me a bone (a few bugs to get my teeth into) so I can chew
>>> on it, and help you.
>> Hi Edwin,
>>
>> Welcome to our mailing list.
>>
>> One of the tasks we are working on is a movement to a new BOARD format.  I am out for a
>> couple days soon, but after that I can write up another "work package" which describes
>> tasks needed to complete this migration.
>>
>> In the meantime, please single step through KICAD_PLUGIN to get a feel how it loads and
>> saves BOARDS.  ioascii.cpp and io_item.cpp are on death row.
>>
>> This KICAD_PLUGIN is soon to be renamed to LEGACY_PLUGIN, and the name KICAD_PLUGIN will
>> be used for new code, being written by Wayne *now*, which will use s-expressions, and
>> fractional millimeter units in the new BOARD files.
>>
>> KICAD_NANOMETER is a compile time option.   Only when defined, will we support nanometers
>> as our internal unit within PCBNEW.  Said differently, this is NOT a runtime option, but
>> is a compile time option.
>>
>> You heard me say that the BOARD is going to be saved in (fractional) millimeters, and the
>> internal units will be nanometers when KICAD_NANOMETER is defined during compilation of
>> PCBNEW.
>>
>> Most of the additional work needed to complete the bridge to KICAD_NANOMETERs is in the
>> dialogs, mouse movement scaling, etc, basically at the UI level.
>>
>> We also need to pick a new file extension, since I don't want to have to read a BOARD file
>> to figure out what format it is in.   Something like:
>>
>>
>>    *.kicad_pcb
>>
>>
>> Please answer these questions to allow me to help you best get involved:
>>
>>
>> a) are you interested in this KICAD_NANOMETER work for PCBNEW?
>>
>> b) what is your C++ experience in years and projects?
>>
>> c) how many hours per week can you offer the project?
>>
>>
>> Thanks,
>>
>> Dick
>>
>>
>>
>>> I am a bit confused about how this is coordinated, I see so many
>>> websites (sourceforge/lauchpad/yahoo, some French stuff)
>>> Just point me in the right direction.
>> Please answer the questions, and I will.
>>
>>> Keep it going, and have a happy day,
>>>
>>> Edwin
> 
> 
> Well that was a waste of 15 minutes......
> 
> 
> 
> 
> I welcome help from any qualified developer to wring out the zoom support and the dialogs
> in the USE_PCBNEW_NANOMETRE build.
> 
> Just a quick sampling of the work:
> 
> *) sensible coordinate numbers in the status bar, with proper resolution, but not greater
> than necessary.
> 
> *) dialogs should all be gone over.
> 
> *) exports to gerber, and any other file formats, including specctra
> 
> 
> Wayne has on his to do list to split out some functions from common.cpp, so that they can
> be separately compiled, for EESCHEMA and PCBNEW separately, since we've decided that these
> two code bodies will never be part of the same link image.
> 
> Those goofy functions which take an integer internal unit argument will be #ifdef compiled.

I already have created a file in my development branch to move these
functions into and make them compile time dependent instead of run time
dependent.  I also modified the CMakeList.txt files so that the
appropriate internal units get used given the current build options and
the application that it is being compiled against.  My hope is that this
will help ease the transition to the DSO/DLL implementation in the
future.  I will start moving some of these functions in the initial
commit.  It is highly likely that there will be some serious conflicts
if someone else does it at the same time.  Once I get the initial commit
of this done, it should be fairly obvious how the internal units are
being handled.  At that point I would be more than happy to get some
help wrangling these functions into the new source file.  My bet is
there are more of these floating around than I am aware of.

Thanks,

Wayne

> 
> Knowing this, there is enough here for someone to volunteer for part(s) of it.
> 
> Thanks,
> 
> Dick
> 
> 
> _______________________________________________
> 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
>