kicad-developers team mailing list archive

[Greg Smith <ecomputerd@xxxxxxxxx>]

 Hi Mathias!
I have implemented unit conversion in the entry boxesfor KiPadCheck. The code is on lines 715-835 here:
https://github.com/HiGregSmith/KiPadCheck/blob/nightly_4.0.6/kipadcheck.py

I generated the first version of the list of units, then asked at the KiCad forums and received a few suggestionsthat I integrated into the code.
Here is the full list (additional code includes the areaversions of the same units with "^2", "2", and "**2"following the unit). The code is in Python dictionary (hash table) format.

| conversion = { |
|  |  '':1, |
|  |  'nm':1, |
|  |  'nanometer':1, |
|  |  'nanometers':1, |
|  |  'um':pcbnew.IU_PER_MM/1000.0, |
|  |  'micron':pcbnew.IU_PER_MM/1000.0, |
|  |  'microns':pcbnew.IU_PER_MM/1000.0, |
|  |  'micrometer':pcbnew.IU_PER_MM/1000.0, |
|  |  'micrometers':pcbnew.IU_PER_MM/1000.0, |
|  |  'decimicron':pcbnew.IU_PER_MM/10000.0, |
|  |  'decimicrons':pcbnew.IU_PER_MM/10000.0, |
|  |  'du':pcbnew.IU_PER_MM/10000.0, |
|  |  'dus':pcbnew.IU_PER_MM/10000.0, |
|  |  'dum':pcbnew.IU_PER_MM/10000.0, |
|  |  'dums':pcbnew.IU_PER_MM/10000.0, |
|  |  'mm':pcbnew.IU_PER_MM, |
|  |  'millimeter':pcbnew.IU_PER_MM, |
|  |  'millimeters':pcbnew.IU_PER_MM, |
|  |  'm':pcbnew.IU_PER_MM*1000, |
|  |  'meter':pcbnew.IU_PER_MM*1000, |
|  |  'meters':pcbnew.IU_PER_MM*1000, |
|  |  'km':pcbnew.IU_PER_MM*1000000, |
|  |  'kilometer':pcbnew.IU_PER_MM*1000000, |
|  |  'kilometers':pcbnew.IU_PER_MM*1000000, |
|  |  'thou':pcbnew.IU_PER_MILS, |
|  |  'mil':pcbnew.IU_PER_MILS, |
|  |  'mils':pcbnew.IU_PER_MILS, |
|  |  'dmil':pcbnew.IU_PER_MILS/10.0, |
|  |  'dmils':pcbnew.IU_PER_MILS/10.0, |
|  |  'decimil':pcbnew.IU_PER_MILS/10.0, |
|  |  'decimils':pcbnew.IU_PER_MILS/10.0, |
|  |  'cmil':pcbnew.IU_PER_MILS/100.0, |
|  |  'cmils':pcbnew.IU_PER_MILS/100.0, |
|  |  'centimil':pcbnew.IU_PER_MILS/100.0, |
|  |  'centimils':pcbnew.IU_PER_MILS/100.0, |
|  |  'cm':pcbnew.IU_PER_MM*10, |
|  |  'centimeter':pcbnew.IU_PER_MM*10, |
|  |  'centimeters':pcbnew.IU_PER_MM*10, |
|  |  'in':pcbnew.IU_PER_MILS*1000.0, |
|  |  'inch':pcbnew.IU_PER_MILS*1000.0, |
|  |  'inches':pcbnew.IU_PER_MILS*1000.0, |
|  |  '"':pcbnew.IU_PER_MILS*1000.0, # inches |
|  |  "'":pcbnew.IU_PER_MILS*1000.0*12, # feet |
|  |  'feet':pcbnew.IU_PER_MILS*1000.0*12, |
|  |  'foot':pcbnew.IU_PER_MILS*1000.0*12, |
|  | } |





    On Monday, September 11, 2017, 2:42:09 PM CDT, Mathias Grimmberger <mgri@xxxxxxxxxxxxx> wrote:  
 
 
Hi all,


you may remember that I complained about the inconsistent behaviour of
several dialogs some time ago.

Below is what I have come up with to improve that. The main purpose is
to improve consistency of dialogs, although it may occasionally simplify
the code too.

Basically it is a kind of bracket around what makes up a typical input in
a dialog, namely a label, a text entry, an optional spin button and an
optional unit indicator, kind of an extended WX_UNIT_BINDER.

The idea is that the code for the dialog should only deal with that
object and use the individual controls only in special circumstances.

Below is the declaration of WX_DIMENSION_INPUT, this is for inputting
everything that ends up as a value in internal units. Also attached is
the code for 2 (simple) dialogs using it to show what that looks like
(please note that I'm not sure the values used for design rule
validation are actually the right ones, this is more for demonstration).

What WX_DIMENSION_INPUT provides for now:

- disabling/enabling of all controls belonging to the input as a group
- setting/getting the input value directly in internal units
- allowing input of optional unit suffixes (mm, in, mi etc.)
- validating that a formally correct value was entered (meaning no more
inputting "mimimi" and getting 0 as value without error message)
- validating that the value won't overflow internal units limits
- validating the value against settable minimum/maximum limits (default
> 0, <= INT_MAX)
- error popups with consistent error messages if validation fails
(e.g. "Value of 'Track width' invalid: design rules specify a minimum of
0.2 mm."), with the value name automatically derived from the label
- after the error popup is dismissed the text entry will get focus and
the text in it will be selected
- the value can be accessed either by explicit functions or by the
usual data transfer mechanism of wxWidgets

Similar (but simpler) classes can be created for input of arbitrary
floating point numbers and for integers.

Some more features would need to be added to be able to use this for
complicated dialogs like the pad properties.

So, my question is, what do you think? Is it worth continuing in this
direction (identifiers and other details can be discussed if this ever
gets to the stage of being considered for inclusion)?


Have fun,

MGri



_______________________________________________
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