← Back to team overview

kicad-developers team mailing list archive

Re: Winbuilder Nanometer support


On 10/11/2012 3:39 PM, Adam Wolf wrote:
I'll set my PPA to whatever is decided.  I am also considering making
a "scripting PPA" with the scripting support turned on--if it's still
something that has to be turned on.

Scripting support is disabled by default. I haven't had a chance to use it yet but it seems like there are quite a few folks out there who are using it. Maybe some of them will weigh in as to whether or not scripting is ready for initial user testing. I am reluctant to turn on scripting as the default because building it on Windows it is much more involved than Linux. I don't know if Brian has the windows builder up to date to support scripting on Windows yet or not. If he does, then it may be something worth considering.

Adam Wolf
Wayne and Layne, LLC

On Thu, Oct 11, 2012 at 2:30 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
On 10/11/2012 11:31 AM, Dick Hollenbeck wrote:

On 10/11/2012 05:27 AM, Brian Sidebotham wrote:

Hi Guys,

Would it be beneficial if I changed KicadWinbuilder to build with the
new nanometer units?

It should get more people testing the nanometer support and provide
some feedback. I think quite a few people use Winbuilder to get access
to the latest versions, but don't change anything in the setup. This
way it will gradually get you some more nanometer beta testers and

Let me know as I will only take a few minutes to change.

Best Regards, Brian.

I am using the nanometer build without issue.

(My only suspicion is with respect to grabbing zone borders with the mouse
pointer.  I
have felt for some time that the hit testing there should use pixels to
measure acceptable
distance, not IU which are subject to variances on zoom factor.  Pixels
are not subject to
zoom factor.  Its in the TODO.txt file.  It is painfully hard to select a
zone boarder
reliably in the nanometer build.)

I like the idea of forcing folks to smoke out problems.  Because it has to
sometime.  There are no beta testers on some kind of payroll.

Pcbnew files (even legacy format files) created from that point forward
are not compatible
with the deci-mils build.  So it is a bridge which is difficult to
traverse backwards across.

I've found that the Eagle plugin needs the nanometer build to avoid
rounding errors,
because coming from metric to deci-mils is and has been a problem
regardless of plugin.
This was the whole impetus to move to nanometers as a means of avoiding
rounding errors
even within legacy files in the first place.

The fork in the road looks like this:

a) change now, generate a bunch of new mm based footprint libraries and mm
based legacy
board files, which are not compatible with deci-mil builds.

b) wait until the *.kicad_pcb files and s-expression footprints are fully
supported, those
will only ever be in mm, meaning this is mandatorily the nanometer build.
Legacy files
generated from this build are also not compatible with deci-meter builds.

a) and b) both have the same disadvantage.

I have personally chosen to go the a) route, because I can get more
accurate footprints
and boards in play now.  I never have to use an older version of the
software anyway.

I cannot speak for other users, only for myself, and for the benefits to
the project.

Mostly we might be speaking about new users being affected by your change
to your script.
For them I might be inclined to lean towards a) also.

If there was a pause point in the script's execution, or a way you can
explain how to
change from the default of nanometers to rebuild, that might be enough to
make everyone
minimally grumpy.

On balance, I find your suggestion more positive than negative.

I think it's a pretty good idea.  You might want to see what the Ubuntu PPA
folks are using just so we're all on the same page.  There may be a few
corner cases like print and plot scaling where things are not quite 100%.
It also might be a good idea to get the nanometre stuff fixed before we
unleash the new board and footprint library file formats.  I'm sure there
will be some grumbling because board file unit changes will create a large
diff when they didn't make any changes to the board but that is to be
expected.  No good deed goes unpunished.


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

Follow ups