kicad-developers team mailing list archive

[Miguel Ángel Ajo <majopela@xxxxxxxxxx>]

Hi, I’ve been playing a bit around, being able to locally define the default units [1]
but I’m not satisfied with it, because the implementation is not thread safe (big  
sad-face “:-(“  )

(ignore the Point(x,y) Size(x,y) passing, Piers, you really convinced me
it’s more reasonable to just use (x,y) where we can.

I have forked your lib here:  https://github.com/KiCad/kicad-python (https://github.com/KiCad/kicad-python/blob/master/kicad/units.py) to retain
your original authorship.

I have also added sphinx so we can build the docs as normally done for python
APIs [2] and a bit of testing [3] which is passed over here, along with pep8 / flake8 checks
[4], for that may be it’s better to use travis-ci as it has better integration to
github.

I will be playing a bit more around the default units context, as a second option
we could default to inches or mm (with the ability to explicitly provide other unit
in parameters).

I would guess that mm is more common among users, because of the european
origin of the software, but may be a poll would be good here.

Best regards,
Miguel Ángel.

[1] https://github.com/KiCad/kicad-python/blob/master/kicad/units.py  
[2] http://ci.kicad-pcb.org/job/kicad-python/ws/doc/build/html/index.html
[3] https://github.com/KiCad/kicad-python/tree/master/kicad/tests/unit
[4] http://ci.kicad-pcb.org/job/kicad-python/


Miguel Ángel Ajo


On Friday, 16 de January de 2015 at 20:35, Miguel Ángel Ajo wrote:

>  
>  
> Miguel Ángel Ajo
>  
>  
> On Friday, 16 de January de 2015 at 20:01, LordBlick wrote:
>  
> > In response to a message written on 16.01.2015, 18:43, from Miguel Ángel Ajo:
> > > About using mm as the default unit, other people may disagree, we should provide
> > > facilities to let people specify their unit.
> > >  
> >  
> > wxPoint and wxSize can be subclassed to allow any arithmetical operation and  
> > unit conversion with propietary methods.
> > > > As Jean-Pierre Charras wrote in thread nearly, board names for cooper layers may
> > > > vary:
> > > > brd = pcbnew
> > > > pcb = brd.GetBoard()
> > > > > > > pcb.SetLayerName(0, 'Top')
> > > > > >  
> > > > >  
> > > >  
> > > > True
> > > > > > > pcb.SetLayerName(31, 'Bottom')
> > > > > >  
> > > > >  
> > > >  
> > > > True
> > > > > > > pcb.SetLayerName(32, 'BottomGlue')
> > > > > >  
> > > > >  
> > > >  
> > > > False
> > > > > > >  
> > > > > >  
> > > > >  
> > > >  
> > > >  
> > >  
> > >  
> > > Hmm, that’s an important point for not referencing layers by names dynamically,
> > > (I was proposing that too)
> > >  
> > > may be we should be defining a set of 32 constants for the layers we can reference
> > > and keep up to date with any ID changes at the C++ side. Although I suppose ID’s
> > > are not
> > > going to change for compatibility reasons.
> > >  
> >  
> > Seems to be unessary creating independent data. Simply:
> > lsLayers = tuple([(idl, brd.BOARD_GetStandardLayerName(idl)) for idl in  
> > range(brd.LAYER_ID_COUNT)])
> > lsCuLayers = tuple(filter(lambda idl, layerName: layerName.endswith('.Cu'),  
> > lsLayers))
> >  
> Yes, you already told me, but wasn’t the point against using provided names
> that they could eventualy change?.
>  
> This is why I was suggesting constants. It’s not an awful work ;) but I understand you may
> not want to do it ;)  
>  
>   
> > --  
> > Best Regards,
> > LordBlick
> >  
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto: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 (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>