Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

And the version with default units:  

https://github.com/KiCad/kicad-python/pull/7/files

Looks quite clean to me, and yet all the precision from native units is 
retained, plus
we can do things like:
>> p = Point((2**31-1) * nm, (-(2**31)+1) *nm)
>> p.nm
(2147483647.0, -2146483648.0)


>>> p=Point(1,2)
>>> p.inch
(0.03937007874015748, 0.07874015748031496)

>>> p=Point(1*inch, 1*inch)
>>> p.inch
(1.0, 1.0)
>>> p.mm
(25.4, 25.4)
>>> p.nm
(2540.0, 2540.0)
>>> p.rotate(90, around=(0,0))
>>> p
Point(-25.4, 25.4)




Miguel Ángel Ajo


On Sunday, 25 de January de 2015 at 03:03, Miguel Ángel Ajo wrote:

> A little experiment, with the suggested * mm / * inch notation.  
>  
> https://github.com/KiCad/kicad-python/pull/6/files [1]
>  
> Look specially at the tests (last files).
>  
> Feel free to comment over the code.
>  
> If we could default to mm (my preferred) or inches, we could
> save a lot of code (specially to process by human brains
> reading python) while retaining all the precision.
>  
>  
> Best,
> Miguel Ángel Ajo
> [1] Note: 2 builds failed because I didn’t make the C++ “pcbnew” module for 
> the tests.
>  
>  
> On Sunday, 25 de January de 2015 at 02:56, Tomasz Wlostowski wrote:
>  
> > On 25.01.2015 02:50, Miguel Ángel Ajo wrote:
> > >  
> > > I was just testing that.
> > >  
> > > Python floats (in all architectures) are double, so the 52 bit fraction 
> > > (11 bit exp) is always
> > > going to hold more information that the 32bits wxPoint /wxSize can hold.
> > >  
> >  
> >  
> > Hi Miguel,
> >  
> > Sorry, I'm a C/C++ guy, so float defaults for me to 32 bits ;) Doubles
> > look ok, although the decimal part will be anyway truncated on the way
> > from Python to C++ (if we decide to keep the nm as default unit)
> >  
> > Cheers,
> > T.
> >  
> >  
> >  
>  
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

A little experiment, with the suggested * mm / * inch notation.  

https://github.com/KiCad/kicad-python/pull/6/files [1]

Look specially at the tests (last files).

Feel free to comment over the code.

If we could default to mm (my preferred) or inches, we could
save a lot of code (specially to process by human brains
reading python) while retaining all the precision.


Best,
Miguel Ángel Ajo
[1] Note: 2 builds failed because I didn’t make the C++ “pcbnew” module for the 
tests.


On Sunday, 25 de January de 2015 at 02:56, Tomasz Wlostowski wrote:

> On 25.01.2015 02:50, Miguel Ángel Ajo wrote:
> >  
> > I was just testing that.
> >  
> > Python floats (in all architectures) are double, so the 52 bit fraction (11 
> > bit exp) is always
> > going to hold more information that the 32bits wxPoint /wxSize can hold.
> >  
>  
>  
> Hi Miguel,
>  
> Sorry, I'm a C/C++ guy, so float defaults for me to 32 bits ;) Doubles
> look ok, although the decimal part will be anyway truncated on the way
> from Python to C++ (if we decide to keep the nm as default unit)
>  
> Cheers,
> T.
>  
>  


___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Tomasz Wlostowski]

On 25.01.2015 02:50, Miguel Ángel Ajo wrote:
> 
> I was just testing that.
> 
>   Python floats (in all architectures) are double, so the 52 bit fraction (11 
> bit exp) is always
> going to hold more information that the 32bits wxPoint /wxSize can hold.

Hi Miguel,

Sorry, I'm a C/C++ guy, so float defaults for me to 32 bits ;) Doubles
look ok, although the decimal part will be anyway truncated on the way
from Python to C++ (if we decide to keep the nm as default unit)

Cheers,
T.


___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

I was just testing that.

  Python floats (in all architectures) are double, so the 52 bit fraction (11 
bit exp) is always
going to hold more information that the 32bits wxPoint /wxSize can hold.

   So that’s not a point.

   I’m experimenting with both options, to see what’s more readable.  

Miguel Ángel Ajo


On Sunday, 25 de January de 2015 at 02:48, Tomasz Wlostowski wrote:

> On 25.01.2015 02:04, Piers Titus van der Torren wrote:
> > While I understand that for internal units it's good to use integers and
> > hence small units, for this high level python api I don't see much benefits
> > for not using floats and sensible default  
> >  
>  
>  
> Dear Peter,
>  
> 32-bit float is bad simply because the set of 32-bit floats is not a
> superset of 32 bit integers. This means merely converting an integer
> coordinate to float and back to int may loose accuracy. In case of
> tightly packed primitives, one might end up with unwanted DRC errors.
>  
> As for small vs big units - units matter on the UI side, when the user
> inputs some parameters for the script in a dialog window.
> Inputting/outputting values with units should be therefore made as easy
> as possible. Processing the data is IMHO a different story - computers
> don't care if they do calculations in milli- or nanometers. So why
> create yet another unit definition?
>  
> Tom
>  
> units like degrees and mm.
> > Keeping the internal api intact still allows for low level scripting and
> > using internal units. Even combined with this api, as the internal object
> > currently is easily available as ._module for example.
> > I see this api as a user interface, where internal units may be hidden just
> > like in the gui.
> > Also the * inch syntax can be used if preferred with inch = 25.4.
> >  
> > Piers
> > Op 24 jan. 2015 23:48 schreef "Miguel Ángel Ajo"  > (mailto:majop...@redhat.com)>:
> >  
> > > Hmm, I’m actually liking Tom’s suggestion, sounds quite natural to me.
> > >  
> > > pcb.create_module(ref=‘A1’, position=(10 * mm, 10 * mm))
> > >  
> > > but also accepting pcb.create_module(ref=‘B1’, position=Point(10 * mm, 10
> > > * mm))
> > >  
> > > I’d do the function parameter translation into Point automatically, even
> > > if I believe parameter
> > > input should be easy, having a class for points or sizes makes them easier
> > > to manipulate,
> > > for example if we wanted to rotate them:
> > >  
> > > point.rotate(2 * rad)
> > >  
> > > point.rotate(90 * deg, around=(5 * mm, 5 * mm))
> > >  
> > > or
> > >  
> > > new_point = point.rotated(90 * deg)
> > >  
> > > --
> > > Side note, not sure why I thought IUs were 10nm, but they are 1nm (and
> > > 10nm for gerbview, I suppose the
> > > reason for the gerview change is being able to stack the biggest boards
> > > 10x10)
> > >  
> > > http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/include/convert_to_biu.h#L44
> > >  
> > > Miguel Ángel Ajo
> > >  
> > > On Saturday, 24 de January de 2015 at 22:37, tiger12506 wrote:
> > >  
> > > I have no weight in the discussion, but I really like Tom's suggestion
> > > here.
> > >  
> > > It allows you to use them as if they were units. 10 * mm is almost
> > > syntactically identical to 10mm.
> > > And they don't get in the way with a bunch of boilerplate, like some of
> > > the other suggestions do.
> > >  
> > > ~JS
> > >  
> > > On 1/24/2015 3:55 PM, Tomasz Wlostowski wrote:
> > >  
> > > On 16.01.2015 18:43, Miguel Ángel Ajo wrote:
> > >  
> > > The user shouldn’t need to know what an IU is unless he really wants, for
> > > some
> > > reason.
> > >  
> > > Hi Miguel,
> > >  
> > > Why make things complicated here? Given that the choice of IUs in pcbnew
> > > is very reasonable and easy to understand, I see no reason for hiding
> > > that knowledge from script writers. A nanometer after all, is just
> > > one-millionth of a millimeter. No rocket science here...
> > >  
> > > On the other hand, we need to provide a sensible way of
> > > inputting/presenting values with units. For hardcoded values, defining
> > > units could be just multiplying by a fixed scalefactor:
> > >  
> > > from pcbnew import mm, inch, mils
> > >  
> > > #pcbnew.mm = 100
> > > #pcbnew.inch = 2540
> > > #pcbnew.mils = 25400
> > >  
> > > p = Point(10 * mm, 12 * mm)
> > >  
> > > Concerning UI input/output (dialogs) - recently I had to do some dialogs
> > > for P&S with lots of values in mm/inches, so to avoid repeatable unit
> > > conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
> > > binds together a WX text control with an unit label:
> > >  
> > > class MyDialog : public dialog_generated_by_wxfb_base {
> > > WX_UNIT_BINDER m_myValueInUnits;
> > > };
> > >  
> > > MyDialog::MyDialog() :
> > > m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
> > > {
> > > m_myValueInUnits.SetValue ( value_in_iu_here )
> > > // x = m_myValueInUnits.GetValue();
> > > }
> > >  
> > > All unit conversion is done inside the bi

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Tomasz Wlostowski]

On 25.01.2015 02:04, Piers Titus van der Torren wrote:
> While I understand that for internal units it's good to use integers and
> hence small units, for this high level python api I don't see much benefits
> for not using floats and sensible default 

Dear Peter,

32-bit float is bad simply because the set of 32-bit floats is not a
superset of 32 bit integers. This means merely converting an integer
coordinate to float and back to int may loose accuracy. In case of
tightly packed primitives, one might end up with unwanted DRC errors.

As for small vs big units - units matter on the UI side, when the user
inputs some parameters for the script in a dialog window.
Inputting/outputting values with units should be therefore made as easy
as possible. Processing the data is IMHO a different story - computers
don't care if they do calculations in milli- or nanometers. So why
create yet another unit definition?

Tom

units like degrees and mm.
> Keeping the internal api intact still allows for low level scripting and
> using internal units. Even combined with this api, as the internal object
> currently is easily available as ._module for example.
> I see this api as a user interface, where internal units may be hidden just
> like in the gui.
> Also the * inch syntax can be used if preferred with inch = 25.4.
> 
> Piers
> Op 24 jan. 2015 23:48 schreef "Miguel Ángel Ajo" :
> 
>> Hmm, I’m actually liking Tom’s suggestion, sounds quite natural to me.
>>
>> pcb.create_module(ref=‘A1’, position=(10 * mm, 10 * mm))
>>
>> but also accepting pcb.create_module(ref=‘B1’, position=Point(10 * mm, 10
>> * mm))
>>
>> I’d do the function parameter translation into Point automatically, even
>> if I believe parameter
>> input should be easy, having a class for points or sizes makes them easier
>> to manipulate,
>> for example if we wanted to rotate them:
>>
>> point.rotate(2 * rad)
>>
>> point.rotate(90 * deg, around=(5 * mm, 5 * mm))
>>
>> or
>>
>> new_point = point.rotated(90 * deg)
>>
>> --
>> Side note, not sure why I thought IUs were 10nm, but they are 1nm (and
>> 10nm for gerbview, I suppose the
>> reason for the gerview change is being able to stack the biggest boards
>> 10x10)
>>
>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/include/convert_to_biu.h#L44
>>
>> Miguel Ángel Ajo
>>
>> On Saturday, 24 de January de 2015 at 22:37, tiger12506 wrote:
>>
>> I have no weight in the discussion, but I really like Tom's suggestion
>> here.
>>
>> It allows you to use them as if they were units. 10 * mm is almost
>> syntactically identical to 10mm.
>> And they don't get in the way with a bunch of boilerplate, like some of
>> the other suggestions do.
>>
>> ~JS
>>
>> On 1/24/2015 3:55 PM, Tomasz Wlostowski wrote:
>>
>> On 16.01.2015 18:43, Miguel Ángel Ajo wrote:
>>
>> The user shouldn’t need to know what an IU is unless he really wants, for
>> some
>> reason.
>>
>> Hi Miguel,
>>
>> Why make things complicated here? Given that the choice of IUs in pcbnew
>> is very reasonable and easy to understand, I see no reason for hiding
>> that knowledge from script writers. A nanometer after all, is just
>> one-millionth of a millimeter. No rocket science here...
>>
>> On the other hand, we need to provide a sensible way of
>> inputting/presenting values with units. For hardcoded values, defining
>> units could be just multiplying by a fixed scalefactor:
>>
>> from pcbnew import mm, inch, mils
>>
>> #pcbnew.mm = 100
>> #pcbnew.inch = 2540
>> #pcbnew.mils = 25400
>>
>> p = Point(10 * mm, 12 * mm)
>>
>> Concerning UI input/output (dialogs) - recently I had to do some dialogs
>> for P&S with lots of values in mm/inches, so to avoid repeatable unit
>> conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
>> binds together a WX text control with an unit label:
>>
>> class MyDialog : public dialog_generated_by_wxfb_base {
>> WX_UNIT_BINDER m_myValueInUnits;
>> };
>>
>> MyDialog::MyDialog() :
>> m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
>> {
>> m_myValueInUnits.SetValue ( value_in_iu_here )
>> // x = m_myValueInUnits.GetValue();
>> }
>>
>> All unit conversion is done inside the binder class, according to the
>> current units setting. All the user needs to do is to get/set the value
>> in IUs. Maybe a similar method could be used in the scripting API?
>>
>> Cheers,
>> Tom
>>
>> [1]
>>
>> https://github.com/twlostow/kicad-dev/blob/tmp-crap/include/wx_unit_binder.h
>>
>> ___
>> 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.launch

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Piers Titus van der Torren]

While I understand that for internal units it's good to use integers and
hence small units, for this high level python api I don't see much benefits
for not using floats and sensible default units like degrees and mm.
Keeping the internal api intact still allows for low level scripting and
using internal units. Even combined with this api, as the internal object
currently is easily available as ._module for example.
I see this api as a user interface, where internal units may be hidden just
like in the gui.
Also the * inch syntax can be used if preferred with inch = 25.4.

Piers
Op 24 jan. 2015 23:48 schreef "Miguel Ángel Ajo" :

> Hmm, I’m actually liking Tom’s suggestion, sounds quite natural to me.
>
> pcb.create_module(ref=‘A1’, position=(10 * mm, 10 * mm))
>
> but also accepting pcb.create_module(ref=‘B1’, position=Point(10 * mm, 10
> * mm))
>
> I’d do the function parameter translation into Point automatically, even
> if I believe parameter
> input should be easy, having a class for points or sizes makes them easier
> to manipulate,
> for example if we wanted to rotate them:
>
> point.rotate(2 * rad)
>
> point.rotate(90 * deg, around=(5 * mm, 5 * mm))
>
> or
>
> new_point = point.rotated(90 * deg)
>
> --
> Side note, not sure why I thought IUs were 10nm, but they are 1nm (and
> 10nm for gerbview, I suppose the
> reason for the gerview change is being able to stack the biggest boards
> 10x10)
>
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/include/convert_to_biu.h#L44
>
> Miguel Ángel Ajo
>
> On Saturday, 24 de January de 2015 at 22:37, tiger12506 wrote:
>
> I have no weight in the discussion, but I really like Tom's suggestion
> here.
>
> It allows you to use them as if they were units. 10 * mm is almost
> syntactically identical to 10mm.
> And they don't get in the way with a bunch of boilerplate, like some of
> the other suggestions do.
>
> ~JS
>
> On 1/24/2015 3:55 PM, Tomasz Wlostowski wrote:
>
> On 16.01.2015 18:43, Miguel Ángel Ajo wrote:
>
> The user shouldn’t need to know what an IU is unless he really wants, for
> some
> reason.
>
> Hi Miguel,
>
> Why make things complicated here? Given that the choice of IUs in pcbnew
> is very reasonable and easy to understand, I see no reason for hiding
> that knowledge from script writers. A nanometer after all, is just
> one-millionth of a millimeter. No rocket science here...
>
> On the other hand, we need to provide a sensible way of
> inputting/presenting values with units. For hardcoded values, defining
> units could be just multiplying by a fixed scalefactor:
>
> from pcbnew import mm, inch, mils
>
> #pcbnew.mm = 100
> #pcbnew.inch = 2540
> #pcbnew.mils = 25400
>
> p = Point(10 * mm, 12 * mm)
>
> Concerning UI input/output (dialogs) - recently I had to do some dialogs
> for P&S with lots of values in mm/inches, so to avoid repeatable unit
> conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
> binds together a WX text control with an unit label:
>
> class MyDialog : public dialog_generated_by_wxfb_base {
> WX_UNIT_BINDER m_myValueInUnits;
> };
>
> MyDialog::MyDialog() :
> m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
> {
> m_myValueInUnits.SetValue ( value_in_iu_here )
> // x = m_myValueInUnits.GetValue();
> }
>
> All unit conversion is done inside the binder class, according to the
> current units setting. All the user needs to do is to get/set the value
> in IUs. Maybe a similar method could be used in the scripting API?
>
> Cheers,
> Tom
>
> [1]
>
> https://github.com/twlostow/kicad-dev/blob/tmp-crap/include/wx_unit_binder.h
>
> ___
> 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
>
>
>
> ___
> 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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

Hmm, I’m actually liking Tom’s suggestion, sounds quite natural to me.

pcb.create_module(ref=‘A1’, position=(10 * mm, 10 * mm))

but also accepting pcb.create_module(ref=‘B1’, position=Point(10 * mm, 10 * 
mm))  

I’d do the function parameter translation into Point automatically, even if I 
believe parameter
input should be easy, having a class for points or sizes makes them easier to 
manipulate,
for example if we wanted to rotate them:

point.rotate(2 * rad)

point.rotate(90 * deg, around=(5 * mm, 5 * mm))

or  

new_point = point.rotated(90 * deg)

--
Side note, not sure why I thought IUs were 10nm, but they are 1nm (and 10nm for 
gerbview, I suppose the
reason for the gerview change is being able to stack the biggest boards 10x10)
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/include/convert_to_biu.h#L44


Miguel Ángel Ajo


On Saturday, 24 de January de 2015 at 22:37, tiger12506 wrote:

> I have no weight in the discussion, but I really like Tom's suggestion here.
>  
> It allows you to use them as if they were units. 10 * mm is almost  
> syntactically identical to 10mm.
> And they don't get in the way with a bunch of boilerplate, like some of  
> the other suggestions do.
>  
> ~JS
>  
> On 1/24/2015 3:55 PM, Tomasz Wlostowski wrote:
> > On 16.01.2015 18:43, Miguel Ángel Ajo wrote:
> > > The user shouldn’t need to know what an IU is unless he really wants, for 
> > > some
> > > reason.
> > >  
> >  
> > Hi Miguel,
> >  
> > Why make things complicated here? Given that the choice of IUs in pcbnew
> > is very reasonable and easy to understand, I see no reason for hiding
> > that knowledge from script writers. A nanometer after all, is just
> > one-millionth of a millimeter. No rocket science here...
> >  
> > On the other hand, we need to provide a sensible way of
> > inputting/presenting values with units. For hardcoded values, defining
> > units could be just multiplying by a fixed scalefactor:
> >  
> > from pcbnew import mm, inch, mils
> >  
> > #pcbnew.mm = 100
> > #pcbnew.inch = 2540
> > #pcbnew.mils = 25400
> >  
> > p = Point(10 * mm, 12 * mm)
> >  
> > Concerning UI input/output (dialogs) - recently I had to do some dialogs
> > for P&S with lots of values in mm/inches, so to avoid repeatable unit
> > conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
> > binds together a WX text control with an unit label:
> >  
> > class MyDialog : public dialog_generated_by_wxfb_base {
> > WX_UNIT_BINDER m_myValueInUnits;
> > };
> >  
> > MyDialog::MyDialog() :
> > m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
> > {
> > m_myValueInUnits.SetValue ( value_in_iu_here )
> > // x = m_myValueInUnits.GetValue();
> > }
> >  
> > All unit conversion is done inside the binder class, according to the
> > current units setting. All the user needs to do is to get/set the value
> > in IUs. Maybe a similar method could be used in the scripting API?
> >  
> > Cheers,
> > Tom
> >  
> > [1]
> > https://github.com/twlostow/kicad-dev/blob/tmp-crap/include/wx_unit_binder.h
> >  
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net 
> > (mailto: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 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[tiger12506]

I have no weight in the discussion, but I really like Tom's suggestion here.

It allows you to use them as if they were units. 10 * mm is almost 
syntactically identical to 10mm.
And they don't get in the way with a bunch of boilerplate, like some of 
the other suggestions do.


~JS

On 1/24/2015 3:55 PM, Tomasz Wlostowski wrote:

On 16.01.2015 18:43, Miguel Ángel Ajo wrote:

The user shouldn’t need to know what an IU is unless he really wants, for some
reason.


Hi Miguel,

Why make things complicated here? Given that the choice of IUs in pcbnew
is very reasonable and easy to understand, I see no reason for hiding
that knowledge from script writers. A nanometer after all, is just
one-millionth of a millimeter. No rocket science here...

On the other hand, we need to provide a sensible way of
inputting/presenting values with units. For hardcoded values, defining
units could be just multiplying by a fixed scalefactor:

from pcbnew import mm, inch, mils

#pcbnew.mm = 100
#pcbnew.inch = 2540
#pcbnew.mils = 25400

p = Point(10 * mm, 12 * mm)

Concerning UI input/output (dialogs) - recently I had to do some dialogs
for P&S with lots of values in mm/inches, so to avoid repeatable unit
conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
binds together a WX text control with an unit label:

class MyDialog : public dialog_generated_by_wxfb_base {
WX_UNIT_BINDER m_myValueInUnits;
};

MyDialog::MyDialog() :
m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
{
m_myValueInUnits.SetValue ( value_in_iu_here )
// x = m_myValueInUnits.GetValue();
}

All unit conversion is done inside the binder class, according to the
current units setting. All the user needs to do is to get/set the value
in IUs. Maybe a similar method could be used in the scripting API?

Cheers,
Tom

[1]
https://github.com/twlostow/kicad-dev/blob/tmp-crap/include/wx_unit_binder.h

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

On Saturday, 24 de January de 2015 at 20:02, LordBlick wrote:

> In response to a message written on 24.01.2015, 11:58, from Miguel Ángel Ajo:
> I hope that the current possibility to use the original „import pcbnew” will  
> remain intact. Internal units under KiCAD as integers are the most precise 
> form.
> As python script writer I don't need nothing else.
> I also do not want it to previous results of my few months work has become  
> incompatible.
>  
No intention to break the C++ pcbnew module. This is partly why I
put everything under the kicad.* umbrella.

About IU, I believe we should provide access to IU if the user wants to
use it. May be we should call the unit NM10 or something similar,  
so people knows what it means, and in the event the internal  
unit changed (very unlikely) we could still keep backwards-compatibility.

Best,
Migue Ángel

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Tomasz Wlostowski]

On 16.01.2015 18:43, Miguel Ángel Ajo wrote:
> 
> The user shouldn’t need to know what an IU is unless he really wants, for some
> reason.
>
Hi Miguel,

Why make things complicated here? Given that the choice of IUs in pcbnew
is very reasonable and easy to understand, I see no reason for hiding
that knowledge from script writers. A nanometer after all, is just
one-millionth of a millimeter. No rocket science here...

On the other hand, we need to provide a sensible way of
inputting/presenting values with units. For hardcoded values, defining
units could be just multiplying by a fixed scalefactor:

from pcbnew import mm, inch, mils

#pcbnew.mm = 100
#pcbnew.inch = 2540
#pcbnew.mils = 25400

p = Point(10 * mm, 12 * mm)

Concerning UI input/output (dialogs) - recently I had to do some dialogs
for P&S with lots of values in mm/inches, so to avoid repeatable unit
conversion code, I developed a class tiny called WX_UNIT_BINDER [1]. It
binds together a WX text control with an unit label:

class MyDialog : public dialog_generated_by_wxfb_base {
WX_UNIT_BINDER m_myValueInUnits;
};

MyDialog::MyDialog() :
m_myValueInUnits ( m_myValueText, m_myValueUnitLabel )
{
m_myValueInUnits.SetValue ( value_in_iu_here )
// x = m_myValueInUnits.GetValue();
}

All unit conversion is done inside the binder class, according to the
current units setting. All the user needs to do is to get/set the value
in IUs. Maybe a similar method could be used in the scripting API?

Cheers,
Tom

[1]
https://github.com/twlostow/kicad-dev/blob/tmp-crap/include/wx_unit_binder.h

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 24.01.2015, 11:58, from Miguel Ángel Ajo:
I hope that the current  possibility to use the original „import pcbnew” will 
remain intact. Internal units under KiCAD as integers are the most precise form.

As python script writer I don't need nothing else.
I also do not want it to previous results of my few months work has become 
incompatible.


--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

On Saturday, 24 de January de 2015 at 14:25, Piers Titus van der Torren wrote:

> On Sat, Jan 24, 2015 at 11:58 AM, Miguel Ángel Ajo  (mailto:majop...@redhat.com)> wrote:
> > 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 “:-(“  )
> >  
> Another option would be to use the default unit from the general settings 
> (g_UserUnit), that way nothing has to be stored in the python module. Just 
> user unit versions of the conversion functions would do:
> def _from_user_units(val):
> unit = pcbnew.GetAbbreviatedUnitsLabel()
> if unit == 'in':
> return pcbnew.FromMM(float(val) * 25.4)
> elif unit == 'mm':
> return pcbnew.FromMM(float(val))
>  
> However I think this may add more problems than being clear about a default 
> unit and having easy conversion functions. (mostly on the user side with 
> forgetting to set/check default units, but also on the internal side where 
> float rounding issues might appear, 1.0/2.54*2.54 = 0. with 
> float precision)
>  

I believe relying on user settings would render scripts incompatible depending 
on the settings the user
configured.

If we set an standard needs to be compatible forever and all.

For just in case using contexts doesn’t work (starts to look like it’s not 
possible (thread safe)  
without hacking too much - looking back stack frames until finding last unit 
settings, I’ve
created this poll:

https://www.surveymonkey.com/s/YBSKM9C

Does it look reasonable before sharing starting an specific thread?.
  
>  
> > (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.
> >  
> Thanks, good to have more structure. What's the reason you didn't rename 
> pcbnew_easy.py to kicad/pcbnew.py? I don't see the need for a subdirectory 
> there.
>   
> > 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).  
>  
> Nice to see these experiments with contexts, it's a nifty idea.
> However I still think the easiest and most versatile solution would be to 
> have default units and a recursive inch_to_mm (or shorter: in2mm) function.
>  
> For example combining units like in the following action would be hard with a 
> units='in' parameter:
>  
> m.add_pad(position=in2mm((0, 0.1)), drill=1.0)
>  
> I do use both units sometimes because some things are standardized in inch, 
> like pin header spacing, but in that case I still use metric drill sizes, so 
> I think this example is a realistic action.
>   
> > 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.
> >  
> >  
>  
>  
>  And most American companies finally use metric units too nowadays (at least 
> in most datasheets I encounter)
> >  
> > 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/
> >  
> >   
> >  
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

Interesting update,  about CI,  

I’ve been able to integrate jenkins back to github pull requests:

https://github.com/KiCad/kicad-python/pull/5

Now when there is a pull request on kicad-python, the CI passes
to make sure it’s ok.

If we ever move things to github, we could do such thing for the whole
kicad, in combination with better testing.


Miguel Ángel Ajo


On Saturday, 24 de January de 2015 at 11:58, Miguel Ángel Ajo wrote:

> 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@lists.launchpad.net 
> > > (mailto: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 
> > (mailto: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 
> 

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Piers Titus van der Torren]

On Sat, Jan 24, 2015 at 11:58 AM, Miguel Ángel Ajo 
wrote:

> 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 “:-(“  )
>
> Another option would be to use the default unit from the general settings
(g_UserUnit), that way nothing has to be stored in the python module. Just
user unit versions of the conversion functions would do:
def _from_user_units(val):
unit = pcbnew.GetAbbreviatedUnitsLabel()
if unit == 'in':
return pcbnew.FromMM(float(val) * 25.4)
elif unit == 'mm':
return pcbnew.FromMM(float(val))

However I think this may add more problems than being clear about a default
unit and having easy conversion functions. (mostly on the user side with
forgetting to set/check default units, but also on the internal side where
float rounding issues might appear, 1.0/2.54*2.54 = 0. with
float precision)

(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
>  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.
>
> Thanks, good to have more structure. What's the reason you didn't rename
pcbnew_easy.py to kicad/pcbnew.py? I don't see the need for a subdirectory
there.


> 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).
>

Nice to see these experiments with contexts, it's a nifty idea.
However I still think the easiest and most versatile solution would be to
have default units and a recursive inch_to_mm (or shorter: in2mm) function.

For example combining units like in the following action would be hard with
a units='in' parameter:

m.add_pad(position=in2mm((0, 0.1)), drill=1.0)

I do use both units sometimes because some things are standardized in inch,
like pin header spacing, but in that case I still use metric drill sizes,
so I think this example is a realistic action.


> 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.
>

 And most American companies finally use metric units too nowadays (at
least in most datasheets I encounter)

>
> 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/
>
>
>
___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

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@lists.launchpad.net 
> > (mailto: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 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

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@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

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))


--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

About using mm as the default unit, other people may disagree, we should provide
facilities to let people specify their unit.


On Friday, 16 de January de 2015 at 18:30, LordBlick wrote:

> In response to a message written on 16.01.2015, 18:10, from Piers Titus van 
> der  
> Torren:
> > About units: For me it was a big benefit to be able to just use any 2 
> > element
> > tuple like object for coordinates and sizes, and direct numbers for other
> > values, and not having to use a conversion to internal units all the time. 
> > I do
> > a lot of my calculations with numpy, so it makes things a lot easier if 
> > numpy
> > arrays can be used directly.
> > To me it makes most sense to use mm as default unit for the python API, and
> > convert from inches to mm using a simple inch2mm function.
> >  
>  
> Why not use KiCAD internal units ?
>  
>  

I would hold internally the IUs, I agree. But that should only be internal,  
or accessible via .to_iu / .from_iu if we wanted…

The user shouldn’t need to know what an IU is unless he really wants, for some
reason.
  
> Any necessary geometric calculation can be  
> implemented in compiled _pcbnew.so
> Also we can look onto Cython…
>  
>  

We may reuse any logic that it’s already provided by the pcbnew classes,
and sometimes we can even extend them (if there is an evident bottleneck).  
  
> >  
> > Furthermore I put my script in a github repository, like Wayne suggested, I 
> > hope
> > this leads to more organized experimenting, please clone and improve. It 
> > can be
> > found at https://github.com/pierstitus/kicad-python
> >  
> > LordBlick, thanks for another improvement to the layer conversion, it is 
> > much
> > better to use the names that are used in the GUI ('F.Cu' instead of 'F_Cu').
> >  
>  
> 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.
>  
> > It's committed to the github repo above.
> Thank you for cooperate… :)
>  
>  


Thank you Piers, it’s actually an awesome start point.  
>  
> --  
> Best Regards,
> LordBlick
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 16.01.2015, 18:10, from Piers Titus van der 
Torren:

About units: For me it was a big benefit to be able to just use any 2 element
tuple like object for coordinates and sizes, and direct numbers for other
values, and not having to use a conversion to internal units all the time. I do
a lot of my calculations with numpy, so it makes things a lot easier if numpy
arrays can be used directly.
To me it makes most sense to use mm as default unit for the python API, and
convert from inches to mm using a simple inch2mm function.
Why not use KiCAD internal units ? Any necessary geometric calculation can be 
implemented in compiled _pcbnew.so

Also we can look onto Cython…


Furthermore I put my script in a github repository, like Wayne suggested, I hope
this leads to more organized experimenting, please clone and improve. It can be
found at https://github.com/pierstitus/kicad-python

LordBlick, thanks for another improvement to the layer conversion, it is much
better to use the names that are used in the GUI ('F.Cu' instead of 'F_Cu').
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
>>>


It's committed to the github repo above.

Thank you for cooperate… :)

--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Piers Titus van der Torren]

About units: For me it was a big benefit to be able to just use any 2
element tuple like object for coordinates and sizes, and direct numbers for
other values, and not having to use a conversion to internal units all the
time. I do a lot of my calculations with numpy, so it makes things a lot
easier if numpy arrays can be used directly.
To me it makes most sense to use mm as default unit for the python API, and
convert from inches to mm using a simple inch2mm function.

Furthermore I put my script in a github repository, like Wayne suggested, I
hope this leads to more organized experimenting, please clone and improve.
It can be found at https://github.com/pierstitus/kicad-python

LordBlick, thanks for another improvement to the layer conversion, it is
much better to use the names that are used in the GUI ('F.Cu' instead of
'F_Cu'). It's committed to the github repo above.

Piers

On Fri, Jan 16, 2015 at 5:14 PM, Miguel Ángel Ajo 
wrote:

>
> First of all, let me first clarify, we’re discussing two things at the
> same time:
>
> [people scripts (2, 2.1, 2.2)] —> [kicad-python-api(1)i] —> [C++
> swigged-API]
>
>
> 1) Building an API to access the kicad objects in a way that is not
> tightly coupled to the KiCad internals, and that it’s for consumption from
> python scripts. This API is to be written in python.
>
> I believe this API should live in the kicad repository, even if we
> iterate
> first on a separate one. This way, when breaking changes happen in the C++
> implementation (interface change, object change, etc..) the API layer
> can be updated to work with the new C++ interface.
>
>
> 2) Having scripts people build on python to provide specific functions.
> This could live on a separate repo without risk, since the API contract
> should not change (unless somehow deprecated). If something becomes
> really useful for the wide community, of course, it can always be packaged
> together with KiCad.
>
> 2.1) At some point, we could even make a repository available via github,
>  the same way we do for footprints.
>
> 2.2) I also find interesting another kind of special functions, not to run
> standalone
> from kicad, but to run inside kicad:
>
> a) Contextual menu hooks: scripts that can hook certain contextual
> menus,
> to provide functions, so users can plug those special functions
> into kicad.
>
> b) Tool bar hooks: To install functions in the toolbar.
>
> c) I/O plugins: To write I/O plugins in plain python.
>
>
> I’m replying between lines too->
>
> On Friday, 16 de January de 2015 at 15:25, LordBlick wrote:
>
> In response to a message written on 16.01.2015, 14:35, from Tomasz
> Wlostowski:
>
> On 16.01.2015 14:06, LordBlick wrote: Dear LordBlick,
>
> I'm of quite opposite opinion - all scripts of decent quality should be
> available in some official repository (whether it will be separate from the
> main Kicad repo is a different discussion) and possibly packaged with the
> releases of Kicad.
>
> Separate repository seems more sensible. My OS packaging environment (RPM)
> spends 23 minutes to build every release (without docs and libs) and that
> amount
> of time still grows. Every element, which can stand alone, should have
> separate
> repo as was done with docs and libs.
>
> Build time is painful, but I believe it's something which shouldn’t stop
> us from
> adding new functionalities, otherwise we should stop development now ;-)
>
>
> A stable and simple API for scripting, that is independent of the pcbnew's
> internal storage model is a big step in that direction. To me the
> discussion
> if: Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10,
> 10) is a waste of time, because I don't see any of these forms making
> script
> development significantly more difficult.
>
> That's my appointment too, but possibly haven't found proprietary words…
> Some of ways comes from Python language specific forms.
>
> Ok, let’s not spend more time on that part. :)
>
>
> @Miguel: PS - What do you think about adding a GAL canvas object to the
> scripting API? It could be useful for footprint/import wizards or other PCB
> feature generators as a preview window, embedded in a GUI form.
>
> It will be great to control fast drawing area from external script. Today
> I use
> cairo/gtk to my scribbles.
>
> Yes, I totally missed that when using scripting, if you could give me an
> example
> of how to instantiate the GAL canvas from a standalone simple wxpython
> application, that should give me an  idea on what do we need to provide
> from the C++ API layer.
>
>
> I've had in mind a Pythonish SVG graphic importer (see attachment), adding
> a
> simple OSHW logo to a Kicad PCB project is quite painful now...
>
> Curiously, I'm doing svg import work in python with additional ability to
> simple
> edit points position.
> Screenshot contains yet unfinished UI editor. I have some ideas, eg. a
> choice to
> import (DrawPolygon footprint or other draws - arcs, circles segments,
>

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

First of all, let me first clarify, we’re discussing two things at the same 
time:

[people scripts (2, 2.1, 2.2)] —> [kicad-python-api(1)i] —> [C++ swigged-API]

   
1) Building an API to access the kicad objects in a way that is not  
tightly coupled to the KiCad internals, and that it’s for consumption from  
python scripts. This API is to be written in python.

I believe this API should live in the kicad repository, even if we iterate
first on a separate one. This way, when breaking changes happen in the C++
implementation (interface change, object change, etc..) the API layer
can be updated to work with the new C++ interface.


2) Having scripts people build on python to provide specific functions.  
This could live on a separate repo without risk, since the API contract  
should not change (unless somehow deprecated). If something becomes
really useful for the wide community, of course, it can always be packaged
together with KiCad.  

2.1) At some point, we could even make a repository available via github,
 the same way we do for footprints.

2.2) I also find interesting another kind of special functions, not to run 
standalone
from kicad, but to run inside kicad:

a) Contextual menu hooks: scripts that can hook certain contextual menus,
to provide functions, so users can plug those special functions into 
kicad.

b) Tool bar hooks: To install functions in the toolbar.

c) I/O plugins: To write I/O plugins in plain python.


I’m replying between lines too->  

On Friday, 16 de January de 2015 at 15:25, LordBlick wrote:

> In response to a message written on 16.01.2015, 14:35, from Tomasz Wlostowski:
> > On 16.01.2015 14:06, LordBlick wrote: Dear LordBlick,
> >  
> > I'm of quite opposite opinion - all scripts of decent quality should be
> > available in some official repository (whether it will be separate from the
> > main Kicad repo is a different discussion) and possibly packaged with the
> > releases of Kicad.
> >  
>  
> Separate repository seems more sensible. My OS packaging environment (RPM)
> spends 23 minutes to build every release (without docs and libs) and that 
> amount
> of time still grows. Every element, which can stand alone, should have 
> separate
> repo as was done with docs and libs.
>  
>  

Build time is painful, but I believe it's something which shouldn’t stop us 
from  
adding new functionalities, otherwise we should stop development now ;-)
> >  
> > A stable and simple API for scripting, that is independent of the pcbnew's
> > internal storage model is a big step in that direction. To me the discussion
> > if: Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10,
> > 10) is a waste of time, because I don't see any of these forms making script
> > development significantly more difficult.
>  
> That's my appointment too, but possibly haven't found proprietary words…
> Some of ways comes from Python language specific forms.
>  

Ok, let’s not spend more time on that part. :)
  
> > @Miguel: PS - What do you think about adding a GAL canvas object to the
> > scripting API? It could be useful for footprint/import wizards or other PCB
> > feature generators as a preview window, embedded in a GUI form.
> >  
>  
> It will be great to control fast drawing area from external script. Today I 
> use
> cairo/gtk to my scribbles.
>  

Yes, I totally missed that when using scripting, if you could give me an 
example  
of how to instantiate the GAL canvas from a standalone simple wxpython  
application, that should give me an  idea on what do we need to provide  
from the C++ API layer.
  
> > I've had in mind a Pythonish SVG graphic importer (see attachment), adding a
> > simple OSHW logo to a Kicad PCB project is quite painful now...
> >  
>  
> Curiously, I'm doing svg import work in python with additional ability to 
> simple
> edit points position.
> Screenshot contains yet unfinished UI editor. I have some ideas, eg. a choice 
> to
> import (DrawPolygon footprint or other draws - arcs, circles segments, zone on
> board or draw elements on board etc ...)
>  


Nice!  
>  
> --  
> Best Regards,
> LordBlick
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Wayne Stambaugh]

Why don't we start with a Python repo on Launchpad or GitHub.  I'll
leave that decision to the Python developers.  This way the Python
developers can share ideas and contribute their Python expertise.  Once
a script reaches some level of usefulness and maturity, the script can
then be submitted for inclusion in the KiCad source.  What do you think?
 Is there anyone out there who would like to volunteer to lead such an
effort?

On 01/16/2015 08:35 AM, Tomasz Wlostowski wrote:
> On 16.01.2015 14:06, LordBlick wrote:
>> In response to a message written on 16.01.2015, 13:26, from Miguel Ángel
>> Ajo:
>>> In my opinion it’s not a waste of time.
>>>
>>> A decent API will lead to more standardized scripts, and the
>>> people ability to share and look at other’s work.
>>>
>> All right, IMHO this could itself be provided at that condition if is
>> not used, there will not be silently consume system resources.
>> Only lest it was made out of such API layer of additional layer of
>> additional layer… Yo dawg!
>> If we want to brag about own scripts, it is possible to create any forum
>> or page to share scripts, no need for this fancy API.
>> Personally, I cured myself from thinking that my script should be
>> attached to the giant, which becomes the KiCad repository.
> 
> Dear LordBlick,
> 
> I'm of quite opposite opinion - all scripts of decent quality should be
> available in some official repository (whether it will be separate from
> the main Kicad repo is a different discussion) and possibly packaged
> with the releases of Kicad.
> 
> A stable and simple API for scripting, that is independent of the
> pcbnew's internal storage model is a big step in that direction. To me
> the discussion if:
> Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10,
> 10) is a waste of time, because I don't see any of these forms making
> script development significantly more difficult.
> 
> Cheers,
> Tom
> 
> @Miguel: PS - What do you think about adding a GAL canvas object to the
> scripting API? It could be useful for footprint/import wizards or other
> PCB feature generators as a preview window, embedded in a GUI form. I've
> had in mind a Pythonish SVG graphic importer (see attachment), adding a
> simple OSHW logo to a Kicad PCB project is quite painful now...
> 
> 
> 
> ___
> 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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Tomasz Wlostowski]

On 16.01.2015 14:06, LordBlick wrote:
> In response to a message written on 16.01.2015, 13:26, from Miguel Ángel
> Ajo:
>> In my opinion it’s not a waste of time.
>>
>> A decent API will lead to more standardized scripts, and the
>> people ability to share and look at other’s work.
>>
> All right, IMHO this could itself be provided at that condition if is
> not used, there will not be silently consume system resources.
> Only lest it was made out of such API layer of additional layer of
> additional layer… Yo dawg!
> If we want to brag about own scripts, it is possible to create any forum
> or page to share scripts, no need for this fancy API.
> Personally, I cured myself from thinking that my script should be
> attached to the giant, which becomes the KiCad repository.

Dear LordBlick,

I'm of quite opposite opinion - all scripts of decent quality should be
available in some official repository (whether it will be separate from
the main Kicad repo is a different discussion) and possibly packaged
with the releases of Kicad.

A stable and simple API for scripting, that is independent of the
pcbnew's internal storage model is a big step in that direction. To me
the discussion if:
Point(10, 10, Units=MM) is better than Point.mm(10, 10) or point_mm(10,
10) is a waste of time, because I don't see any of these forms making
script development significantly more difficult.

Cheers,
Tom

@Miguel: PS - What do you think about adding a GAL canvas object to the
scripting API? It could be useful for footprint/import wizards or other
PCB feature generators as a preview window, embedded in a GUI form. I've
had in mind a Pythonish SVG graphic importer (see attachment), adding a
simple OSHW logo to a Kicad PCB project is quite painful now...

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 16.01.2015, 13:26, from Miguel Ángel Ajo:

In my opinion it’s not a waste of time.

A decent API will lead to more standardized scripts, and the
people ability to share and look at other’s work.

All right, IMHO this could itself be provided at that condition if is not used, 
there will not be silently consume system resources.
Only lest it was made out of such API layer of additional layer of additional 
layer… Yo dawg!
If we want to brag about own scripts, it is possible to create any forum or page 
to share scripts, no need for this fancy API.
Personally, I cured myself from thinking that my script should be attached to 
the giant, which becomes the KiCad repository. Usually, any amendment affects a 
small portion of the software, and you have to rebuild the whole, to get the 
current package.

--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

In my opinion it’s not a waste of time.

A decent API will lead to more standardized scripts, and the
people ability to share and look at other’s work.

Cheers,
Miguel Ángel.


Miguel Ángel Ajo


On Friday, 16 de January de 2015 at 13:24, LordBlick wrote:

> In response to a message written on 16.01.2015, 13:09, from Miguel Ángel Ajo:
> > I’m also trying to think if there is any way to handle it within a context,
> >  
> > with Units(MM):
> > point = Point(10,10)
> >  
>  
> I think that any similar constructions debate are waste of time. If somebody  
> wants to create some sensible script, then she/he will made own way to ensure 
>  
> using correct units…
> There is not only right way, there are a number of possible solutions.
> --  
> Best Regards,
> LordBlick
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 16.01.2015, 13:09, from Miguel Ángel Ajo:

I’m also trying to think if there is any way to handle it within a context,

 with Units(MM):
 point = Point(10,10)
I think that any similar constructions debate are waste of time. If somebody 
wants to create some sensible script, then she/he will made own way to ensure 
using correct units…

There is not only right way, there are a number of possible solutions.
--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

Hi Brian,

 I see your point, but the problem with that is interoperability, for example
if we mix up modules which work with pcbnew, they could change units,
and mix them all up.

   I have proposed on the ether pad to do something like:

   Point.mm(10, 10), which would, under the hood do:

class Point:
def __init__(x, y, unit):
   …

@staticmethod
 def mm(x,y):
  return Point(x, y, unit=MM)


how does it sound?


I’m also trying to think if there is any way to handle it within a context,

with Units(MM):  
point = Point(10,10)

But I haven’t found how to push the context and make it available to Point..  

Miguel Ángel Ajo


On Friday, 16 de January de 2015 at 11:03, Brian Sidebotham wrote:

> On 15 January 2015 at 10:20, Miguel Ángel Ajo  (mailto:majop...@redhat.com)> wrote:
> > Yesterday I wrote a proposal for discussion here:
> >  
> > http://pads.kicad-pcb.org/p/kicad-scripting-layer (please write your name
> > for your color
> > using the top right icon, so what you write can be identified to you).
> >  
> > I tried not to look too much into the original Piers proposal,
> > to do a true top-down design (“how do I like to interact with kicad
> > objects?”)
> >  
> > In the end, it looks quite much like Piers proposal, just with the
> > difference
> > of Point/Size objects receiving the unit.
> >  
> > I was trying to be as pythonic as possible avoiding set_/get_ methods,
> > and instead rely on attributes and implicit setters/getters.
> >  
> > The listed options are not exclusive, just different ways of doing the same.
> >  
> > Please feel free to write about other use cases, or copy, paste, then modify
> > my blocks
> > to provide different possible interactions.
> >  
> > Best,
> > Miguel Ángel.
> >  
> > Miguel Ángel Ajo
>  
> Hi Miguel,
>  
> I thought I'd add my thoughts here instead of changing what others have done.
>  
> I see that someone doesn't like the Point( 10, 10, unit=MM ) paradime
> for creating a 2D vector.
>  
> Personally, I prefer that construct compared to the proposed point_mm(
> 10, 10 ) by quite a long way.
>  
> But, it's of course a pain to always use unit=MM. Generally we know
> the units we're going to work with when we start with pcbnew scripting
> so it would be good to be able to do something like
> pcbnew.default_units = MM somewhere near the start of the script and
> then all 2D vectors can be created without the unit=MM additional
> argument, such as: Point( 10, 10 ) instead.
>  
> That would make a nicer interface in my opinion. I only had a chance
> to have a quick look at it. Thanks for getting something together for
> people to look at.
>  
> Best Regards,
>  
> Brian.
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Brian Sidebotham]

On 15 January 2015 at 10:20, Miguel Ángel Ajo  wrote:
> Yesterday I wrote a proposal for discussion here:
>
> http://pads.kicad-pcb.org/p/kicad-scripting-layer  (please write your name
> for your color
> using the top right icon, so what you write can be identified to you).
>
> I tried not to look too much into the original Piers proposal,
> to do a true top-down design (“how do I like to interact with kicad
> objects?”)
>
> In the end, it looks quite much like Piers proposal, just with the
> difference
> of Point/Size objects receiving the unit.
>
> I was trying to be as pythonic as possible avoiding set_/get_ methods,
> and instead rely on attributes and implicit setters/getters.
>
> The listed options are not exclusive, just different ways of doing the same.
>
> Please feel free to write about other use cases, or copy, paste, then modify
> my blocks
> to provide different possible interactions.
>
> Best,
> Miguel Ángel.
>
> Miguel Ángel Ajo

Hi Miguel,

I thought I'd add my thoughts here instead of changing what others have done.

I see that someone doesn't like the Point( 10, 10, unit=MM ) paradime
for creating a 2D vector.

Personally, I prefer that construct compared to the proposed point_mm(
10, 10 ) by quite a long way.

But, it's of course a pain to always use unit=MM. Generally we know
the units we're going to work with when we start with pcbnew scripting
so it would be good to be able to do something like
pcbnew.default_units = MM somewhere near the start of the script and
then all 2D vectors can be created without the unit=MM additional
argument, such as: Point( 10, 10 ) instead.

That would make a nicer interface in my opinion. I only had a chance
to have a quick look at it. Thanks for getting something together for
people to look at.

Best Regards,

Brian.

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

Yesterday I wrote a proposal for discussion here:

http://pads.kicad-pcb.org/p/kicad-scripting-layer  (please write your name for 
your color
using the top right icon, so what you write can be identified to you).

I tried not to look too much into the original Piers proposal,
to do a true top-down design (“how do I like to interact with kicad objects?”)

In the end, it looks quite much like Piers proposal, just with the difference
of Point/Size objects receiving the unit.  

I was trying to be as pythonic as possible avoiding set_/get_ methods,
and instead rely on attributes and implicit setters/getters.

The listed options are not exclusive, just different ways of doing the same.

Please feel free to write about other use cases, or copy, paste, then modify my 
blocks
to provide different possible interactions.

Best,
Miguel Ángel.


Miguel Ángel Ajo


On Thursday, 15 de January de 2015 at 01:32, LordBlick wrote:

> In response to a message written on 07.01.2015, 19:29, from Adam Wolf:
> > I dunno, LordBlick, it looks pretty Pythonic to me!
> >  
> > Also, I do not think
> >  
> > dict(map(lambda lname: lname, layers_tuple.index(lname), layers_tuple))
> >  
> > is clearer than using a dictionary called layer_dict :)
> Auto-generated functions below are always up to date, layers names and number 
> in
> KiCAD still evaluates, so we can not rely on ordinary static, an independent
> dictionary.
>  
> lsLayers = tuple([(idl, pcbnew.BOARD_GetStandardLayerName(idl)) for idl in  
> range(pcbnew.LAYER_ID_COUNT)])
> layerName2ID = lambda txtLayer: dict(map(reversed, lsLayers)).get(txtLayer)
> layerID2Name = lambda layerID: dict(lsLayers).get(layerID)
>  
> 3 lines concluding bilateral conversion vs. 24 lines of dictionary only…
> Thank you for your attention! :)
>  
> --  
> Best Regards,
> LordBlick
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 07.01.2015, 19:29, from Adam Wolf:

I dunno, LordBlick, it looks pretty Pythonic to me!

Also, I do not think

  dict(map(lambda lname: lname, layers_tuple.index(lname), layers_tuple))

is clearer than using a dictionary called layer_dict :)

Auto-generated functions below are always up to date, layers names and number in
KiCAD still evaluates, so we can not rely on ordinary static, an independent
dictionary.

lsLayers = tuple([(idl, pcbnew.BOARD_GetStandardLayerName(idl)) for idl in 
range(pcbnew.LAYER_ID_COUNT)])

layerName2ID = lambda txtLayer: dict(map(reversed, lsLayers)).get(txtLayer)
layerID2Name = lambda layerID: dict(lsLayers).get(layerID)

3 lines concluding bilateral conversion vs. 24 lines of dictionary only…
Thank you for your attention! :)

--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Brian Sidebotham]

On 7 January 2015 at 10:36, PTT  wrote:
> Dear all,
> First of all thanks for all the good work, I recently switched to KiCAD
> because of the added scripting support which I needed for scripted button
> placement on a pcb.
>
> To make it easier to get my work done I made some convenience functions and
> classes wrapping the swig api to have a cleaner interface.
>
> Please have a look and see if it is useful to somehow incorporate it in the
> main branch.
>
> pcbnew_easy.py
> https://gist.github.com/pierstitus/7be2d9923da502c88ff1
>
> There is a simple usage example, to run put the file on your path, (or add
> the path with sys.path.append("...path_to_file..."))
> open the pcbnew console and enter
 import pcbnew_easy
 pcbnew_easy.test()
> (the screen is only updating on moving)
>
> Piers
>

Hi Piers,

Certainly, the python interface we expose should be much more pythonic, I agree!

It will help us to have an abstraction layer too between the python
API and the internal C++ structures and API. Changing the C++ API
shouldn't require all scripts to be re-written, unless we move KiCad's
internals to an official API. I'd rather the API definition be defined
by a secondary python module that sits atop the KiCad internals which
can be more fluid.

I think we could do with some people more familiar than me with python
to take this on in a public repo somewhere and collaborate on it to
make a more python interface. Forward internal data change requests
and requests for exposure of more internals to the KiCad development
list (this one), or send patches to the swig interface files.

We could also have a more python interface by have much more advances
swig interface files, that's also an avenue someone could investigate,
but I find the SWIG interface file language quite awful.

Whatever route we take to make the scripting more pythonic, it'll need
multiple developers to be able to support it alongside the C++
development.

Thank-you for broaching the subject and providing some code, it's
really interesting to see. It looks like there's some good interest in
it.

These are just my views of course! :-D

Best Regards,

Brian.

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[PTT]

On Wed, Jan 7, 2015 at 11:35 PM, Miguel Ángel Ajo 
wrote:

> Whoops :-), %s/LordBlick/PTT/g
>
> Miguel Ángel Ajo
>
> On Wednesday, 7 de January de 2015 at 23:31, LordBlick wrote:
>
> In response to a message written on 07.01.2015, 23:07, from Miguel Ángel
> Ajo:
>
> Hi Lordblick, sorry, I was on a run before, and I actually didn’t look
> into your code, but stepped into tabs vs spaces (thinking it was a
> discussion
> about in-KiCad code).
>
> Your python extra layer is very nice, actually, at the start I was very
> reluctant
> on adding another layer and reusing the C++ interface as much as possible,
> and, even if that’s cheaper, it has a lot of disadvantages:
>
> 1) Resulting code is not very pythonic, and hard to read.
>
> 2) If C++ implementation changes, the available python scripts break.
>
> 3) The auto generated documentation is poor, if we had a python mid-layer,
> we could have very nice documentation rendered by sphinx or any equivalent
> pythonic solution.
>
> I must say, that it sounds like an interesting step, and quite motivating,
> if other people wanted to join forces on this, and discuss about what would
> be an ideal interface (your implementation seems like a very nice start
> point
> to start discusion), I’d love to spend some time on it and re-join forces
> back
> to KiCad development.
>
> Regardless that I'm different person than PTT, I think that some of most
> useful
> code pieces (in example LayerSet with modified by me get_layer()) could be
> included in swig staff…
>
> --
> Best Regards,
> LordBlick
>
>
> Good to see the discussion getting on. Indeed this is just a starting
point, not a completely thought through API :)
Thanks for the suggestions, it's updated again.
Putting it on the path would be good enough, so it can be loaded without
hassle. But including parts in the swig layer is good too.

One thing I like to add is a redraw screen function, but I couldn't find
it, anyone knows? (now you have to move the canvas to see the changes)

regards,
Piers
___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Maciej Sumiński]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

>> That is exactly what I was trying to say with my 2nd point :) and
>> I believe it’s something very valuable.

Sorry, I misread your statement. Now, all I can do is to admit that I
share your view ;)

Regards,
Orson
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUrbVxAAoJEBRwGu1hpbJ1HRMH/35GPF9GNYFuONiPfCrxJLzQ
B2yjAZoP+8lK8BTlanXzxrw+PL5xgXKG/C5k8MJ0ruEKXvXZVVD6GyqiKgmbuwFu
71b6t2wRT+fHDHBEwK291nY729nwN1JHgsqwVUmITxCKhv9PptdxbiJvuVe6nG6d
DZR7mVbO8uB3Y+UuOWGdo+3PpqZ4gAhNSVzMfUZV8LcRtA5XQ6CM7pCBTMTfWlUZ
luD1SQsz8x/pfCxzaVPMmjoDF1gIOQpoSAPYuJ/MBMigmGc8dkYrqfT6c43C4zF0
x/gzwO+EVRTeLldwcCFPD1tnQB1VenmuEBH5mIih66Ro2Tpz08T1WQzwRGylxS8=
=jxc6
-END PGP SIGNATURE-

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

Whoops :-), %s/LordBlick/PTT/g

Miguel Ángel Ajo


On Wednesday, 7 de January de 2015 at 23:31, LordBlick wrote:

> In response to a message written on 07.01.2015, 23:07, from Miguel Ángel Ajo:
> > Hi Lordblick, sorry, I was on a run before, and I actually didn’t look
> > into your code, but stepped into tabs vs spaces (thinking it was a 
> > discussion
> > about in-KiCad code).
> >  
> > Your python extra layer is very nice, actually, at the start I was very 
> > reluctant
> > on adding another layer and reusing the C++ interface as much as possible,
> > and, even if that’s cheaper, it has a lot of disadvantages:
> >  
> > 1) Resulting code is not very pythonic, and hard to read.
> >  
> > 2) If C++ implementation changes, the available python scripts break.
> >  
> > 3) The auto generated documentation is poor, if we had a python mid-layer,
> > we could have very nice documentation rendered by sphinx or any equivalent
> > pythonic solution.
> >  
> > I must say, that it sounds like an interesting step, and quite motivating,
> > if other people wanted to join forces on this, and discuss about what would
> > be an ideal interface (your implementation seems like a very nice start 
> > point
> > to start discusion), I’d love to spend some time on it and re-join forces 
> > back
> > to KiCad development.
> >  
>  
> Regardless that I'm different person than PTT, I think that some of most 
> useful  
> code pieces (in example LayerSet with modified by me get_layer()) could be  
> included in swig staff…
>  
> --  
> Best Regards,
> LordBlick
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

Miguel Ángel Ajo


On Wednesday, 7 de January de 2015 at 23:32, Maciej Sumiński wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>  
> Hi Miguel,
>  
> On 01/07/2015 11:07 PM, Miguel Ángel Ajo wrote:
> [snip]
> > 2) If C++ implementation changes, the available python scripts
> > break.
> >  
>  
>  
> There might be another point that could be taken under consideration.
> Currently, if the C++ implementation changes, every script that relies
> on the implementation will fail. With an additional layer of
> abstraction, all we need to fix are the internals of the provided API.
>  
>  

That is exactly what I was trying to say with my 2nd point :)
and I believe it’s something very valuable.
  
>  
> Regards,
> Orson
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>  
> iQEcBAEBCAAGBQJUrbQNAAoJEBRwGu1hpbJ1SmoH/0sSLjqIP4AHPLRUbxrlf6hU
> hb4CH0l87mPYIThiiD1wxSulmsZXIpd8jHwX0nyRV/x+Osd2+PtEcNWmDXHVCXX2
> k7tYQPojpYJavCGx2vwQpgApqy3THZ/O3vkh2NqJ6KKgEo+RZhXq+jaRDoA2g8Mt
> r72Ox+rjdw/bsaHlfcW2vegJ9C400GLw2j7TDQCkDizyZVUiZEtzRGcLJTwRWdAW
> /oO9XLJ/fzCwO1BHa7eWsTeDR4yY1sA6y/DG2Mtw3VYjNkDJExaHM/bEH01VZNMW
> mxqvwHOKt/X+QkaLvqTQ64R666H9WKjnYzE28Hl2CA1prFm7I45f6hT7KldHuYM=
> =/1JO
> -END PGP SIGNATURE-
>  
>  


___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Maciej Sumiński]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Miguel,

On 01/07/2015 11:07 PM, Miguel Ángel Ajo wrote:
[snip]
> 2) If C++ implementation changes, the available python scripts
> break.

There might be another point that could be taken under consideration.
Currently, if the C++ implementation changes, every script that relies
on the implementation will fail. With an additional layer of
abstraction, all we need to fix are the internals of the provided API.

Regards,
Orson
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUrbQNAAoJEBRwGu1hpbJ1SmoH/0sSLjqIP4AHPLRUbxrlf6hU
hb4CH0l87mPYIThiiD1wxSulmsZXIpd8jHwX0nyRV/x+Osd2+PtEcNWmDXHVCXX2
k7tYQPojpYJavCGx2vwQpgApqy3THZ/O3vkh2NqJ6KKgEo+RZhXq+jaRDoA2g8Mt
r72Ox+rjdw/bsaHlfcW2vegJ9C400GLw2j7TDQCkDizyZVUiZEtzRGcLJTwRWdAW
/oO9XLJ/fzCwO1BHa7eWsTeDR4yY1sA6y/DG2Mtw3VYjNkDJExaHM/bEH01VZNMW
mxqvwHOKt/X+QkaLvqTQ64R666H9WKjnYzE28Hl2CA1prFm7I45f6hT7KldHuYM=
=/1JO
-END PGP SIGNATURE-

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 07.01.2015, 23:07, from Miguel Ángel Ajo:

Hi Lordblick, sorry, I was on a run before, and I actually didn’t look
into your code, but stepped into tabs vs spaces (thinking it was a discussion
about in-KiCad code).

Your python extra layer is very nice, actually, at the start I was very 
reluctant
on adding another layer and reusing the C++ interface as much as possible,
and, even if that’s cheaper, it has a lot of disadvantages:

1) Resulting code is not very pythonic, and hard to read.

2) If C++ implementation changes, the available python scripts break.

3) The auto generated documentation is poor, if we had a python mid-layer,
  we could have very nice documentation rendered by sphinx or any equivalent
  pythonic solution.

I must say, that it sounds like an interesting step, and quite motivating,
if other people wanted to join forces on this, and discuss about what would
be an ideal interface (your implementation seems like a very nice start point
to start discusion), I’d love to spend some time on it and re-join forces back
to KiCad development.
Regardless that I'm different person than PTT, I think that some of most useful 
code pieces (in example LayerSet with modified by me get_layer()) could be 
included in swig staff…


--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

Hi Lordblick, sorry, I was on a run before, and I actually didn’t look
into your code, but stepped into tabs vs spaces (thinking it was a discussion
about in-KiCad code).

Your python extra layer is very nice, actually, at the start I was very 
reluctant
on adding another layer and reusing the C++ interface as much as possible,
and, even if that’s cheaper, it has a lot of disadvantages:

1) Resulting code is not very pythonic, and hard to read.

2) If C++ implementation changes, the available python scripts break.

3) The auto generated documentation is poor, if we had a python mid-layer,
 we could have very nice documentation rendered by sphinx or any equivalent
 pythonic solution.

I must say, that it sounds like an interesting step, and quite motivating,
if other people wanted to join forces on this, and discuss about what would
be an ideal interface (your implementation seems like a very nice start point
to start discusion),  I’d love to spend some time on it and re-join forces back
to KiCad development.


Miguel Ángel Ajo


On Wednesday, 7 de January de 2015 at 22:10, LordBlick wrote:

> In response to a message written on 07.01.2015, 21:54, from Wayne Stambaugh:
> > On 1/7/2015 3:44 PM, LordBlick wrote:
> > > In response to a message written on 07.01.2015, 20:48, from Adam Wolf:
> > > > I have to stop responding to this thread, but it's official Python 
> > > > policy
> > > > that spaces are preferred over tabs, and has been for a while.
> > > > https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces
> > > >  
> > >  
> > > OK, I appreciate that, but my heart goes on tabs… :P I leave policies to
> > > politicians. I like the programing mainly because it is one of the few
> > > oases of freedom in modern times. Also freedom of choice of indentation
> > > sign… :P Enforcing „One correct way” is sign of civilization falling.
> > > Diversity is a basic rule of survival.
> > >  
> >  
> >  
> > For your own personal code, the sky's the limit as far as formatting goes.
> > Any code included in the KiCad source must follow the coding policy. I
> > doubt the KiCad coding policy has much influence on the overall health of
> > civilization ;).
> >  
>  
> I do not intend to violate any of the sacred rules of KiCAD congregation, my
> code will be published off-project, and here I'll just kindly inspired you 
> all... ;)
> --  
> Best Regards,
> LordBlick
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 07.01.2015, 21:54, from Wayne Stambaugh:

On 1/7/2015 3:44 PM, LordBlick wrote:

In response to a message written on 07.01.2015, 20:48, from Adam Wolf:

I have to stop responding to this thread, but it's official Python policy
that spaces are preferred over tabs, and has been for a while.
https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

OK, I appreciate that, but my heart goes on tabs… :P I leave policies to
politicians. I like the programing mainly because it is one of the few
oases of freedom in modern times. Also freedom of choice of indentation
sign… :P Enforcing „One correct way” is sign of civilization falling.
Diversity is a basic rule of survival.


For your own personal code, the sky's the limit as far as formatting goes.
Any code included in the KiCad source must follow the coding policy.  I
doubt the KiCad coding policy has much influence on the overall health of
civilization ;).

I do not intend to violate any of the sacred rules of KiCAD congregation, my
code will be published off-project, and here I'll just kindly inspired you 
all... ;)
--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 07.01.2015, 21:45, from Miguel Ángel Ajo:

PEP8 strongly recommends spaces: (I was about to link the same Adam did).

The reasoning is tabs is that change width from editor to editor or from
configuration to configuration. Spaces are always the same.

If programmer leaves information about tab-spaces in some comments at begin of
file, that will not be to messy. It will be nice, if someone from Python dev
team will include to language syntax(as was done with coding/encoding):
„# -*- tabstop:  -*-”


Python syntax heavily relies on indenting for blocks, and that can result in
problems if people starts mixing spaces or tabs.

At least mixing spaces and tabs should be totally avoided.

My  inclination is to use spaces. I do that with those settings in vimdc:

set tabstop=4 set shiftwidth=4 set expandtab

My tabstop is 4 spaces too… ;)


But I’m not writing too much in KiCad lately, so.. my opinion is not very
important here. The only thing I believe super important is not to mix.

So I use space only as text spaces, nor indentation…


--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Wayne Stambaugh]

On 1/7/2015 3:44 PM, LordBlick wrote:
> In response to a message written on 07.01.2015, 20:48, from Adam Wolf:
>> I have to stop responding to this thread, but it's official Python policy
>> that spaces are preferred over tabs, and has been for a while.
>> https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces
> OK, I appreciate that, but my heart goes on tabs… :P I leave policies to
> politicians. I like the programing mainly because it is one of the few
> oases of
> freedom in modern times. Also freedom of choice of indentation sign… :P
> Enforcing „One correct way” is sign of civilization falling. Diversity is a
> basic rule of survival.

For your own personal code, the sky's the limit as far as formatting
goes.  Any code included in the KiCad source must follow the coding
policy.  I doubt the KiCad coding policy has much influence on the
overall health of civilization ;).

>>
>> In other news, is anyone else from the KiCad community going to Pycon
>> this
>> year?
> IMHO, flying to USA for foreigner is to costly and complicated(TSA etc…)
> than
> visiting profits… ;)
> 


___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Miguel Ángel Ajo]

PEP8 strongly recommends spaces:
(I was about to link the same Adam did).

The reasoning is tabs is that change width from editor to editor
or from configuration to configuration. Spaces are always the same.

Python syntax heavily relies on indenting for blocks, and that can result
in problems if people starts mixing spaces or tabs.

At least mixing spaces and tabs should be totally avoided.  

My  inclination is to use spaces. I do that with those settings in vimdc:

set tabstop=4
set shiftwidth=4
set expandtab


But I’m not writing too much in KiCad lately, so.. my opinion is not  
very important here. The only thing I believe super important is not to mix.

Best regards,
Miguel Ángel.


Miguel Ángel Ajo


On Wednesday, 7 de January de 2015 at 21:44, LordBlick wrote:

> In response to a message written on 07.01.2015, 20:48, from Adam Wolf:
> > I have to stop responding to this thread, but it's official Python policy
> > that spaces are preferred over tabs, and has been for a while.
> > https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces
> >  
>  
> OK, I appreciate that, but my heart goes on tabs… :P I leave policies to
> politicians. I like the programing mainly because it is one of the few oases 
> of
> freedom in modern times. Also freedom of choice of indentation sign… :P
> Enforcing „One correct way” is sign of civilization falling. Diversity is a
> basic rule of survival.
> >  
> > In other news, is anyone else from the KiCad community going to Pycon this
> > year?
> >  
>  
> IMHO, flying to USA for foreigner is to costly and complicated(TSA etc…) than
> visiting profits… ;)
>  
> --  
> Best Regards,
> LordBlick
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto: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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 07.01.2015, 20:48, from Adam Wolf:

I have to stop responding to this thread, but it's official Python policy
that spaces are preferred over tabs, and has been for a while.
https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

OK, I appreciate that, but my heart goes on tabs… :P I leave policies to
politicians. I like the programing mainly because it is one of the few oases of
freedom in modern times. Also freedom of choice of indentation sign… :P
Enforcing „One correct way” is sign of civilization falling. Diversity is a
basic rule of survival.


In other news, is anyone else from the KiCad community going to Pycon this
year?

IMHO, flying to USA for foreigner is to costly and complicated(TSA etc…) than
visiting profits… ;)

--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Adam Wolf]

I have to stop responding to this thread, but it's official Python policy
that spaces are preferred over tabs, and has been for a while.

https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

In other news, is anyone else from the KiCad community going to Pycon this
year?

Adam Wolf
Cofounder and Engineer
W&L

On Wed, Jan 7, 2015 at 1:45 PM, LordBlick  wrote:

> In response to a message written on 07.01.2015, 19:29, from Adam Wolf:
>
>> Hi folks,
>>
>> Good work!
>>
>> I dunno, LordBlick, it looks pretty Pythonic to me!
>>
>> Also, I do not think
>>
>>   dict(map(lambda lname: lname, layers_tuple.index(lname), layers_tuple))
>>
>> is clearer than using a dictionary called layer_dict :)
>>
> Some tip: count chars… :P
> This dictionary is not necessary for this code since it is used only for
> the one function. Code below makes the same without dict:
> def get_layer(s):
> "Get layer id from layer name\n If it is already an int just
> return it."
> if hasattr(pcbnew, s):
> return getattr(pcbnew, s)
> elif isinstance(s, int) \
> and(s in range(pcbnew.LAYER_ID_COUNT):
> return s
> return None
>
> BTW. I love Tabs in python code, which syntax is based on Tab counting and
> I don't intend to change that… Setting tab length is not so advanced and
> hard activity.
>
> --
> Best Regards,
> LordBlick
>
> ___
> 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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 07.01.2015, 19:29, from Adam Wolf:

Hi folks,

Good work!

I dunno, LordBlick, it looks pretty Pythonic to me!

Also, I do not think

  dict(map(lambda lname: lname, layers_tuple.index(lname), layers_tuple))

is clearer than using a dictionary called layer_dict :)

Some tip: count chars… :P
This dictionary is not necessary for this code since it is used only for the one 
function. Code below makes the same without dict:

def get_layer(s):
"Get layer id from layer name\n If it is already an int just return it."
if hasattr(pcbnew, s):
return getattr(pcbnew, s)
elif isinstance(s, int) \
and(s in range(pcbnew.LAYER_ID_COUNT):
return s
return None

BTW. I love Tabs in python code, which syntax is based on Tab counting and I 
don't intend to change that… Setting tab length is not so advanced and hard 
activity.

--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Adam Wolf]

Hi folks,

Good work!

I dunno, LordBlick, it looks pretty Pythonic to me!

Also, I do not think

 dict(map(lambda lname: lname, layers_tuple.index(lname), layers_tuple))

is clearer than using a dictionary called layer_dict :)

Adam Wolf
Cofounder and Engineer
W&L


On Wed, Jan 7, 2015 at 12:25 PM, LordBlick  wrote:

> In response to a message written on 07.01.2015, 11:36, from PTT:
>
>> Please have a look and see if it is useful to somehow incorporate it in
>>> the main
>>>
>> branch.
>>
>> pcbnew_easy.py
>> https://gist.github.com/pierstitus/7be2d9923da502c88ff1
>>
> Very good work for adding it to pcbnew/scripting/examples/, but it will
> not let anything be loaded by default. Each developer has their own habits
> and not everything looks like a purely written code in my eyes. Much of
> coding is to tune up some project than writing down some script, which will
> be creating tracks or vias. Well, unless someone recode freerouter to
> python ...;)
>
> BTW. Some advice to make better world ;) :
> - via.SetLayerPair(layer_pair[0], layer_pair[1]) looks better as
> via.SetLayerPair(*layer_pair)
> - „def mm” is bad - there are two methods in pcbnew - FromMM and ToMM,
> both useful…
> - layer_dict is not comfortable way - as layers are defined as int, better
> and easier done it will put these string names by correct order in tuple.
> Any dict (if really needed) can be created dynamically from tuple by
> function:
>  dict(map(lambda lname: lname, layers_tuple.index(lname), layers_tuple))
> Alternative for tuple is getattr(pcbnew, lname):
> >>> getattr(pcbnew, 'F_Cu')
> 0
> >>> getattr(pcbnew, 'In1_Cu')
> 1
> I wish you many wins with python battles… ;)
> --
> Best Regards,
> LordBlick
>
>
> ___
> 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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[LordBlick]

In response to a message written on 07.01.2015, 11:36, from PTT:

Please have a look and see if it is useful to somehow incorporate it in the main

branch.

pcbnew_easy.py
https://gist.github.com/pierstitus/7be2d9923da502c88ff1
Very good work for adding it to pcbnew/scripting/examples/, but it will not let 
anything be loaded by default. Each developer has their own habits and not 
everything looks like a purely written code in my eyes. Much of coding is to 
tune up some project than writing down some script, which will be creating 
tracks or vias. Well, unless someone recode freerouter to python ...;)


BTW. Some advice to make better world ;) :
- via.SetLayerPair(layer_pair[0], layer_pair[1]) looks better as 
via.SetLayerPair(*layer_pair)

- „def mm” is bad - there are two methods in pcbnew - FromMM and ToMM, both 
useful…
- layer_dict is not comfortable way - as layers are defined as int, better and 
easier done it will put these string names by correct order in tuple. Any dict 
(if really needed) can be created dynamically from tuple by function:

 dict(map(lambda lname: lname, layers_tuple.index(lname), layers_tuple))
Alternative for tuple is getattr(pcbnew, lname):
>>> getattr(pcbnew, 'F_Cu')
0
>>> getattr(pcbnew, 'In1_Cu')
1
I wish you many wins with python battles… ;)
--
Best Regards,
LordBlick

___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Paulo Henrique Silva]

PTT,

I am looking to add plot support. It is something I use often.

What do you think of add this project to an external repository to let
people contribute and when you release "stable/good" version we ask KiCad
folks to integrate those releases.

Cheers,

2015-01-07 16:42 GMT-02:00 PTT :

> I do intend to update and improve the parts that I use, though that won't
> cover all use cases so I hope other people will extend it too.
>
> Thanks for the remarks about formatting, I totally agree, that's updated
> now.
>
> On Wed, Jan 7, 2015 at 3:08 PM, Wayne Stambaugh 
> wrote:
>
>> On 1/7/2015 8:33 AM, Tomasz Wlostowski wrote:
>> > On 07.01.2015 11:36, PTT wrote:
>> >> Dear all,
>> >> First of all thanks for all the good work, I recently switched to KiCAD
>> >> because of the added scripting support which I needed for scripted
>> button
>> >> placement on a pcb.
>> >>
>> >
>> > Hi Piers,
>> >
>> > Very nice work, thanks! IMHO C++ APIs SWIGgged directly to python are
>> > rather big and inelegant and such a wrapper makes writing scripts much
>> > easier!
>> >
>> > Are you intending to continue working on your wrapper? I vote for
>> > including it in future Kicad releases along with some examples. Miguel,
>> > Wayne - would you agree?
>>
>> I think it's a good idea for developers who don't want to wade into all
>> of the swigged objects.  If Piers (or someone else) intends to maintain
>> it then we can add it as part of the python scripting installation.  If
>> not, then we can add it to the pcbnew/scripting/examples folder for user
>> convenience.
>>
>> If I do add it the formatting issues will have to be addressed.  Tabs
>> are forbidden in all KiCad source code so you have to convert them to 4
>> spaces.  The trailing white space will also have to be cleaned up.
>> Although not strictly enforce, it is preferred that line lengths be
>> limited to 100 characters.  I also see some formatting inconsistencies
>> in functions with multiple arguments.  Some times there is a space after
>> the comma and sometimes there isn't so that should be addressed as well.
>>
>> Thanks,
>>
>> Wayne
>>
>> >
>> > Cheers,
>> > Tom
>> >
>> >
>> >
>> >> To make it easier to get my work done I made some convenience
>> functions and
>> >> classes wrapping the swig api to have a cleaner interface.
>> >>
>> >> Please have a look and see if it is useful to somehow incorporate it
>> in the
>> >> main branch.
>> >>
>> >> pcbnew_easy.py
>> >> https://gist.github.com/pierstitus/7be2d9923da502c88ff1
>> >>
>> >> There is a simple usage example, to run put the file on your path, (or
>> add
>> >> the path with sys.path.append("...path_to_file..."))
>> >> open the pcbnew console and enter
>> > import pcbnew_easy
>> > pcbnew_easy.test()
>> >> (the screen is only updating on moving)
>> >>
>> >> Piers
>> >>
>> >>
>> >>
>> >> ___
>> >> 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
>> >
>>
>>
>> ___
>> 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
>
>
___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[PTT]

I do intend to update and improve the parts that I use, though that won't
cover all use cases so I hope other people will extend it too.

Thanks for the remarks about formatting, I totally agree, that's updated
now.

On Wed, Jan 7, 2015 at 3:08 PM, Wayne Stambaugh 
wrote:

> On 1/7/2015 8:33 AM, Tomasz Wlostowski wrote:
> > On 07.01.2015 11:36, PTT wrote:
> >> Dear all,
> >> First of all thanks for all the good work, I recently switched to KiCAD
> >> because of the added scripting support which I needed for scripted
> button
> >> placement on a pcb.
> >>
> >
> > Hi Piers,
> >
> > Very nice work, thanks! IMHO C++ APIs SWIGgged directly to python are
> > rather big and inelegant and such a wrapper makes writing scripts much
> > easier!
> >
> > Are you intending to continue working on your wrapper? I vote for
> > including it in future Kicad releases along with some examples. Miguel,
> > Wayne - would you agree?
>
> I think it's a good idea for developers who don't want to wade into all
> of the swigged objects.  If Piers (or someone else) intends to maintain
> it then we can add it as part of the python scripting installation.  If
> not, then we can add it to the pcbnew/scripting/examples folder for user
> convenience.
>
> If I do add it the formatting issues will have to be addressed.  Tabs
> are forbidden in all KiCad source code so you have to convert them to 4
> spaces.  The trailing white space will also have to be cleaned up.
> Although not strictly enforce, it is preferred that line lengths be
> limited to 100 characters.  I also see some formatting inconsistencies
> in functions with multiple arguments.  Some times there is a space after
> the comma and sometimes there isn't so that should be addressed as well.
>
> Thanks,
>
> Wayne
>
> >
> > Cheers,
> > Tom
> >
> >
> >
> >> To make it easier to get my work done I made some convenience functions
> and
> >> classes wrapping the swig api to have a cleaner interface.
> >>
> >> Please have a look and see if it is useful to somehow incorporate it in
> the
> >> main branch.
> >>
> >> pcbnew_easy.py
> >> https://gist.github.com/pierstitus/7be2d9923da502c88ff1
> >>
> >> There is a simple usage example, to run put the file on your path, (or
> add
> >> the path with sys.path.append("...path_to_file..."))
> >> open the pcbnew console and enter
> > import pcbnew_easy
> > pcbnew_easy.test()
> >> (the screen is only updating on moving)
> >>
> >> Piers
> >>
> >>
> >>
> >> ___
> >> 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
> >
>
>
> ___
> 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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Wayne Stambaugh]

On 1/7/2015 8:33 AM, Tomasz Wlostowski wrote:
> On 07.01.2015 11:36, PTT wrote:
>> Dear all,
>> First of all thanks for all the good work, I recently switched to KiCAD
>> because of the added scripting support which I needed for scripted button
>> placement on a pcb.
>>
> 
> Hi Piers,
> 
> Very nice work, thanks! IMHO C++ APIs SWIGgged directly to python are
> rather big and inelegant and such a wrapper makes writing scripts much
> easier!
> 
> Are you intending to continue working on your wrapper? I vote for
> including it in future Kicad releases along with some examples. Miguel,
> Wayne - would you agree?

I think it's a good idea for developers who don't want to wade into all
of the swigged objects.  If Piers (or someone else) intends to maintain
it then we can add it as part of the python scripting installation.  If
not, then we can add it to the pcbnew/scripting/examples folder for user
convenience.

If I do add it the formatting issues will have to be addressed.  Tabs
are forbidden in all KiCad source code so you have to convert them to 4
spaces.  The trailing white space will also have to be cleaned up.
Although not strictly enforce, it is preferred that line lengths be
limited to 100 characters.  I also see some formatting inconsistencies
in functions with multiple arguments.  Some times there is a space after
the comma and sometimes there isn't so that should be addressed as well.

Thanks,

Wayne

> 
> Cheers,
> Tom
> 
> 
> 
>> To make it easier to get my work done I made some convenience functions and
>> classes wrapping the swig api to have a cleaner interface.
>>
>> Please have a look and see if it is useful to somehow incorporate it in the
>> main branch.
>>
>> pcbnew_easy.py
>> https://gist.github.com/pierstitus/7be2d9923da502c88ff1
>>
>> There is a simple usage example, to run put the file on your path, (or add
>> the path with sys.path.append("...path_to_file..."))
>> open the pcbnew console and enter
> import pcbnew_easy
> pcbnew_easy.test()
>> (the screen is only updating on moving)
>>
>> Piers
>>
>>
>>
>> ___
>> 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
> 


___
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

Re: [Kicad-developers] more pythonic scripting API for pcbnew

[Tomasz Wlostowski]

On 07.01.2015 11:36, PTT wrote:
> Dear all,
> First of all thanks for all the good work, I recently switched to KiCAD
> because of the added scripting support which I needed for scripted button
> placement on a pcb.
> 

Hi Piers,

Very nice work, thanks! IMHO C++ APIs SWIGgged directly to python are
rather big and inelegant and such a wrapper makes writing scripts much
easier!

Are you intending to continue working on your wrapper? I vote for
including it in future Kicad releases along with some examples. Miguel,
Wayne - would you agree?

Cheers,
Tom



> To make it easier to get my work done I made some convenience functions and
> classes wrapping the swig api to have a cleaner interface.
> 
> Please have a look and see if it is useful to somehow incorporate it in the
> main branch.
> 
> pcbnew_easy.py
> https://gist.github.com/pierstitus/7be2d9923da502c88ff1
> 
> There is a simple usage example, to run put the file on your path, (or add
> the path with sys.path.append("...path_to_file..."))
> open the pcbnew console and enter
 import pcbnew_easy
 pcbnew_easy.test()
> (the screen is only updating on moving)
> 
> Piers
> 
> 
> 
> ___
> 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