kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] Zoom to fit on empty canvas
Maciej Suminski <maciej.suminski@xxxxxxx>
Fri, 17 Mar 2017 21:47:45 +0100
spf=pass (sender IP is 18.104.22.168) smtp.mailfrom=cern.ch; lists.launchpad.net; dkim=none (message not signed) header.d=none;lists.launchpad.net; dmarc=bestguesspass action=none header.from=cern.ch;
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
GAL tools do not perform any unit conversion. They work with the
internal units, whatever they are, by calling Get/SetPosition() methods.
I doubt there are other hardcoded conversions in the GAL code.
The problem with the hardcoded scaling you see in the patch (and as a
matter of fact, in the original code) is caused by WS_DRAW_ITEM_LIST
demanding a scaling factor (SetMilsToIUFactor() method). When I was
writing the code, I was really confused by the #ifdefs in
convert_to_biu.h. Even once I understood them - I still could not use
any of them, as libcommon does not define IU_PER_MILS.
To sum up: I am not proud of the existing code, but I could not find any
other way to implement this correctly. I agree there is a problem to be
solved, but I would rather fix it at its root, instead of looking for
On 03/17/2017 01:40 PM, Wayne Stambaugh wrote:
> On 3/17/2017 3:06 AM, jp charras wrote:
>> Le 17/03/2017 à 00:32, José Ignacio a écrit :
>>> eeschema uses mils, which are exactly 25400 nanometers, eeschema can be losslessly converted to
>>> nanometers. Another advantage of using nm in eeschema would be that it would be possible to use
>>> round metric quantities (right now it's impossible and confusing as numbers are rounded to the
>>> nearest mil) while being able to open older schematics losslessly.
>> But Gerbview uses 10 nanometers.
>> 1 nanometer in Gerbview creates integer overflow in some gerber files, which can use large
>> coordinates (usually due to a large offset when plotting files).
>> Eeschema has other constraints.
>> Especially, you cannot easily mix mils and mm for the working grid, because items are connected when
>> the end points are at the same location (no magnetic pin).
>> A correct handling of the actual internal units is for me the better (and the easier) way.
> This is going to have to be done at some point anyway or none of the
> "common" tools that do any unit conversions will function properly
> outside of Pcbnew. As I said before, I'm OK with merging this patch
> since this issue already exists with other tools but this just adds one
> more place where it will have to be fixed when the common tools are used
> in eeschema or gerbview.
>>> On Thu, Mar 16, 2017 at 2:16 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>> On 3/16/2017 3:03 PM, jp charras wrote:
>>> > Le 16/03/2017 à 11:21, John Beard a écrit :
>>> >> Hi JP,
>>> >> Thank for checking this. Internal units always confuse me, since
>>> >> they're always different and nothing in common can ever use anything
>>> >> to do with IUs, as they're only defined in some end executables.
>>> >> How should this be done correctly?
>>> >> Cheers,
>>> >> John
>>> > IUs are not very easy to handle, and currently I am not very happy by the way they are handled.
>>> Me neither. I've never been a big fan of compiling the same source code
>>> file multiple times (see include/convert_to_bui.h) depending on a
>>> definition specified at compile time. I would much rather see some type
>>> of abstract class be used to define the app specific internal units. Of
>>> course you would have to modify the tools to use this object to provide
>>> the proper internal units.
>>> > About the GAL layer, sorry, but I am not a GAL specialist.
>>> > However I just know this issue is serious and must be solved.
>>> This makes me reluctant to merge this patch even though it sounds like
>>> this issue already exists elsewhere in the "common" tool framework. It
>>> also means that none of the "common" gal tools that use nanometer units
>>> will be usable in the schematic editor and no I don't think nanometer
>>> units make any sense for the schematic editor.
>>> > Until now, GAL was used only by Pcbnew.
>>> > Unfortunately, in a few places, I saw a conversion to nanometers using fixed scaling factor.
>>> > (A golden advice I learned when writing Kicad code: do not use a fixed scaling factor in code)
>>> > Now GAL is very near to be used by other applications.
>>> > Conversion to nanometers just by using a fixed scaling factor is therefore a bug, and from my point
>>> > of view, even in Pcbnew.
>>> > Who know: we could change one day the internal unit value. It already happened.
>>> > I just leave guys who have a good knowledge of the GAL code taking the best decision.
>>> > Thanks, John.
>>> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/%7Ekicad-developers>
>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/%7Ekicad-developers>
>>> More help : https://help.launchpad.net/ListHelp <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
> 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