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 <m...@zaphod.sax.de> 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp