Re: [Kicad-developers] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

I'm adding an example bellow:


2012/5/6 Miguel Angel Ajo Pelayo 

>
>
> 2012/5/6 Dick Hollenbeck 
>
>
>>  >  2) even if I could use them now, the wxpython  wouldn't play well
>> with our swig wx
>> > wrapped classes (as they
>> >  consider each other different objects types) -I have plans to
>> make that work,
>> > but it's not a priority right now-
>>
>>
>> What would this entail?  Having access to some wxPython headers at KiCad
>> build time?  What?
>>
>
> At least, wxpython ".i" files should be available to swig.   (
> http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/src/ ),
> but probably that's being just too optimistic, probably we should be
> needing also the exact same wx headers that
> where used when building our system installed "wxPython" (but that's just
> a guess...)
>
> Also wxPython crew, seem to be using some kind of swig patches, (at least
> they did for swig 1.3.x) , which won't be
> available on a stock swig. (
> http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/SWIG/)
>
>
>> Is the the difficulty easy to explain?
>>
>> The problem now is that our wxPoint (for example) is different from
> wx.Point for python, because,
> at the time swig is building our wrappers doesn't have access to wx ".i"
> wrapper definitions.
>
> To avoid those two dependencies, I built some basic wrappers to wxPoint,
> wxRect, wxString, wxArrayString,
> and some others. And it's a solution right now, but I'd really want to
> make them compatible to the native wxPython
> wrappers that you can import with "import wx" in Python.
>
> So, there is some level of wxPython <-> wx C++ interoperability which I'm
> not sure it could be obtained (with a reasonable
> amount of work).
>
>

I think an example is easier to see the problem of our internal wx objects
with the "import wx" objects of wxPython

ajo@vaio:~/work/kicad.scripting/pcbnew$ python
Python 2.7.3 (default, Apr 20 2012, 22:44:07)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> import pcbnew
>>> wx_rect = wx.Rect(1,2,3,4)
>>> pcb_rect = pcbnew.wxRect(1,2,3,4)

>>> wx_rect.GetX()
1

>>> pcb_rect.GetX()
1

# at this point, wx_rect and pcb_rect have the same interfaces, but
# are considered different object types by python, which is normal
# as wx and pcbnew are different modules, and they even have different
# names "Rect"=/="wxRect"

# but, let's try to make a trick and exchange
# their internal pointers to the "wxRect *" real object: (which I expected
it could be
# a solution at some point...)

>>> wx_rect.this


>>> pcb_rect.this


>>> wx_rect.this = pcb_rect.this

# it doesn't work:

>>> wx_rect.GetX()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
line 1150, in GetX
return _core_.Rect_GetX(*args, **kwargs)
TypeError: in method 'Rect_GetX', expected argument 1 of type 'wxRect const
*'

# I suppose swig gives an internal ID to every object it wraps, ...



>
>
>> >
>> >
>> >
>> > This gives you an option to use any standard python graphics API,
>> more autonomy.  Maybe
>> > you want to explore Torsten's GAL under python.
>> >
>> >
>> > I initially discarded that way, because using my own drawing strategy
>> would require a
>> > lot of maintenance, much
>> > more time (in fact *a lot*) and probably the drawing result's would be
>> poor compared to
>> > KiCad drawing functions.
>> >
>> >  So I decided to go into adding the little wizard to the module editor
>> inside pcbnew
>> > (which shouldn't be more
>> > than the c++ wrapper to the python wizards, and the interface file,
>> that's all).
>> >
>> >  I think I'm also highly motivated to that because I strongly
>> believe that KiCad
>> > being scriptable *also* from inside
>> > will be as powerful as the "plugin" from python or even more, and it
>> was my initial
>> > motivation to start scripting.
>> >
>> >
>> > There are some more degrees of freedom to consider.   I personally
>> would want to build a
>> > gem before I got too caught up in integrating it into Pcbnew,
>> >
>> >
>> > You mean cleaning all the classes inside pcbnew, etc..., right?  Well,
>> I think that this
>> > is concern for both cases:
>> >
>> > 1) Python "pcbnew" plugin
>> > 2) KiCad "inside" python scripting
>> >
>> > Because, as we change important classes and methods inside KiCad, the
>> scripts people
>> > write could get broken (as the
>> > classes and methods -we want- are swigged out as we write them in C++),
>> I'm even adding
>> > little abstraction
>> > layers for some parts, with I find more sensitive, but that wouldn't be
>> enough for big
>> > changes.
>> >
>> > So probably we must be releasing 1+2 when we feel comfortable enough
>> with our internal
>> > class design, but not too late,
>> > perfection is expensive.
>> >
>> > doing a tighter integration later is also a reasonable path,
>> tighter than clipboard
>> > support.  Later you cou

Re: [Kicad-developers] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

2012/5/6 Dick Hollenbeck 


> >  2) even if I could use them now, the wxpython  wouldn't play well
> with our swig wx
> > wrapped classes (as they
> >  consider each other different objects types) -I have plans to
> make that work,
> > but it's not a priority right now-
>
>
> What would this entail?  Having access to some wxPython headers at KiCad
> build time?  What?
>

At least, wxpython ".i" files should be available to swig.   (
http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/src/ ),
but probably that's being just too optimistic, probably we should be
needing also the exact same wx headers that
where used when building our system installed "wxPython" (but that's just a
guess...)

Also wxPython crew, seem to be using some kind of swig patches, (at least
they did for swig 1.3.x) , which won't be
available on a stock swig. (
http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/SWIG/)


> Is the the difficulty easy to explain?
>
> The problem now is that our wxPoint (for example) is different from
wx.Point for python, because,
at the time swig is building our wrappers doesn't have access to wx ".i"
wrapper definitions.

To avoid those two dependencies, I built some basic wrappers to wxPoint,
wxRect, wxString, wxArrayString,
and some others. And it's a solution right now, but I'd really want to make
them compatible to the native wxPython
wrappers that you can import with "import wx" in Python.

So, there is some level of wxPython <-> wx C++ interoperability which I'm
not sure it could be obtained (with a reasonable
amount of work).



> >
> >
> >
> > This gives you an option to use any standard python graphics API,
> more autonomy.  Maybe
> > you want to explore Torsten's GAL under python.
> >
> >
> > I initially discarded that way, because using my own drawing strategy
> would require a
> > lot of maintenance, much
> > more time (in fact *a lot*) and probably the drawing result's would be
> poor compared to
> > KiCad drawing functions.
> >
> >  So I decided to go into adding the little wizard to the module editor
> inside pcbnew
> > (which shouldn't be more
> > than the c++ wrapper to the python wizards, and the interface file,
> that's all).
> >
> >  I think I'm also highly motivated to that because I strongly
> believe that KiCad
> > being scriptable *also* from inside
> > will be as powerful as the "plugin" from python or even more, and it was
> my initial
> > motivation to start scripting.
> >
> >
> > There are some more degrees of freedom to consider.   I personally
> would want to build a
> > gem before I got too caught up in integrating it into Pcbnew,
> >
> >
> > You mean cleaning all the classes inside pcbnew, etc..., right?  Well, I
> think that this
> > is concern for both cases:
> >
> > 1) Python "pcbnew" plugin
> > 2) KiCad "inside" python scripting
> >
> > Because, as we change important classes and methods inside KiCad, the
> scripts people
> > write could get broken (as the
> > classes and methods -we want- are swigged out as we write them in C++),
> I'm even adding
> > little abstraction
> > layers for some parts, with I find more sensitive, but that wouldn't be
> enough for big
> > changes.
> >
> > So probably we must be releasing 1+2 when we feel comfortable enough
> with our internal
> > class design, but not too late,
> > perfection is expensive.
> >
> > doing a tighter integration later is also a reasonable path, tighter
> than clipboard
> > support.  Later you could return a
> > MODULE which replaces the one in the module editor, and is called
> from the module
> > editor.
> >
> >
> > Yes, that was my exact idea, and right now it's almost done, I only need
> to build the
> > interface dialog.
> >
> > I thought it as a good start for the inside scripting architecture,
> because it had
> > little coupling to all the design,
> > (so the problems wouldn't be big...) and a good way to start learning
> how to build a
> > scripting architecture that
> > could extend KiCad from inside.
> >
> > The hard part of this architecture would be adding extended user
> interaction from
> > inside, but this is something I still
> > don't find myself ready to do, I must pass the "footprint wizard" (or
> any other)
> > training first. :-)
> >
> >
> > I will think a little more about how could I rip it out of pcbnew module
> editor, but...
> > I'm yet not sure about how to do
> > it taking a reasonable time.
> >
> > In the other hand, If you finally find ok with the wizards and scripting
> inside
> > pcbnew/module editor I promise to keep it up
> > to date with the testing branch changes as they happen. The most
> problematic part of
> > this is the Python2x.dll dependency
> > in windows / mac, where I might need some help.
> >
> >
> >
> > >
> >
> > >
> > >
> > > 2012/5/5 Dick Hollenbeck  d...@softplc.com>
> > >>
> > >
> > > On 05/05/2012 08:55 AM, Miguel Angel Ajo Pelayo wrote:

Re: [Kicad-developers] Kicad scripting progress :-)

[Dick Hollenbeck]

On 05/06/2012 04:17 AM, Miguel Angel Ajo Pelayo wrote:
>
>
> 2012/5/6 Dick Hollenbeck mailto:d...@softplc.com>>
>
> On 05/05/2012 03:32 PM, Miguel Angel Ajo Pelayo wrote:
> > I'm going further, my plan is not only to make PLUGIN accesible from 
> python, that's the
> > first stone,
> > and a good one.
> >
>
> Shortly after PCB_IO starts to firm up, it should be pretty easy to teach 
> the module
> editor to pull an entire module off the clipboard, i.e. paste module.  It 
> is one of the
> cleanest uses of clipboard support that I can foresee right now.
>
> So this gives you an option to work fully external to Pcbnew, using your 
> own graphics
> strategy, and then when done simply pass the MODULE back to PCBNEW via 
> clipboard.  It
> requires that the user paste the module, but it is only a click or two if 
> it comes
> with an
> implied "replace current module with clipboard contents" paradigm.  
>
>  
> The clipboard plan sounds good, in fact I like it, 
>
> Or you could simply write the new module into a footprint library.
>
>
> That's easy to do, but I'd miss drawing/preview, 
>
>
> My initial plan was to write it as a standalone python app, but I found caged 
> when
> trying to use the current
> drawing functionality, as:
>  1) we don't plan to include it in the future "pcbnew" module when the 
> Draw
> functions are completely separate/refactored.

The "data model" code could be one DLL/DSO.  This is basically what you have in 
class
PLUGIN, along with the ability to then actually "access" the objects you get 
back in a
BOARD or MODULE.  No graphics, as you say.  This is one of a number of building 
blocks
that would be nice to have.  Maybe we can get a class PAINTER type of interface 
into
another building block (perhaps or perhaps not another DLL/DSO).

Then there is the BOARD_ACTIONS that we talked about, which are IU-less 
procedural actions
that operate on a BOARD, and maybe MODULE.


>  2) even if I could use them now, the wxpython  wouldn't play well with 
> our swig wx
> wrapped classes (as they 
>  consider each other different objects types) -I have plans to make 
> that work,
> but it's not a priority right now-


What would this entail?  Having access to some wxPython headers at KiCad build 
time?  What?

Is the the difficulty easy to explain?


> 
>
>
> This gives you an option to use any standard python graphics API, more 
> autonomy.  Maybe
> you want to explore Torsten's GAL under python.
>
>
> I initially discarded that way, because using my own drawing strategy would 
> require a
> lot of maintenance, much
> more time (in fact *a lot*) and probably the drawing result's would be poor 
> compared to
> KiCad drawing functions.
>
>  So I decided to go into adding the little wizard to the module editor inside 
> pcbnew
> (which shouldn't be more
> than the c++ wrapper to the python wizards, and the interface file, that's 
> all). 
>
>  I think I'm also highly motivated to that because I strongly believe 
> that KiCad
> being scriptable *also* from inside
> will be as powerful as the "plugin" from python or even more, and it was my 
> initial
> motivation to start scripting.
>  
>
> There are some more degrees of freedom to consider.   I personally would 
> want to build a
> gem before I got too caught up in integrating it into Pcbnew, 
>
>
> You mean cleaning all the classes inside pcbnew, etc..., right?  Well, I 
> think that this
> is concern for both cases:
>
> 1) Python "pcbnew" plugin
> 2) KiCad "inside" python scripting
>
> Because, as we change important classes and methods inside KiCad, the scripts 
> people
> write could get broken (as the
> classes and methods -we want- are swigged out as we write them in C++), I'm 
> even adding
> little abstraction
> layers for some parts, with I find more sensitive, but that wouldn't be 
> enough for big
> changes.
>
> So probably we must be releasing 1+2 when we feel comfortable enough with our 
> internal
> class design, but not too late,
> perfection is expensive.
>
> doing a tighter integration later is also a reasonable path, tighter than 
> clipboard
> support.  Later you could return a
> MODULE which replaces the one in the module editor, and is called from 
> the module
> editor.
>
>
> Yes, that was my exact idea, and right now it's almost done, I only need to 
> build the
> interface dialog.
>
> I thought it as a good start for the inside scripting architecture, because 
> it had
> little coupling to all the design,
> (so the problems wouldn't be big...) and a good way to start learning how to 
> build a
> scripting architecture that 
> could extend KiCad from inside.
>
> The hard part of this architecture would be adding extended user interaction 
> from
> inside, but this is something I still
> don't find myself ready to do, I must pass the "footprint wizard" (or any 
> other)
> training first. :-)
>
>
> I will think a 

Re: [Kicad-developers] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

2012/5/6 Dick Hollenbeck 

> On 05/05/2012 03:32 PM, Miguel Angel Ajo Pelayo wrote:
> > I'm going further, my plan is not only to make PLUGIN accesible from
> python, that's the
> > first stone,
> > and a good one.
> >
>
> Shortly after PCB_IO starts to firm up, it should be pretty easy to teach
> the module
> editor to pull an entire module off the clipboard, i.e. paste module.  It
> is one of the
> cleanest uses of clipboard support that I can foresee right now.
>
> So this gives you an option to work fully external to Pcbnew, using your
> own graphics
> strategy, and then when done simply pass the MODULE back to PCBNEW via
> clipboard.  It
> requires that the user paste the module, but it is only a click or two if
> it comes with an
> implied "replace current module with clipboard contents" paradigm.


The clipboard plan sounds good, in fact I like it,

Or you could simply write the new module into a footprint library.
>

That's easy to do, but I'd miss drawing/preview,


My initial plan was to write it as a standalone python app, but I found
caged when trying to use the current
drawing functionality, as:
 1) we don't plan to include it in the future "pcbnew" module when the
Draw functions are completely separate/refactored.
 2) even if I could use them now, the wxpython  wouldn't play well with
our swig wx wrapped classes (as they
 consider each other different objects types) -I have plans to make
that work, but it's not a priority right now-


>
> This gives you an option to use any standard python graphics API, more
> autonomy.  Maybe
> you want to explore Torsten's GAL under python.
>
>
I initially discarded that way, because using my own drawing strategy would
require a lot of maintenance, much
more time (in fact *a lot*) and probably the drawing result's would be poor
compared to KiCad drawing functions.

 So I decided to go into adding the little wizard to the module editor
inside pcbnew (which shouldn't be more
than the c++ wrapper to the python wizards, and the interface file, that's
all).

 I think I'm also highly motivated to that because I strongly believe
that KiCad being scriptable *also* from inside
will be as powerful as the "plugin" from python or even more, and it was my
initial motivation to start scripting.


> There are some more degrees of freedom to consider.   I personally would
> want to build a
> gem before I got too caught up in integrating it into Pcbnew,


You mean cleaning all the classes inside pcbnew, etc..., right?  Well, I
think that this is concern for both cases:

1) Python "pcbnew" plugin
2) KiCad "inside" python scripting

Because, as we change important classes and methods inside KiCad, the
scripts people write could get broken (as the
classes and methods -we want- are swigged out as we write them in C++), I'm
even adding little abstraction
layers for some parts, with I find more sensitive, but that wouldn't be
enough for big changes.

So probably we must be releasing 1+2 when we feel comfortable enough with
our internal class design, but not too late,
perfection is expensive.

doing a tighter integration later is also a reasonable path, tighter than
> clipboard support.  Later you could return a
> MODULE which replaces the one in the module editor, and is called from the
> module editor.
>

Yes, that was my exact idea, and right now it's almost done, I only need to
build the interface dialog.

I thought it as a good start for the inside scripting architecture, because
it had little coupling to all the design,
(so the problems wouldn't be big...) and a good way to start learning how
to build a scripting architecture that
could extend KiCad from inside.

The hard part of this architecture would be adding extended user
interaction from inside, but this is something I still
don't find myself ready to do, I must pass the "footprint wizard" (or any
other) training first. :-)


I will think a little more about how could I rip it out of pcbnew module
editor, but... I'm yet not sure about how to do
it taking a reasonable time.

In the other hand, If you finally find ok with the wizards and scripting
inside pcbnew/module editor I promise to keep it up
to date with the testing branch changes as they happen. The most
problematic part of this is the Python2x.dll dependency
in windows / mac, where I might need some help.



> >

>
> >
> > 2012/5/5 Dick Hollenbeck mailto:d...@softplc.com>>
> >
> > On 05/05/2012 08:55 AM, Miguel Angel Ajo Pelayo wrote:
> > > Thank you too Wayne,
> > >
> > > It's nice to team up with you all :-)
> > >
> > >
> > >   I have a little prototype of the footprint wizards, for which I
> should finish the C++
> > > integration part, I just finished testing the python part.
> >
> >
> > What needs to be done in C++?
> >
> > I thought you already had a bridge from python to PLUGIN done.
> >
> >
> >
> >
> > ___
> > Mailing list: https://launchpa

Re: [Kicad-developers] Kicad scripting progress :-)

[Dick Hollenbeck]

On 05/05/2012 03:32 PM, Miguel Angel Ajo Pelayo wrote:
> I'm going further, my plan is not only to make PLUGIN accesible from python, 
> that's the
> first stone,
> and a good one.
>
> The next part in the plan, is to make pcbnew/eeschema/etc, scriptable itself, 
> and that
> means,
> that the user can put ".py" extensions somewhere, and the pcbnew/eeschema/etc 
> get extended
> with that .py modules functionality.
>
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478
> 
>
> these are the "preliminary" python classes
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#pcbnew/scripting/plugins.i
> 
>
> that have their mirror C++ classes accessible:
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#pcbnew/scripting/pcbnew_footprint_wizards.h
> 
>
>
> and get registered on load by the pcbnew.LoadPlugins()
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#scripting/python_scripting.cpp
> 
>
> This is a first wizard example:
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#pcbnew/scripting/plugins/fpc_footprint_wizard.py
> 
>
>
> and now, I'm working to make a generic interface for the footprint wizards, 
> inside
> pcbnew module editor, 
> it should be interactive, and as we modify any parameter we should see the 
> resulting
> module on the right.


Shortly after PCB_IO starts to firm up, it should be pretty easy to teach the 
module
editor to pull an entire module off the clipboard, i.e. paste module.  It is 
one of the
cleanest uses of clipboard support that I can foresee right now.

So this gives you an option to work fully external to Pcbnew, using your own 
graphics
strategy, and then when done simply pass the MODULE back to PCBNEW via 
clipboard.  It
requires that the user paste the module, but it is only a click or two if it 
comes with an
implied "replace current module with clipboard contents" paradigm.  Or you 
could simply
write the new module into a footprint library.


This gives you an option to use any standard python graphics API, more 
autonomy.  Maybe
you want to explore Torsten's GAL under python. 

There are some more degrees of freedom to consider.   I personally would want 
to build a
gem before I got too caught up in integrating it into Pcbnew, doing a tighter 
integration
later is also a reasonable path, tighter than clipboard support.  Later you 
could return a
MODULE which replaces the one in the module editor, and is called from the 
module editor.


Dick



>
>
>
> 2012/5/5 Dick Hollenbeck mailto:d...@softplc.com>>
>
> On 05/05/2012 08:55 AM, Miguel Angel Ajo Pelayo wrote:
> > Thank you too Wayne,
> >
> > It's nice to team up with you all :-)
> >
> >
> >   I have a little prototype of the footprint wizards, for which I 
> should finish the C++
> > integration part, I just finished testing the python part.
>
>
> What needs to be done in C++?
>
> I thought you already had a bridge from python to PLUGIN done.
>
>
>
>
> ___
> 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
>
>
>
>
> -- 
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo


___
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] Kicad scripting progress :-)

[Wayne Stambaugh]

On 5/5/2012 9:55 AM, Miguel Angel Ajo Pelayo wrote:
> Thank you too Wayne,
> 
> It's nice to team up with you all :-)
> 
> 
>   I have a little prototype of the footprint wizards, for which I should
> finish the C++ integration part, I just finished testing the python part. 
> 
> The parameters they receive are structured in Pages, parameters inside
> the pages, that come with a default value. Every time someone
> changes a value the BuildFootprint() method will be called with the new
> parameters, and we can get the new module via "GetModule()" method.
> 
> A footprint wizard may look like:
> 
> -- fpc_footprint_wizard.py
> 
> 
> from pcbnew import FootprintWizardPlugin
> 
> class FPCFootprintWizard(pcbnew.FootprintWizard):
> def __init__(self):
> FootprintWizardPlugin.__init__(self)
> self.name  = "FPC"
> self.description = "FPC Footprint Wizard"
> self.image=""
> self.parameters = {
>  "Pads":
> {"pad_n":40,"pitch":0.5,"pad_width":0.25,"pad_height":1.6},
>  "Shield":
>
> {"shield_to_pad":1,"top_to_pad":2,"pad_width":2,"pad_height":3}
> }
> def BuildFootprint(self):
> self.module = None
> --
> # w = FPCFootprintWizard() 
> # w.Show()
> 
> for example we may install them system wide in the kicad directory, so
> they are loaded at pcbnew start... or
> at some user directory like ~/.kicad/plugins/
> 
> The parent "FootprintWizardPlugin" class takes care for registering our
> new class into the C++ part, so we can
> can list and use them later on some wx interface.

Very cool!  I can't wait to free up some time and try it out.  I see a
day when KiCad ships with all kinds of useful scripts that experienced
board designers would really appreciate.  I've got a few on my short
list that I would be willing to provide.  Thanks again for your
contributions.

Wayne

> 
> 
> 
> 2012/5/2 Wayne Stambaugh  >
> 
> On 5/2/2012 12:32 PM, Dick Hollenbeck wrote:
> 
> On 05/01/2012 04:35 PM, Miguel Angel Ajo Pelayo wrote:
> 
> 
> 
> 2012/5/1 Dick Hollenbeck <__mailto:d...@softplc.com
> >>
> 
> On 05/01/2012 10:02 AM, Miguel Angel Ajo Pelayo wrote:
> >  We can read and write libraries now with the latest
> extensions to PLUGIN that Dick&
> >  Wayne did :)
> >  now it always use legacy, but they will work with all
> formats. :-)
> >
> >  [...]
> 
> 
> Only 7 lines of code which show how powerful the
> scripting support is becoming.
> 
> Thank you very much Miguel.  I look forward to playing
> with it, some day when I have
> more
> time.
> 
> 
> You're welcome Dick , I think we all are putting a lot of
> effort to make next KiCad's
> release something
> awesome.
> 
> I'm using the new library functionality to make some nice
> little footprint wizard
> examples, and I'm thinking about
> how to build a simple architecture to let people "plug in"
> new footprint wizard scripts.
> 
> 
> 
> Miguel,
> 
> Your enthusiasm for the project has become an important asset of
> the project in and of
> itself.  I personally appreciate all that you do.
> 
> 
> With the introduction of some sensible "software interfaces" we
> are now starting to see
> some benefits.  The original idea for the BOARD plugin framework
> should be credited to Tom
> and Javier of CERN.  From that I was able to actually design
> something workable.  As
> simple as possible, but not simpler.
> 
> Wayne has been faithful to that software API contract, and is in
> the midst of writing one
> of the most important classes ever contributed to KiCad.  We're
> calling it PCB_IO.  This
> class is a normal PLUGIN for our new native s-expression support
> in mm, but has special
> bells and whistles on it for clipboard text generation and
> parsing.  This work is being
> funded by CERN, so we owe them a special thanks.  (Some selling
> took place to get this
> funding, and I will claim some responsibility there.  Selling is
> not foreign to me.)
> 
> 
> On my todo list is an EAGLE plugin.  (My todo list is like a
> personal wish list.  Wishes
> only come true based on available time, energy and mood.)
> 
> 
> No

Re: [Kicad-developers] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

woops, where I said plugins.i I meant:
http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#scripting/kicadplugins.i

sorry :)

2012/5/5 Miguel Angel Ajo Pelayo 

> I'm going further, my plan is not only to make PLUGIN accesible from
> python, that's the first stone,
> and a good one.
>
> The next part in the plan, is to make pcbnew/eeschema/etc, scriptable
> itself, and that means,
> that the user can put ".py" extensions somewhere, and the
> pcbnew/eeschema/etc get extended
> with that .py modules functionality.
>
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478
>
> these are the "preliminary" python classes
>
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#pcbnew/scripting/plugins.i
>
> that have their mirror C++ classes accessible:
>
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#pcbnew/scripting/pcbnew_footprint_wizards.h
>
>
> and get registered on load by the pcbnew.LoadPlugins()
>
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#scripting/python_scripting.cpp
>
> This is a first wizard example:
>
> http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#pcbnew/scripting/plugins/fpc_footprint_wizard.py
>
>
> and now, I'm working to make a generic interface for the footprint
> wizards, inside pcbnew module editor,
> it should be interactive, and as we modify any parameter we should see the
> resulting module on the right.
>
>
>
> 2012/5/5 Dick Hollenbeck 
>
>> On 05/05/2012 08:55 AM, Miguel Angel Ajo Pelayo wrote:
>> > Thank you too Wayne,
>> >
>> > It's nice to team up with you all :-)
>> >
>> >
>> >   I have a little prototype of the footprint wizards, for which I
>> should finish the C++
>> > integration part, I just finished testing the python part.
>>
>>
>> What needs to be done in C++?
>>
>> I thought you already had a bridge from python to PLUGIN done.
>>
>>
>>
>>
>> ___
>> 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
>>
>
>
>
> --
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

I'm going further, my plan is not only to make PLUGIN accesible from
python, that's the first stone,
and a good one.

The next part in the plan, is to make pcbnew/eeschema/etc, scriptable
itself, and that means,
that the user can put ".py" extensions somewhere, and the
pcbnew/eeschema/etc get extended
with that .py modules functionality.

http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478

these are the "preliminary" python classes
http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#pcbnew/scripting/plugins.i

that have their mirror C++ classes accessible:
http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#pcbnew/scripting/pcbnew_footprint_wizards.h


and get registered on load by the pcbnew.LoadPlugins()
http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#scripting/python_scripting.cpp

This is a first wizard example:
http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3478#pcbnew/scripting/plugins/fpc_footprint_wizard.py


and now, I'm working to make a generic interface for the footprint wizards,
inside pcbnew module editor,
it should be interactive, and as we modify any parameter we should see the
resulting module on the right.



2012/5/5 Dick Hollenbeck 

> On 05/05/2012 08:55 AM, Miguel Angel Ajo Pelayo wrote:
> > Thank you too Wayne,
> >
> > It's nice to team up with you all :-)
> >
> >
> >   I have a little prototype of the footprint wizards, for which I should
> finish the C++
> > integration part, I just finished testing the python part.
>
>
> What needs to be done in C++?
>
> I thought you already had a bridge from python to PLUGIN done.
>
>
>
>
> ___
> 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
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Kicad scripting progress :-)

[Dick Hollenbeck]

On 05/05/2012 08:55 AM, Miguel Angel Ajo Pelayo wrote:
> Thank you too Wayne,
>
> It's nice to team up with you all :-)
>
>
>   I have a little prototype of the footprint wizards, for which I should 
> finish the C++
> integration part, I just finished testing the python part.


What needs to be done in C++?  

I thought you already had a bridge from python to PLUGIN done. 




___
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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

Thank you too Wayne,

It's nice to team up with you all :-)


  I have a little prototype of the footprint wizards, for which I should
finish the C++ integration part, I just finished testing the python part.

The parameters they receive are structured in Pages, parameters inside the
pages, that come with a default value. Every time someone
changes a value the BuildFootprint() method will be called with the new
parameters, and we can get the new module via "GetModule()" method.

A footprint wizard may look like:

-- fpc_footprint_wizard.py


from pcbnew import FootprintWizardPlugin

class FPCFootprintWizard(pcbnew.FootprintWizard):
def __init__(self):
FootprintWizardPlugin.__init__(self)
self.name = "FPC"
self.description = "FPC Footprint Wizard"
self.image=""
self.parameters = {
 "Pads":
{"pad_n":40,"pitch":0.5,"pad_width":0.25,"pad_height":1.6},
 "Shield":

{"shield_to_pad":1,"top_to_pad":2,"pad_width":2,"pad_height":3}
}
def BuildFootprint(self):
self.module = None
--
# w = FPCFootprintWizard()
# w.Show()

for example we may install them system wide in the kicad directory, so they
are loaded at pcbnew start... or
at some user directory like ~/.kicad/plugins/

The parent "FootprintWizardPlugin" class takes care for registering our new
class into the C++ part, so we can
can list and use them later on some wx interface.



2012/5/2 Wayne Stambaugh 

> On 5/2/2012 12:32 PM, Dick Hollenbeck wrote:
>
>> On 05/01/2012 04:35 PM, Miguel Angel Ajo Pelayo wrote:
>>
>>>
>>>
>>> 2012/5/1 Dick Hollenbeckmailto:d...@softplc.com>>
>>>
>>> On 05/01/2012 10:02 AM, Miguel Angel Ajo Pelayo wrote:
>>> >  We can read and write libraries now with the latest extensions to
>>> PLUGIN that Dick&
>>> >  Wayne did :)
>>> >  now it always use legacy, but they will work with all formats. :-)
>>> >
>>> >  [...]
>>>
>>>
>>> Only 7 lines of code which show how powerful the scripting support
>>> is becoming.
>>>
>>> Thank you very much Miguel.  I look forward to playing with it, some
>>> day when I have
>>> more
>>> time.
>>>
>>>
>>> You're welcome Dick , I think we all are putting a lot of effort to make
>>> next KiCad's
>>> release something
>>> awesome.
>>>
>>> I'm using the new library functionality to make some nice little
>>> footprint wizard
>>> examples, and I'm thinking about
>>> how to build a simple architecture to let people "plug in" new footprint
>>> wizard scripts.
>>>
>>
>>
>> Miguel,
>>
>> Your enthusiasm for the project has become an important asset of the
>> project in and of
>> itself.  I personally appreciate all that you do.
>>
>>
>> With the introduction of some sensible "software interfaces" we are now
>> starting to see
>> some benefits.  The original idea for the BOARD plugin framework should
>> be credited to Tom
>> and Javier of CERN.  From that I was able to actually design something
>> workable.  As
>> simple as possible, but not simpler.
>>
>> Wayne has been faithful to that software API contract, and is in the
>> midst of writing one
>> of the most important classes ever contributed to KiCad.  We're calling
>> it PCB_IO.  This
>> class is a normal PLUGIN for our new native s-expression support in mm,
>> but has special
>> bells and whistles on it for clipboard text generation and parsing.  This
>> work is being
>> funded by CERN, so we owe them a special thanks.  (Some selling took
>> place to get this
>> funding, and I will claim some responsibility there.  Selling is not
>> foreign to me.)
>>
>>
>> On my todo list is an EAGLE plugin.  (My todo list is like a personal
>> wish list.  Wishes
>> only come true based on available time, energy and mood.)
>>
>>
>> Now imagine that you, Miguel, write a world class footprint wizard, or a
>> framework that
>> lets others do their little twist to it.  Maybe as you say, it is a
>> housing for any number
>> of footprint wizards, each with a particular specialization.  Then, with
>> this design in
>> place, imagine being able to generate eagle footprints or kicad
>> footprints, without any
>> change to your code, or to the code within the wizards.  It is not
>> inconceivable that
>> eagle users will come just to use the footprint wizards.
>>
>>
>> Another benefit of this PLUGIN API design, is that we are positioned to
>> climb to a
>> superset position in both BOARD and in MODULE.  This is because the API
>> is based on those
>> objects, and as we write additional plugins, it is not inconceivable that
>> we may chose to
>> add features to our core C++ objects in order to handle them some other
>> format.  This
>> means we are positioned to assimilate and extend as needed.
>>
>> So yes, there is a hell of a lot going on here.  And there are a

Re: [Kicad-developers] Kicad scripting progress :-)

[Wayne Stambaugh]

On 5/2/2012 12:32 PM, Dick Hollenbeck wrote:

On 05/01/2012 04:35 PM, Miguel Angel Ajo Pelayo wrote:



2012/5/1 Dick Hollenbeckmailto:d...@softplc.com>>

 On 05/01/2012 10:02 AM, Miguel Angel Ajo Pelayo wrote:
 >  We can read and write libraries now with the latest extensions to PLUGIN 
that Dick&
 >  Wayne did :)
 >  now it always use legacy, but they will work with all formats. :-)
 >
 >  [...]


 Only 7 lines of code which show how powerful the scripting support is 
becoming.

 Thank you very much Miguel.  I look forward to playing with it, some day 
when I have
 more
 time.


You're welcome Dick , I think we all are putting a lot of effort to make next 
KiCad's
release something
awesome.

I'm using the new library functionality to make some nice little footprint 
wizard
examples, and I'm thinking about
how to build a simple architecture to let people "plug in" new footprint wizard 
scripts.



Miguel,

Your enthusiasm for the project has become an important asset of the project in 
and of
itself.  I personally appreciate all that you do.


With the introduction of some sensible "software interfaces" we are now 
starting to see
some benefits.  The original idea for the BOARD plugin framework should be 
credited to Tom
and Javier of CERN.  From that I was able to actually design something 
workable.  As
simple as possible, but not simpler.

Wayne has been faithful to that software API contract, and is in the midst of 
writing one
of the most important classes ever contributed to KiCad.  We're calling it 
PCB_IO.  This
class is a normal PLUGIN for our new native s-expression support in mm, but has 
special
bells and whistles on it for clipboard text generation and parsing.  This work 
is being
funded by CERN, so we owe them a special thanks.  (Some selling took place to 
get this
funding, and I will claim some responsibility there.  Selling is not foreign to 
me.)


On my todo list is an EAGLE plugin.  (My todo list is like a personal wish 
list.  Wishes
only come true based on available time, energy and mood.)


Now imagine that you, Miguel, write a world class footprint wizard, or a 
framework that
lets others do their little twist to it.  Maybe as you say, it is a housing for 
any number
of footprint wizards, each with a particular specialization.  Then, with this 
design in
place, imagine being able to generate eagle footprints or kicad footprints, 
without any
change to your code, or to the code within the wizards.  It is not 
inconceivable that
eagle users will come just to use the footprint wizards.


Another benefit of this PLUGIN API design, is that we are positioned to climb 
to a
superset position in both BOARD and in MODULE.  This is because the API is 
based on those
objects, and as we write additional plugins, it is not inconceivable that we 
may chose to
add features to our core C++ objects in order to handle them some other format. 
 This
means we are positioned to assimilate and extend as needed.

So yes, there is a hell of a lot going on here.  And there are a lot of people 
contributing.


It is really great to see so many people stepping up and making great 
contributions to KiCad.  Thank you all for you continued support.


Wayne




Dick



___
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] Kicad scripting progress :-)

[Dick Hollenbeck]

On 05/01/2012 04:35 PM, Miguel Angel Ajo Pelayo wrote:
>
>
> 2012/5/1 Dick Hollenbeck mailto:d...@softplc.com>>
>
> On 05/01/2012 10:02 AM, Miguel Angel Ajo Pelayo wrote:
> > We can read and write libraries now with the latest extensions to 
> PLUGIN that Dick &
> > Wayne did :)
> > now it always use legacy, but they will work with all formats. :-)
> >
> > [...]
>
>
> Only 7 lines of code which show how powerful the scripting support is 
> becoming.
>
> Thank you very much Miguel.  I look forward to playing with it, some day 
> when I have
> more
> time.
>
>
> You're welcome Dick , I think we all are putting a lot of effort to make next 
> KiCad's
> release something
> awesome.
>
> I'm using the new library functionality to make some nice little footprint 
> wizard
> examples, and I'm thinking about
> how to build a simple architecture to let people "plug in" new footprint 
> wizard scripts.


Miguel,

Your enthusiasm for the project has become an important asset of the project in 
and of
itself.  I personally appreciate all that you do.


With the introduction of some sensible "software interfaces" we are now 
starting to see
some benefits.  The original idea for the BOARD plugin framework should be 
credited to Tom
and Javier of CERN.  From that I was able to actually design something 
workable.  As
simple as possible, but not simpler. 

Wayne has been faithful to that software API contract, and is in the midst of 
writing one
of the most important classes ever contributed to KiCad.  We're calling it 
PCB_IO.  This
class is a normal PLUGIN for our new native s-expression support in mm, but has 
special
bells and whistles on it for clipboard text generation and parsing.  This work 
is being
funded by CERN, so we owe them a special thanks.  (Some selling took place to 
get this
funding, and I will claim some responsibility there.  Selling is not foreign to 
me.)


On my todo list is an EAGLE plugin.  (My todo list is like a personal wish 
list.  Wishes
only come true based on available time, energy and mood.)


Now imagine that you, Miguel, write a world class footprint wizard, or a 
framework that
lets others do their little twist to it.  Maybe as you say, it is a housing for 
any number
of footprint wizards, each with a particular specialization.  Then, with this 
design in
place, imagine being able to generate eagle footprints or kicad footprints, 
without any
change to your code, or to the code within the wizards.  It is not 
inconceivable that
eagle users will come just to use the footprint wizards.


Another benefit of this PLUGIN API design, is that we are positioned to climb 
to a
superset position in both BOARD and in MODULE.  This is because the API is 
based on those
objects, and as we write additional plugins, it is not inconceivable that we 
may chose to
add features to our core C++ objects in order to handle them some other format. 
 This
means we are positioned to assimilate and extend as needed.

So yes, there is a hell of a lot going on here.  And there are a lot of people 
contributing.


Dick



___
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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

2012/5/1 Dick Hollenbeck 

> On 05/01/2012 10:02 AM, Miguel Angel Ajo Pelayo wrote:
> > We can read and write libraries now with the latest extensions to PLUGIN
> that Dick &
> > Wayne did :)
> > now it always use legacy, but they will work with all formats. :-)
> >
> > [...]
>
>
> Only 7 lines of code which show how powerful the scripting support is
> becoming.
>
> Thank you very much Miguel.  I look forward to playing with it, some day
> when I have more
> time.
>
>
You're welcome Dick , I think we all are putting a lot of effort to make
next KiCad's release something
awesome.

I'm using the new library functionality to make some nice little footprint
wizard examples, and I'm thinking about
how to build a simple architecture to let people "plug in" new footprint
wizard scripts.

-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Kicad scripting progress :-)

[Dick Hollenbeck]

On 05/01/2012 10:02 AM, Miguel Angel Ajo Pelayo wrote:
> We can read and write libraries now with the latest extensions to PLUGIN that 
> Dick &
> Wayne did :)
> now it always use legacy, but they will work with all formats. :-)
>
> from pcbnew import *
> lst = FootprintEnumerate("/usr/share/kicad/modules/sockets.mod")
> for name in lst:
> m = FootprintLoad("/usr/share/kicad/modules/sockets.mod",name)
> print name,"->",m.GetLibRef(), m.GetReference()
> for p in m.GetPads():
> print "\t",p.GetPadName(),p.GetPosition(), p.GetOffset()


Only 7 lines of code which show how powerful the scripting support is becoming.

Thank you very much Miguel.  I look forward to playing with it, some day when I 
have more
time.



Dick



___
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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

We can read and write libraries now with the latest extensions to PLUGIN
that Dick & Wayne did :)
now it always use legacy, but they will work with all formats. :-)

from pcbnew import *
lst = FootprintEnumerate("/usr/share/kicad/modules/sockets.mod")
for name in lst:
m = FootprintLoad("/usr/share/kicad/modules/sockets.mod",name)
print name,"->",m.GetLibRef(), m.GetReference()
for p in m.GetPads():
print "\t",p.GetPadName(),p.GetPosition(), p.GetOffset()
---

20TEX-ELL300 -> 20TEX-ELL300 U***
1 (19500, 57000) (0, 0)
2 (20500, 57000) (0, 0)
3 (21500, 57000) (0, 0)
4 (22500, 57000) (0, 0)
5 (23500, 57000) (0, 0)
6 (24500, 57000) (0, 0)
7 (25500, 57000) (0, 0)
8 (26500, 57000) (0, 0)
9 (27500, 57000) (0, 0)
10 (28500, 57000) (0, 0)
11 (28500, 54000) (0, 0)
12 (27500, 54000) (0, 0)
13 (26500, 54000) (0, 0)
14 (25500, 54000) (0, 0)
15 (24500, 54000) (0, 0)
16 (23500, 54000) (0, 0)
17 (22500, 54000) (0, 0)
18 (21500, 54000) (0, 0)
19 (20500, 54000) (0, 0)
20 (19500, 54000) (0, 0)
HOLE (18500, 51500) (0, 0)
HOLE (27500, 59500) (0, 0)
20TEX300 -> 20TEX300 U***
1 (19500, 57000) (0, 0)
2 (20500, 57000) (0, 0)
3 (21500, 57000) (0, 0)
4 (22500, 57000) (0, 0)
5 (23500, 57000) (0, 0)
6 (24500, 57000) (0, 0)
7 (25500, 57000) (0, 0)
8 (26500, 57000) (0, 0)
9 (27500, 57000) (0, 0)
10 (28500, 57000) (0, 0)
11 (28500, 54000) (0, 0)
12 (27500, 54000) (0, 0)
13 (26500, 54000) (0, 0)
14 (25500, 54000) (0, 0)
15 (24500, 54000) (0, 0)
16 (23500, 54000) (0, 0)
17 (22500, 54000) (0, 0)
18 (21500, 54000) (0, 0)
19 (20500, 54000) (0, 0)
20 (19500, 54000) (0, 0)
HOLE (18500, 51500) (0, 0)
...
...
...


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

Oh, I forgot, if it's useful to anybody, this are the parameters I used for
building it:

mkdir -p build.scripting && cd build.scripting

cmake ../kicad.scripting -DKICAD_STABLE_VERSION=ON -DCMAKE_BUILD_TYPE=Debug
\
   -DUSE_PCBNEW_SEXPR_FILE_FORMAT=ON -DUSE_PCBNEW_NANOMETRES=ON \
   -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON \
   -DCMAKE_INSTALL_PREFIX=/usr
make


2012/4/14 Miguel Angel Ajo Pelayo 

> Hi everybody, I merged the scripting branch with the latest development
> changes.
> Now it saves to the new kicad_pcb format, and also reads/writes legacy :-)
>
> Lajos, about the python2 thing, it seems that in my computer there wasn't
> any "python2",
> just "python" or "python2.7", so probably I'll have to make some script
> that discovers
> which python2 flavor is available and just us it, until then, "ln
> /usr/bin/python2.7 /usr/bin/python2"
> is recommended (python2.6 must work too)
>
>
>
>
> 2012/4/9 Miguel Angel Ajo Pelayo 
>
>>
>>
>>
>> 2012/4/9 lajos kamocsay 
>>
>>> Miguel-
>>>
>>>
>>> This is truly awesome!
>>>
>>
>> It's the swig magic + some help ':D thanks a lot!
>>
>>>
>>> I finally got your repo to build with the attached patch (to revno
>>> 3467). Maybe these changes work for you, too?
>>>
>>
>> Niiice, thanks for the patch, I will apply it right now.
>>
>>>
>>>  - had to specify python2 in a handful of .py files and in pcbnew's
>>> cmakelist (I have both python2 and 3)
>>>
>>
>>  makes sense :-)
>>
>>  - added rt to the linker flags (is this because of testing build?)
>>>
>> About the rt, not sure why is it needed, I suppose it's some Python
>> dependency
>> on your computer. We must leave it added by now.
>>
>>  - moved up Python.h in dialog_scripting.cpp, as there were some
>>> define conflicts
>>>
>>
>>
>> I think that fixes some warnings on my side :-)
>>
>>
>>> Do you plan on upgrading to python3 at some point? I can help with
>>> that if you need an extra hand.
>>>
>>
>>
>> About Python3, I expect it not to be hard to do at some point. I choose
>> to stay 2.x
>> because wxPython still doesn't have 3.0 support. I think that at that
>> point we could
>> tune the sources to compile for Python3 and python2 as they want to do.
>>
>>
>>
>>>
>>> I haven't had a chance to look at the available functions yet, but I'm
>>> hoping that now I can change a bunch of pad and drill sizes on a board
>>> automatically ;)
>>>
>>> in pcbnew/scripting/examples you have a couple of them, still very basic,
>> but you can already open a board, iterate over modules/pads/items, and
>> modify them
>> and save the pcb back.
>>
>>
>>>
>>> Thanks-
>>> -lajos
>>>
>>> Thank you Lajos :-)
>>
>>>
>>>
>>> On Sat, Apr 7, 2012 at 1:44 PM, Wayne Stambaugh 
>>> wrote:
>>> > On 4/7/2012 12:08 PM, Miguel Angel Ajo Pelayo wrote:
>>> >>
>>> >> During the last two days I had some hours to spend on scripting
>>> >> again, I've been able
>>> >> to fix some memory management problems (objects added to a board or
>>> >> module get deleted
>>> >> by board/module object, but python tried to delete them too, now that
>>> >> condition is detected
>>> >> and avoided  - .thisown=0 in python during (board/module).Add(object)
>>> >> did the work-.
>>> >>
>>> >> Now we have wxRect and wxSize wrappers, that were missing.
>>> >>
>>> >>
>>> >> I find some important points that I must address (prioritized
>>> list):
>>> >>
>>> >>  a) May be working in the KICAD_PLUGIN part for component
>>> libraries,
>>> >> to move the librairi.cpp
>>> >> code into plugin system.  There's already some design about that?
>>>  [I'm
>>> >> writing a separate email about this]
>>> >>
>>> >> This is very very interesting: we cleanup kicad's code (as
>>> it's
>>> >> planned), and would offer many
>>> >> benefits: ability to create footprint wizards, making automated
>>> >> component servers/libraries, etc...
>>> >>
>>> >>  b) I should start documenting somewhere how to work with
>>> scripting.
>>> >> Where's
>>> >> the right place? http://kicad.sourceforge.net/wiki/Main_Page ? , or
>>> may
>>> >> be other place?
>>> >
>>> > Miguel,
>>> >
>>> > If this document is only interesting to developers, it may make sense
>>> to
>>> > put is somewhere in the source repo in the Documentation folder.  If
>>> > this is something that end users may be interested then the appropriate
>>> > place would be the user documentation at
>>> > https://code.launchpad.net/~kicad-developers/kicad/doc.  This is where
>>> > the file format documentation currently lives.  Either way, the
>>> document
>>> > would be under version control which is a good thing.
>>> >
>>> > Wayne
>>> >
>>> >>
>>> >>
>>> >>   c) Hook points for scripting inside kicad UI:
>>> >> c.1) Dynamic toolbar + hotkey assignment for registered
>>> plugins
>>> >> c.2) Footprint wizards list, where plugins could be
>>> registered.
>>> >> c.3) Contextual menu plugins (they could registered, and
>>> >> when you right click on some object, the

Re: [Kicad-developers] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

Hi everybody, I merged the scripting branch with the latest development
changes.
Now it saves to the new kicad_pcb format, and also reads/writes legacy :-)

Lajos, about the python2 thing, it seems that in my computer there wasn't
any "python2",
just "python" or "python2.7", so probably I'll have to make some script
that discovers
which python2 flavor is available and just us it, until then, "ln
/usr/bin/python2.7 /usr/bin/python2"
is recommended (python2.6 must work too)




2012/4/9 Miguel Angel Ajo Pelayo 

>
>
>
> 2012/4/9 lajos kamocsay 
>
>> Miguel-
>>
>>
>> This is truly awesome!
>>
>
> It's the swig magic + some help ':D thanks a lot!
>
>>
>> I finally got your repo to build with the attached patch (to revno
>> 3467). Maybe these changes work for you, too?
>>
>
> Niiice, thanks for the patch, I will apply it right now.
>
>>
>>  - had to specify python2 in a handful of .py files and in pcbnew's
>> cmakelist (I have both python2 and 3)
>>
>
>  makes sense :-)
>
>  - added rt to the linker flags (is this because of testing build?)
>>
> About the rt, not sure why is it needed, I suppose it's some Python
> dependency
> on your computer. We must leave it added by now.
>
>  - moved up Python.h in dialog_scripting.cpp, as there were some
>> define conflicts
>>
>
>
> I think that fixes some warnings on my side :-)
>
>
>> Do you plan on upgrading to python3 at some point? I can help with
>> that if you need an extra hand.
>>
>
>
> About Python3, I expect it not to be hard to do at some point. I choose to
> stay 2.x
> because wxPython still doesn't have 3.0 support. I think that at that
> point we could
> tune the sources to compile for Python3 and python2 as they want to do.
>
>
>
>>
>> I haven't had a chance to look at the available functions yet, but I'm
>> hoping that now I can change a bunch of pad and drill sizes on a board
>> automatically ;)
>>
>> in pcbnew/scripting/examples you have a couple of them, still very basic,
> but you can already open a board, iterate over modules/pads/items, and
> modify them
> and save the pcb back.
>
>
>>
>> Thanks-
>> -lajos
>>
>> Thank you Lajos :-)
>
>>
>>
>> On Sat, Apr 7, 2012 at 1:44 PM, Wayne Stambaugh 
>> wrote:
>> > On 4/7/2012 12:08 PM, Miguel Angel Ajo Pelayo wrote:
>> >>
>> >> During the last two days I had some hours to spend on scripting
>> >> again, I've been able
>> >> to fix some memory management problems (objects added to a board or
>> >> module get deleted
>> >> by board/module object, but python tried to delete them too, now that
>> >> condition is detected
>> >> and avoided  - .thisown=0 in python during (board/module).Add(object)
>> >> did the work-.
>> >>
>> >> Now we have wxRect and wxSize wrappers, that were missing.
>> >>
>> >>
>> >> I find some important points that I must address (prioritized
>> list):
>> >>
>> >>  a) May be working in the KICAD_PLUGIN part for component
>> libraries,
>> >> to move the librairi.cpp
>> >> code into plugin system.  There's already some design about that?  [I'm
>> >> writing a separate email about this]
>> >>
>> >> This is very very interesting: we cleanup kicad's code (as it's
>> >> planned), and would offer many
>> >> benefits: ability to create footprint wizards, making automated
>> >> component servers/libraries, etc...
>> >>
>> >>  b) I should start documenting somewhere how to work with
>> scripting.
>> >> Where's
>> >> the right place? http://kicad.sourceforge.net/wiki/Main_Page ? , or
>> may
>> >> be other place?
>> >
>> > Miguel,
>> >
>> > If this document is only interesting to developers, it may make sense to
>> > put is somewhere in the source repo in the Documentation folder.  If
>> > this is something that end users may be interested then the appropriate
>> > place would be the user documentation at
>> > https://code.launchpad.net/~kicad-developers/kicad/doc.  This is where
>> > the file format documentation currently lives.  Either way, the document
>> > would be under version control which is a good thing.
>> >
>> > Wayne
>> >
>> >>
>> >>
>> >>   c) Hook points for scripting inside kicad UI:
>> >> c.1) Dynamic toolbar + hotkey assignment for registered
>> plugins
>> >> c.2) Footprint wizards list, where plugins could be
>> registered.
>> >> c.3) Contextual menu plugins (they could registered, and
>> >> when you right click on some object, they check if they should
>> >>offer their functionality in the list)
>> >> c.4) Scripted DRC plugins
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> 2012/3/20 Wayne Stambaugh > >> >
>> >>
>> >> On 3/18/2012 8:24 PM, Wolfgang Spraul wrote:
>> >> >> But just like the command line argument patch that came in 2
>> >> >> months ago, there will be a better time to merge this all in.
>> >> >
>> >> > Quick note from the guy who wrote most of the command line patch:
>> >> > I saw the scripting patch

Re: [Kicad-developers] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

2012/4/9 lajos kamocsay 

> Miguel-
>
>
> This is truly awesome!
>

It's the swig magic + some help ':D thanks a lot!

>
> I finally got your repo to build with the attached patch (to revno
> 3467). Maybe these changes work for you, too?
>

Niiice, thanks for the patch, I will apply it right now.

>
>  - had to specify python2 in a handful of .py files and in pcbnew's
> cmakelist (I have both python2 and 3)
>

 makes sense :-)

 - added rt to the linker flags (is this because of testing build?)
>
About the rt, not sure why is it needed, I suppose it's some Python
dependency
on your computer. We must leave it added by now.

 - moved up Python.h in dialog_scripting.cpp, as there were some
> define conflicts
>


I think that fixes some warnings on my side :-)


> Do you plan on upgrading to python3 at some point? I can help with
> that if you need an extra hand.
>


About Python3, I expect it not to be hard to do at some point. I choose to
stay 2.x
because wxPython still doesn't have 3.0 support. I think that at that point
we could
tune the sources to compile for Python3 and python2 as they want to do.



>
> I haven't had a chance to look at the available functions yet, but I'm
> hoping that now I can change a bunch of pad and drill sizes on a board
> automatically ;)
>
> in pcbnew/scripting/examples you have a couple of them, still very basic,
but you can already open a board, iterate over modules/pads/items, and
modify them
and save the pcb back.


>
> Thanks-
> -lajos
>
> Thank you Lajos :-)

>
>
> On Sat, Apr 7, 2012 at 1:44 PM, Wayne Stambaugh 
> wrote:
> > On 4/7/2012 12:08 PM, Miguel Angel Ajo Pelayo wrote:
> >>
> >> During the last two days I had some hours to spend on scripting
> >> again, I've been able
> >> to fix some memory management problems (objects added to a board or
> >> module get deleted
> >> by board/module object, but python tried to delete them too, now that
> >> condition is detected
> >> and avoided  - .thisown=0 in python during (board/module).Add(object)
> >> did the work-.
> >>
> >> Now we have wxRect and wxSize wrappers, that were missing.
> >>
> >>
> >> I find some important points that I must address (prioritized list):
> >>
> >>  a) May be working in the KICAD_PLUGIN part for component libraries,
> >> to move the librairi.cpp
> >> code into plugin system.  There's already some design about that?  [I'm
> >> writing a separate email about this]
> >>
> >> This is very very interesting: we cleanup kicad's code (as it's
> >> planned), and would offer many
> >> benefits: ability to create footprint wizards, making automated
> >> component servers/libraries, etc...
> >>
> >>  b) I should start documenting somewhere how to work with scripting.
> >> Where's
> >> the right place? http://kicad.sourceforge.net/wiki/Main_Page ? , or may
> >> be other place?
> >
> > Miguel,
> >
> > If this document is only interesting to developers, it may make sense to
> > put is somewhere in the source repo in the Documentation folder.  If
> > this is something that end users may be interested then the appropriate
> > place would be the user documentation at
> > https://code.launchpad.net/~kicad-developers/kicad/doc.  This is where
> > the file format documentation currently lives.  Either way, the document
> > would be under version control which is a good thing.
> >
> > Wayne
> >
> >>
> >>
> >>   c) Hook points for scripting inside kicad UI:
> >> c.1) Dynamic toolbar + hotkey assignment for registered
> plugins
> >> c.2) Footprint wizards list, where plugins could be
> registered.
> >> c.3) Contextual menu plugins (they could registered, and
> >> when you right click on some object, they check if they should
> >>offer their functionality in the list)
> >> c.4) Scripted DRC plugins
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2012/3/20 Wayne Stambaugh  >> >
> >>
> >> On 3/18/2012 8:24 PM, Wolfgang Spraul wrote:
> >> >> But just like the command line argument patch that came in 2
> >> >> months ago, there will be a better time to merge this all in.
> >> >
> >> > Quick note from the guy who wrote most of the command line patch:
> >> > I saw the scripting patch and I agree with Dick that this is super
> >> > important and great work! Well done scripting can probably replace
> >> > the need for command line options.
> >> >
> >> > I will continue to maintain the command-line patches out-of-tree
> >> > and uplevel 'every few months'. But scripting is definitely the
> >> > better approach and I'm very happy to see it moving forward.
> >> >
> >> > It is in our shared interest to keep the KiCad codebase readable
> >> > maintainable.
> >>
> >> Wolfgang,
> >>
> >> Thank you for being patient and understanding the importance of
> keeping
> >> the code base readable and maintainable.  KiCad is a large proje

Re: [Kicad-developers] Kicad scripting progress :-)

[lajos kamocsay]

Miguel-


This is truly awesome!

I finally got your repo to build with the attached patch (to revno
3467). Maybe these changes work for you, too?

  - had to specify python2 in a handful of .py files and in pcbnew's
cmakelist (I have both python2 and 3)
  - added rt to the linker flags (is this because of testing build?)
  - moved up Python.h in dialog_scripting.cpp, as there were some
define conflicts

Do you plan on upgrading to python3 at some point? I can help with
that if you need an extra hand.

I haven't had a chance to look at the available functions yet, but I'm
hoping that now I can change a bunch of pad and drill sizes on a board
automatically ;)


Thanks-
-lajos



On Sat, Apr 7, 2012 at 1:44 PM, Wayne Stambaugh  wrote:
> On 4/7/2012 12:08 PM, Miguel Angel Ajo Pelayo wrote:
>>
>>     During the last two days I had some hours to spend on scripting
>> again, I've been able
>> to fix some memory management problems (objects added to a board or
>> module get deleted
>> by board/module object, but python tried to delete them too, now that
>> condition is detected
>> and avoided  - .thisown=0 in python during (board/module).Add(object)
>> did the work-.
>>
>>     Now we have wxRect and wxSize wrappers, that were missing.
>>
>>
>>     I find some important points that I must address (prioritized list):
>>
>>      a) May be working in the KICAD_PLUGIN part for component libraries,
>> to move the librairi.cpp
>> code into plugin system.  There's already some design about that?  [I'm
>> writing a separate email about this]
>>
>>         This is very very interesting: we cleanup kicad's code (as it's
>> planned), and would offer many
>> benefits: ability to create footprint wizards, making automated
>> component servers/libraries, etc...
>>
>>      b) I should start documenting somewhere how to work with scripting.
>> Where's
>> the right place? http://kicad.sourceforge.net/wiki/Main_Page ? , or may
>> be other place?
>
> Miguel,
>
> If this document is only interesting to developers, it may make sense to
> put is somewhere in the source repo in the Documentation folder.  If
> this is something that end users may be interested then the appropriate
> place would be the user documentation at
> https://code.launchpad.net/~kicad-developers/kicad/doc.  This is where
> the file format documentation currently lives.  Either way, the document
> would be under version control which is a good thing.
>
> Wayne
>
>>
>>
>>       c) Hook points for scripting inside kicad UI:
>>             c.1) Dynamic toolbar + hotkey assignment for registered plugins
>>             c.2) Footprint wizards list, where plugins could be registered.
>>             c.3) Contextual menu plugins (they could registered, and
>> when you right click on some object, they check if they should
>>                    offer their functionality in the list)
>>             c.4) Scripted DRC plugins
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2012/3/20 Wayne Stambaugh > >
>>
>>     On 3/18/2012 8:24 PM, Wolfgang Spraul wrote:
>>     >> But just like the command line argument patch that came in 2
>>     >> months ago, there will be a better time to merge this all in.
>>     >
>>     > Quick note from the guy who wrote most of the command line patch:
>>     > I saw the scripting patch and I agree with Dick that this is super
>>     > important and great work! Well done scripting can probably replace
>>     > the need for command line options.
>>     >
>>     > I will continue to maintain the command-line patches out-of-tree
>>     > and uplevel 'every few months'. But scripting is definitely the
>>     > better approach and I'm very happy to see it moving forward.
>>     >
>>     > It is in our shared interest to keep the KiCad codebase readable
>>     > maintainable.
>>
>>     Wolfgang,
>>
>>     Thank you for being patient and understanding the importance of keeping
>>     the code base readable and maintainable.  KiCad is a large project and
>>     as it continues to grow, the importance of code maintenance cannot be
>>     under estimated.  I wish I could commit more time to the project to
>>     speed this process along.  For now, we'll have to make due.
>>
>>     Thanks,
>>
>>     Wayne
>>
>>     > Cheers,
>>     > Wolfgang
>>     >
>>     > ___
>>     > 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/ListHe

Re: [Kicad-developers] Kicad scripting progress :-)

[Wayne Stambaugh]

On 4/7/2012 12:08 PM, Miguel Angel Ajo Pelayo wrote:
> 
> During the last two days I had some hours to spend on scripting
> again, I've been able
> to fix some memory management problems (objects added to a board or
> module get deleted
> by board/module object, but python tried to delete them too, now that
> condition is detected
> and avoided  - .thisown=0 in python during (board/module).Add(object)
> did the work-.
> 
> Now we have wxRect and wxSize wrappers, that were missing.
> 
> 
> I find some important points that I must address (prioritized list):
> 
>  a) May be working in the KICAD_PLUGIN part for component libraries,
> to move the librairi.cpp 
> code into plugin system.  There's already some design about that?  [I'm
> writing a separate email about this]
> 
> This is very very interesting: we cleanup kicad's code (as it's
> planned), and would offer many
> benefits: ability to create footprint wizards, making automated
> component servers/libraries, etc...
> 
>  b) I should start documenting somewhere how to work with scripting.
> Where's
> the right place? http://kicad.sourceforge.net/wiki/Main_Page ? , or may
> be other place?

Miguel,

If this document is only interesting to developers, it may make sense to
put is somewhere in the source repo in the Documentation folder.  If
this is something that end users may be interested then the appropriate
place would be the user documentation at
https://code.launchpad.net/~kicad-developers/kicad/doc.  This is where
the file format documentation currently lives.  Either way, the document
would be under version control which is a good thing.

Wayne

> 
> 
>   c) Hook points for scripting inside kicad UI:
> c.1) Dynamic toolbar + hotkey assignment for registered plugins
> c.2) Footprint wizards list, where plugins could be registered.
> c.3) Contextual menu plugins (they could registered, and
> when you right click on some object, they check if they should
>offer their functionality in the list)
> c.4) Scripted DRC plugins
> 
>  
>  
> 
> 
> 
>
> 
> 
> 
> 2012/3/20 Wayne Stambaugh  >
> 
> On 3/18/2012 8:24 PM, Wolfgang Spraul wrote:
> >> But just like the command line argument patch that came in 2
> >> months ago, there will be a better time to merge this all in.
> >
> > Quick note from the guy who wrote most of the command line patch:
> > I saw the scripting patch and I agree with Dick that this is super
> > important and great work! Well done scripting can probably replace
> > the need for command line options.
> >
> > I will continue to maintain the command-line patches out-of-tree
> > and uplevel 'every few months'. But scripting is definitely the
> > better approach and I'm very happy to see it moving forward.
> >
> > It is in our shared interest to keep the KiCad codebase readable
> > maintainable.
> 
> Wolfgang,
> 
> Thank you for being patient and understanding the importance of keeping
> the code base readable and maintainable.  KiCad is a large project and
> as it continues to grow, the importance of code maintenance cannot be
> under estimated.  I wish I could commit more time to the project to
> speed this process along.  For now, we'll have to make due.
> 
> Thanks,
> 
> Wayne
> 
> > Cheers,
> > Wolfgang
> >
> > ___
> > 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
> 
> 
> 
> 
> -- 
> 
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo

___
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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

During the last two days I had some hours to spend on scripting again,
I've been able
to fix some memory management problems (objects added to a board or module
get deleted
by board/module object, but python tried to delete them too, now that
condition is detected
and avoided  - .thisown=0 in python during (board/module).Add(object) did
the work-.

Now we have wxRect and wxSize wrappers, that were missing.


I find some important points that I must address (prioritized list):

 a) May be working in the KICAD_PLUGIN part for component libraries, to
move the librairi.cpp
code into plugin system.  There's already some design about that?  [I'm
writing a separate email about this]

This is very very interesting: we cleanup kicad's code (as it's
planned), and would offer many
benefits: ability to create footprint wizards, making automated component
servers/libraries, etc...

 b) I should start documenting somewhere how to work with scripting.
Where's
the right place? http://kicad.sourceforge.net/wiki/Main_Page ? , or may be
other place?


  c) Hook points for scripting inside kicad UI:
c.1) Dynamic toolbar + hotkey assignment for registered plugins
c.2) Footprint wizards list, where plugins could be registered.
c.3) Contextual menu plugins (they could registered, and when
you right click on some object, they check if they should
   offer their functionality in the list)
c.4) Scripted DRC plugins










2012/3/20 Wayne Stambaugh 

> On 3/18/2012 8:24 PM, Wolfgang Spraul wrote:
> >> But just like the command line argument patch that came in 2
> >> months ago, there will be a better time to merge this all in.
> >
> > Quick note from the guy who wrote most of the command line patch:
> > I saw the scripting patch and I agree with Dick that this is super
> > important and great work! Well done scripting can probably replace
> > the need for command line options.
> >
> > I will continue to maintain the command-line patches out-of-tree
> > and uplevel 'every few months'. But scripting is definitely the
> > better approach and I'm very happy to see it moving forward.
> >
> > It is in our shared interest to keep the KiCad codebase readable
> > maintainable.
>
> Wolfgang,
>
> Thank you for being patient and understanding the importance of keeping
> the code base readable and maintainable.  KiCad is a large project and
> as it continues to grow, the importance of code maintenance cannot be
> under estimated.  I wish I could commit more time to the project to
> speed this process along.  For now, we'll have to make due.
>
> Thanks,
>
> Wayne
>
> > Cheers,
> > Wolfgang
> >
> > ___
> > 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
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Kicad scripting progress :-)

[Wayne Stambaugh]

On 3/18/2012 8:24 PM, Wolfgang Spraul wrote:
>> But just like the command line argument patch that came in 2
>> months ago, there will be a better time to merge this all in.
> 
> Quick note from the guy who wrote most of the command line patch:
> I saw the scripting patch and I agree with Dick that this is super
> important and great work! Well done scripting can probably replace
> the need for command line options.
> 
> I will continue to maintain the command-line patches out-of-tree
> and uplevel 'every few months'. But scripting is definitely the
> better approach and I'm very happy to see it moving forward.
> 
> It is in our shared interest to keep the KiCad codebase readable
> maintainable.

Wolfgang,

Thank you for being patient and understanding the importance of keeping
the code base readable and maintainable.  KiCad is a large project and
as it continues to grow, the importance of code maintenance cannot be
under estimated.  I wish I could commit more time to the project to
speed this process along.  For now, we'll have to make due.

Thanks,

Wayne

> Cheers,
> Wolfgang
> 
> ___
> 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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

Ok,

  I fixed that problem on last commit, now it must compile without
errors on Release mode,

  Thanks for reporting!! :)

2012/3/19 lajos kamocsay :
> Hi Miguel-
>
> This sounds pretty awesome! But for some reason I can't build it (revno 3453):
>
> ...
> ...
> [ 67%] Building CXX object
> pcbnew/CMakeFiles/_pcbnew.dir/scripting/pcbnewPYTHON_wrap.cxx.o
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
> In function 'PyObject* _wrap_DHEAD_VerifyListIntegrity(PyObject*,
> PyObject*)':
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:3985:11:
> error: 'class DHEAD' has no member named 'VerifyListIntegrity'
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
> In function 'PyObject* _wrap_EDA_ITEM_Show(PyObject*, PyObject*)':
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:7210:29:
> error: 'const class EDA_ITEM' has no member named 'Show'
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
> In function 'PyObject* _wrap_EDA_ITEM_ShowDummy(PyObject*,
> PyObject*)':
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:7243:29:
> error: 'const class EDA_ITEM' has no member named 'ShowDummy'
> 
>  (and lots more)
>
> My cmake:
>
> cmake ../../scripting -DKICAD_SCRIPTING=ON
> -DKICAD_SCRIPTING_MODULES=ON -DUSE_NEW_PCBNEW_LOAD=ON
> -DUSE_NEW_PCBNEW_SAVE=ON -DKICAD_STABLE_VERSION=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
>
> I have swig 2.0.4 and python 3.2.2. Do I need anything else?
>
>
> Thanks-
> -lajos
>
>
>
>
>
> On Sun, Mar 18, 2012 at 12:19 PM, Miguel Angel Ajo Pelayo
>  wrote:
>>
>> Hi All,
>>
>>     I wanted to share our progress on this, and ask a few questions.
>>
>>     At this moment, we're already able to:
>>
>> 1) run scripts (python) from inside pcbnew,
>>         pcbnew.GetBoard()  must return our current BOARD* in the editor.
>>
>> A little example:
>>
>>    from pcbnew import *
>>
>>    m = GetBoard().m_Modules
>>
>>    x,y=54000,54000
>>    i=1
>>
>>    while m:
>>         m.SetPosition(wxPoint(x+i*2000,y))
>>         m.SetReference("C%d"%i)
>>   i+=1
>> m = m.Next()
>>
>>
>> 2) run pcbnew classes and objects from inside a standalone python script.
>>
>> #!/bin/env python
>> from pcbnew import *
>>
>> pcb = LoadBoard("/tmp/my.brd")
>> m = pcb.m_Modules
>>
>> x,y=54000,54000
>> i=1
>>
>> while m:
>>      m.SetPosition(wxPoint(x+i*2000,y+i*1000))
>>      m.SetReference("C%d"%i)
>>      i+=1
>>      m = m.Next()
>>
>> SaveBoard("/tmp/my.brd",pcb)
>>
>> Same example from commandline:
>>
>>     For which I added some functions to easily load or save a PCB file via
>> IO_MGR // KICAD_PLUGIN (as Dick asked, it
>> was the best way)
>>
>>     I added typemaps for strings<->wxString, and also wrappers for wxPoint
>> and wxRect, which let
>> us to talk to methods depending on this types.
>>
>>     We have wrappers for most objects (BOARD, COMPONENT, PAD, segments ,
>> tracks, text, etc... ) and lists (DLIST based),
>> but we still miss access to std::vector and std::list objects yet.
>>
>>
>> We already have something quite useful, but testing is very welcome.
>>
>> https://code.launchpad.net/~miguelangel-r/kicad/scripting
>>
>> I only tested it on Linux/x86, and will test on Linux/x64, but testing in
>> other systems is welcome.
>> To build the branch you should compile with:
>>
>> KICAD_SCRIPTING                (for embedded scripting support in pcbnew)
>> KICAD_SCRIPTING_MODULES  (for module scripting support from python)
>> USE_NEW_PCBNEW_LOAD
>> USE_NEW_PCBNEW_SAVE
>>
>>
>> The problems I facing now are:
>>
>> a) Some pcbnew functionalities are highly coupled with UI, so dependencies
>> from objects to UI
>> are in many places (making the .SO/.DLL module approach very hard), I tried
>> to split in ui and
>> non ui .cpp files, but I ended always with linking problems, so the
>> currently built _pcbnew.so links
>> all the UI items inside, it works prefectly, but most code won't be ever
>> called.
>>
>> b) From a), for example, I'm not able to load a MODULE object from library,
>> without having a
>> PCB_BASE_FRAME object:
>>
>> from loadcmp.cpp:
>>
>> MODULE* PCB_BASE_FRAME::GetModuleLibrary( const wxString&
>> aLibraryFullFilename,
>>                                           const wxString& aModuleName,
>>                                           bool
>>  aDisplayMessageError )
>>
>>    This could be fixed by splitting the library functionality in a different
>> class, and then using it
>> from those functions (and from scripting).
>>
>> c) same for DRC, I thought it could be very helpful to run DRC checkings
>> (automated commandline
>> scripts for DRC checking) , but it also was highly coupled to the UI.
>>
>> d) this is minor, but it's there... if you run pcbnew from the same
>> directory _pcbnew.so is (this is normal
>> when bu

Re: [Kicad-developers] Kicad scripting progress :-)

[Wolfgang Spraul]

Dick,
that's a great benefit for everybody that you spell out your
thinking and plans so clearly. Thanks!

If the Python scripting has an entry point and way to execute
KiCad actions, then that same entry point can be used by a
command line processor.
If the interface between scripting and KiCad engine is not so
clean, the command line processor could piggypack on top of
Python. So let's hope for a clean interface, then things will
be good.
Wolfgang

___
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] Kicad scripting progress :-)

[Dick Hollenbeck]

On 03/19/2012 09:45 AM, Wolfgang Spraul wrote:
>> But if we actually read what Wolfgang said, he thinks that
>> the command line option version of main() program will not
>> be needed because of your work.
> He :-)
>
> I didn't actually look at the scripting patch sources to find
> out which actions work today and which not.
>
> But 'scripting' in general sounds like the better/bigger step to
> take to make things right, and I am sure when the scripting
> patches eventually get merged or pulled into KiCad, I will be
> able to rewrite the command line options on top of scripting.
>
> Command line options are a special case of scripting imho.

I don't see that, not necessarily anyway, since you can fulfill your command 
line options
without anything but C++.



If you chose to fulfill them in python, then one has to ask why command line 
options,
instead of a simple wxPython form?

My point is that once there is a clean, UI-less DLL/DSO underneath, you can 
park most
anything on top you want, multiple alternative main() programs.

Again, repeating what I wrote last month:


a) One that incorporates swig bindings, but excludes the stock PCBNEW UI,

b) One that uses wxWidgets and creates our famililar PCBNEW UI, and may know 
about swig
bindings too.

c) one that does not know about swig bindings, does not include PCBNEW UI, is 
pure C++ yet
vectors into BOARD_ACTIONS from the command line main(), needing no scripting 
support at all.

d) one that simply designs your board for you because it can read your mind, or 
your
config files, spits out a board and makes you rich 5 minutes later.

e) ...


The concept here is "multiple alternative main()s", which on its face is not 
different
than what you get do when using most any DLL/DSO underneath, sometimes called a 
library.



___
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] Kicad scripting progress :-)

[Wolfgang Spraul]

> But if we actually read what Wolfgang said, he thinks that
> the command line option version of main() program will not
> be needed because of your work.

He :-)

I didn't actually look at the scripting patch sources to find
out which actions work today and which not.

But 'scripting' in general sounds like the better/bigger step to
take to make things right, and I am sure when the scripting
patches eventually get merged or pulled into KiCad, I will be
able to rewrite the command line options on top of scripting.

Command line options are a special case of scripting imho.
Cheers,
Wolfgang

___
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] Kicad scripting progress :-)

[Dick Hollenbeck]

On 03/19/2012 06:52 AM, Miguel Angel Ajo Pelayo wrote:
> Sorry, somehow my pointer crashed in the "Send" button to early...
>
> I meant that, when the scripting is working somehow I could
> try to help in porting your patches to scripting.

Miguel,

Thanks for your offer to help.

The command line processor patch is a way for main() to route directly into 
those board
actions that we talked about, by passing the UI in most cases.  So assuming we 
move board
actions into a class BOARD_ACTIONS, then the idea of the command line processor 
gets much
easier.  It is an ALTERNATIVE small main() program which sits on top of the 
common DLL/DSO
and simply calls BOARD_ACTIONS for each command line flag, along with gathered 
parameters.

We did not add the patch because bypassing the UI while the UI is present, is 
cluttered. 
Wanted to get a DLL/DSO in place first without most of the UI, then add the 
support at
that future time.

But if we actually read what Wolfgang said, he thinks that the command line 
option version
of main() program will not be needed because of your work.

(Although it does require that the scripting language(s) be installed, which 
would not be
a requirement of a pure command line processor.)


Dick


___
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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

Sorry, somehow my pointer crashed in the "Send" button to early...

I meant that, when the scripting is working somehow I could
try to help in porting your patches to scripting.

2012/3/19 Miguel Angel Ajo Pelayo :
> Thanks for the feedback Wolfgang,
>
>  What does the command-line argument patch do?, may be
> when the
>
> 2012/3/19 Wolfgang Spraul :
>>> But just like the command line argument patch that came in 2
>>> months ago, there will be a better time to merge this all in.
>>
>> Quick note from the guy who wrote most of the command line patch:
>> I saw the scripting patch and I agree with Dick that this is super
>> important and great work! Well done scripting can probably replace
>> the need for command line options.
>>
>> I will continue to maintain the command-line patches out-of-tree
>> and uplevel 'every few months'. But scripting is definitely the
>> better approach and I'm very happy to see it moving forward.
>>
>> It is in our shared interest to keep the KiCad codebase readable
>> maintainable.
>> Cheers,
>> Wolfgang
>>
>> ___
>> 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
>
>
>
> --
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo

___
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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

Thanks for the feedback Wolfgang,

 What does the command-line argument patch do?, may be
when the

2012/3/19 Wolfgang Spraul :
>> But just like the command line argument patch that came in 2
>> months ago, there will be a better time to merge this all in.
>
> Quick note from the guy who wrote most of the command line patch:
> I saw the scripting patch and I agree with Dick that this is super
> important and great work! Well done scripting can probably replace
> the need for command line options.
>
> I will continue to maintain the command-line patches out-of-tree
> and uplevel 'every few months'. But scripting is definitely the
> better approach and I'm very happy to see it moving forward.
>
> It is in our shared interest to keep the KiCad codebase readable
> maintainable.
> Cheers,
> Wolfgang
>
> ___
> 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



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo

___
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] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

It seems like I introduced any dependency with the DEBUG mode, please
enable the DEBUG
on build (not sure what flag was it..)


For python, I built it with Python 2.7 (or 2.6), (I choosed to stay in
2.x because all the wx wrappers
are in 2.x yet as far as I remember). But making the jump into 3.x
later shouldn't be anything complex.

Thanks a lot for testing, I'll try to remove the "DEBUG" dependency.



2012/3/19 lajos kamocsay :
> Hi Miguel-
>
> This sounds pretty awesome! But for some reason I can't build it (revno 3453):
>
> ...
> ...
> [ 67%] Building CXX object
> pcbnew/CMakeFiles/_pcbnew.dir/scripting/pcbnewPYTHON_wrap.cxx.o
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
> In function 'PyObject* _wrap_DHEAD_VerifyListIntegrity(PyObject*,
> PyObject*)':
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:3985:11:
> error: 'class DHEAD' has no member named 'VerifyListIntegrity'
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
> In function 'PyObject* _wrap_EDA_ITEM_Show(PyObject*, PyObject*)':
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:7210:29:
> error: 'const class EDA_ITEM' has no member named 'Show'
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
> In function 'PyObject* _wrap_EDA_ITEM_ShowDummy(PyObject*,
> PyObject*)':
> /Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:7243:29:
> error: 'const class EDA_ITEM' has no member named 'ShowDummy'
> 
>  (and lots more)
>
> My cmake:
>
> cmake ../../scripting -DKICAD_SCRIPTING=ON
> -DKICAD_SCRIPTING_MODULES=ON -DUSE_NEW_PCBNEW_LOAD=ON
> -DUSE_NEW_PCBNEW_SAVE=ON -DKICAD_STABLE_VERSION=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr
>
> I have swig 2.0.4 and python 3.2.2. Do I need anything else?
>
>
> Thanks-
> -lajos
>
>
>
>
>
> On Sun, Mar 18, 2012 at 12:19 PM, Miguel Angel Ajo Pelayo
>  wrote:
>>
>> Hi All,
>>
>>     I wanted to share our progress on this, and ask a few questions.
>>
>>     At this moment, we're already able to:
>>
>> 1) run scripts (python) from inside pcbnew,
>>         pcbnew.GetBoard()  must return our current BOARD* in the editor.
>>
>> A little example:
>>
>>    from pcbnew import *
>>
>>    m = GetBoard().m_Modules
>>
>>    x,y=54000,54000
>>    i=1
>>
>>    while m:
>>         m.SetPosition(wxPoint(x+i*2000,y))
>>         m.SetReference("C%d"%i)
>>   i+=1
>> m = m.Next()
>>
>>
>> 2) run pcbnew classes and objects from inside a standalone python script.
>>
>> #!/bin/env python
>> from pcbnew import *
>>
>> pcb = LoadBoard("/tmp/my.brd")
>> m = pcb.m_Modules
>>
>> x,y=54000,54000
>> i=1
>>
>> while m:
>>      m.SetPosition(wxPoint(x+i*2000,y+i*1000))
>>      m.SetReference("C%d"%i)
>>      i+=1
>>      m = m.Next()
>>
>> SaveBoard("/tmp/my.brd",pcb)
>>
>> Same example from commandline:
>>
>>     For which I added some functions to easily load or save a PCB file via
>> IO_MGR // KICAD_PLUGIN (as Dick asked, it
>> was the best way)
>>
>>     I added typemaps for strings<->wxString, and also wrappers for wxPoint
>> and wxRect, which let
>> us to talk to methods depending on this types.
>>
>>     We have wrappers for most objects (BOARD, COMPONENT, PAD, segments ,
>> tracks, text, etc... ) and lists (DLIST based),
>> but we still miss access to std::vector and std::list objects yet.
>>
>>
>> We already have something quite useful, but testing is very welcome.
>>
>> https://code.launchpad.net/~miguelangel-r/kicad/scripting
>>
>> I only tested it on Linux/x86, and will test on Linux/x64, but testing in
>> other systems is welcome.
>> To build the branch you should compile with:
>>
>> KICAD_SCRIPTING                (for embedded scripting support in pcbnew)
>> KICAD_SCRIPTING_MODULES  (for module scripting support from python)
>> USE_NEW_PCBNEW_LOAD
>> USE_NEW_PCBNEW_SAVE
>>
>>
>> The problems I facing now are:
>>
>> a) Some pcbnew functionalities are highly coupled with UI, so dependencies
>> from objects to UI
>> are in many places (making the .SO/.DLL module approach very hard), I tried
>> to split in ui and
>> non ui .cpp files, but I ended always with linking problems, so the
>> currently built _pcbnew.so links
>> all the UI items inside, it works prefectly, but most code won't be ever
>> called.
>>
>> b) From a), for example, I'm not able to load a MODULE object from library,
>> without having a
>> PCB_BASE_FRAME object:
>>
>> from loadcmp.cpp:
>>
>> MODULE* PCB_BASE_FRAME::GetModuleLibrary( const wxString&
>> aLibraryFullFilename,
>>                                           const wxString& aModuleName,
>>                                           bool
>>  aDisplayMessageError )
>>
>>    This could be fixed by splitting the library functionality in a different
>> class, and then using it
>> from those functions (and from scripting).
>>
>> c) same for DRC, 

Re: [Kicad-developers] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

Thanks for the explantation about BOARD_ACTIONS, it looks clean.

I've been implementing a couple of nice things over DLIST, that now can
be iterated with standard python loops, also the BOARD_ITEM/EDA_ITEM
polymorphic class is handled in a very natural way, with the extended
.Cast() method
(implemented in BOARD_ITEM from .i, no cpp modification for that).

from pcbnew import *
pcb = LoadBoard(filename)

ToUnits=ToMils
FromUnits=FromMils

print "LISTING VIAS+TRACKS:"

for item in pcb.GetTracks():  #internally calls .Cast() at each
iteration of the tracks list

if type(item) is SEGVIA:

pos = item.GetPosition()
drill = item.GetDrillValue()
width = item.GetWidth()
print " * Via:   %s - %f/%f 
"%(ToUnits(pos),ToUnits(drill),ToUnits(width))

elif type(item) is TRACK:

start = item.GetStart()
end = item.GetEnd()
width = item.GetWidth()

print " * Track: %s to %s, width %f" %
(ToUnits(start),ToUnits(end),ToUnits(width))

else:
print "Unknown type %s" % type(item)

Full example here:
http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/view/head:/pcbnew/scripting/examples/listPcb.py

Here we can start to work with the magic of dynamic typing in
scripting languages

http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/view/head:/scripting/dlist.i
http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/view/head:/pcbnew/scripting/board_item.i


Greetings :-)


--

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo

___
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] Kicad scripting progress :-)

[lajos kamocsay]

Hi Miguel-

This sounds pretty awesome! But for some reason I can't build it (revno 3453):

...
...
[ 67%] Building CXX object
pcbnew/CMakeFiles/_pcbnew.dir/scripting/pcbnewPYTHON_wrap.cxx.o
/Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
In function 'PyObject* _wrap_DHEAD_VerifyListIntegrity(PyObject*,
PyObject*)':
/Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:3985:11:
error: 'class DHEAD' has no member named 'VerifyListIntegrity'
/Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
In function 'PyObject* _wrap_EDA_ITEM_Show(PyObject*, PyObject*)':
/Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:7210:29:
error: 'const class EDA_ITEM' has no member named 'Show'
/Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
In function 'PyObject* _wrap_EDA_ITEM_ShowDummy(PyObject*,
PyObject*)':
/Projects/linux/kicad/build.scripting.bzr/Release/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:7243:29:
error: 'const class EDA_ITEM' has no member named 'ShowDummy'

 (and lots more)

My cmake:

cmake ../../scripting -DKICAD_SCRIPTING=ON
-DKICAD_SCRIPTING_MODULES=ON -DUSE_NEW_PCBNEW_LOAD=ON
-DUSE_NEW_PCBNEW_SAVE=ON -DKICAD_STABLE_VERSION=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr

I have swig 2.0.4 and python 3.2.2. Do I need anything else?


Thanks-
-lajos





On Sun, Mar 18, 2012 at 12:19 PM, Miguel Angel Ajo Pelayo
 wrote:
>
> Hi All,
>
>     I wanted to share our progress on this, and ask a few questions.
>
>     At this moment, we're already able to:
>
> 1) run scripts (python) from inside pcbnew,
>         pcbnew.GetBoard()  must return our current BOARD* in the editor.
>
> A little example:
>
>    from pcbnew import *
>
>    m = GetBoard().m_Modules
>
>    x,y=54000,54000
>    i=1
>
>    while m:
>         m.SetPosition(wxPoint(x+i*2000,y))
>         m.SetReference("C%d"%i)
>   i+=1
> m = m.Next()
>
>
> 2) run pcbnew classes and objects from inside a standalone python script.
>
> #!/bin/env python
> from pcbnew import *
>
> pcb = LoadBoard("/tmp/my.brd")
> m = pcb.m_Modules
>
> x,y=54000,54000
> i=1
>
> while m:
>      m.SetPosition(wxPoint(x+i*2000,y+i*1000))
>      m.SetReference("C%d"%i)
>      i+=1
>      m = m.Next()
>
> SaveBoard("/tmp/my.brd",pcb)
>
> Same example from commandline:
>
>     For which I added some functions to easily load or save a PCB file via
> IO_MGR // KICAD_PLUGIN (as Dick asked, it
> was the best way)
>
>     I added typemaps for strings<->wxString, and also wrappers for wxPoint
> and wxRect, which let
> us to talk to methods depending on this types.
>
>     We have wrappers for most objects (BOARD, COMPONENT, PAD, segments ,
> tracks, text, etc... ) and lists (DLIST based),
> but we still miss access to std::vector and std::list objects yet.
>
>
> We already have something quite useful, but testing is very welcome.
>
> https://code.launchpad.net/~miguelangel-r/kicad/scripting
>
> I only tested it on Linux/x86, and will test on Linux/x64, but testing in
> other systems is welcome.
> To build the branch you should compile with:
>
> KICAD_SCRIPTING                (for embedded scripting support in pcbnew)
> KICAD_SCRIPTING_MODULES  (for module scripting support from python)
> USE_NEW_PCBNEW_LOAD
> USE_NEW_PCBNEW_SAVE
>
>
> The problems I facing now are:
>
> a) Some pcbnew functionalities are highly coupled with UI, so dependencies
> from objects to UI
> are in many places (making the .SO/.DLL module approach very hard), I tried
> to split in ui and
> non ui .cpp files, but I ended always with linking problems, so the
> currently built _pcbnew.so links
> all the UI items inside, it works prefectly, but most code won't be ever
> called.
>
> b) From a), for example, I'm not able to load a MODULE object from library,
> without having a
> PCB_BASE_FRAME object:
>
> from loadcmp.cpp:
>
> MODULE* PCB_BASE_FRAME::GetModuleLibrary( const wxString&
> aLibraryFullFilename,
>                                           const wxString& aModuleName,
>                                           bool
>  aDisplayMessageError )
>
>    This could be fixed by splitting the library functionality in a different
> class, and then using it
> from those functions (and from scripting).
>
> c) same for DRC, I thought it could be very helpful to run DRC checkings
> (automated commandline
> scripts for DRC checking) , but it also was highly coupled to the UI.
>
> d) this is minor, but it's there... if you run pcbnew from the same
> directory _pcbnew.so is (this is normal
> when building), then pcbnew will load _pcbnew.so from it's local directory
> (this is some swig feature...),
> then GetBoard() won't work (return None) because it's a separeted instance
> from our running pcbnew...,
> so if you want to test ./pcbnew from your build directory, then move
> _pcbnew.so somewhere else ;)
>
>
> e) other minor, if y

Re: [Kicad-developers] Kicad scripting progress :-)

[Wolfgang Spraul]

> But just like the command line argument patch that came in 2
> months ago, there will be a better time to merge this all in.

Quick note from the guy who wrote most of the command line patch:
I saw the scripting patch and I agree with Dick that this is super
important and great work! Well done scripting can probably replace
the need for command line options.

I will continue to maintain the command-line patches out-of-tree
and uplevel 'every few months'. But scripting is definitely the
better approach and I'm very happy to see it moving forward.

It is in our shared interest to keep the KiCad codebase readable
maintainable.
Cheers,
Wolfgang

___
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] Kicad scripting progress :-)

[Dick Hollenbeck]

On 03/18/2012 01:46 PM, Miguel Angel Ajo Pelayo wrote:
> Hi Dick,
>
> 2012/3/18 Dick Hollenbeck mailto:d...@softplc.com>>
>
> On 03/18/2012 11:19 AM, Miguel Angel Ajo Pelayo wrote:
> > We already have something quite useful, but testing is very welcome.
>
> I would be inclined to offer my help on the architectural changes needed 
> to make this
> right, before I were to spend any of my time "testing".
>
>
> I will be glad to offer my help on those architectural changes, I could do it 
> while I keep
> working on the scripting system. I'm finding it a very grateful work, because 
> without 
> very big efforts (thanks to swig) I'm being able to get very good results.
>  
>
> Finding that time is my biggest problem.  Some of my thoughts:
>
>
> I know what you mean, really ':)
>  
>
>
> a) This is very important ground work.
>
>
> Not as important as the refactoring you're working on :-)
>  
>
>
> b) Eventually I hope to be able to help, and it will come in bits and 
> pieces.  You will
> see on my personal todo list in TODO.txt, that I have adding "loading 
> modules" to the
> PLUGIN API near the top.  This will happen very soon.  See number 2) in 
> that file.
>
>
> Nice!, that sounds great, really great.
>  
>
>
> c) The architectural changes I identified before still need to happen 
> before we can call
> this a completely sound design.  I personally am not motivated to merely 
> get this done,
> but am motivated to get it done correctly on top of the proper 
> architecture.   I do not
> feel that much if any of the work you have done is a waste of time.  
> Quite the contrary.
> However, I am not surprised in the least that you have hit a an 
> architectural wall.
>  It is
> precisely the wall that I warned about.
>
>
> Yes, after going down in the code I agree with you, let's clean up the house, 
> and when
> it's done then we merge.
>
> During that time I could start writing some basic scripts to check all the 
> object
> wrappings,, 
> etc... , the tests, and  
>
>
> (On a personal note, the wall that I am hitting lately is insufficient 
> time to spend on
> KiCad.  There are several items before this scripting in my work queue, 
> but I feel
> scripting is probably one of the most important enhancements that will 
> ever happen
> to KiCad.)
>
>
> I think it can be a very interesting one, things like the recently proposed 
> pcb to
> schematic 
> reverse engineering functionality could be very well done in scripting, so 
> executed and
> maintained out
> of KiCad's sourcecode.
>  
>
> We will soon be moving to all new file formats in PCBNEW, both for 
> footprints and
> boards,
> driven by the move to nanometer internal units.
>
>
> One question, now the internal units (used in the objects as wxPoints are in 
> 1/10 of
> mils or inch derived
> units, right?) I was quite surprised seeing that when I added 2000 to X it 
> moved
> 2.54*2mm (if I'm not wrong) :-)
>
> I think that for easiness I'll define some unit converters like mm(x) or 
> inches(x) that
> must map to our internal unit systems,
> that would also make the scripts I write now compatible with the nanometer 
> upgrade.
>
>  
>
> At this time we have an opportunity to make very disruptive changes to 
> the PCBNEW file
> format, an opportunity which does not come along often.  The beauty of 
> having the
> scripting inside the program, on top of the object model, is that your 
> work will be
> largely preserved, even as the BOARD format changes, probably radically.  
> (An external
> pure python library which tried to read *.brd files would be immediately 
> obsolete.)
>
>
> Yes, those changes are hard to make when a project is already rolling, having 
> the
> KICAD_PLUGIN and IO_MGR the compatibility is easier to maintain, for the 
> scripting
> must be totally transparent.
>  
>
>
> I thank you for the progress report, and I honestly believe you are doing 
> *very*
> important
> work, which will eventually get pulled into KiCad.  You have my personal 
> guarantee.
>
>
> Thanks a lot Dick, I will keep working to make it as good as possible before 
> merge. 
>  
>
>
> But just like the command line argument patch that came in 2 months ago, 
> there will be a
> better time to merge this all in.   After BOARD_ACTIONS, after 
> nano-meters, and after we
> have a clean separation of UI from actions.  Otherwise it would be like 
> re-modelling
> while
> someone is cleaning the house.  Yes, I have been saying this for nearly 5 
> years, but I
> honestly believe we are now very very close, relatively speaking.
>
>
> Once I feel the scripting work is ready with the current version I will try 
> to help on that.
>
> What's the idea of BOARD_ACTIONS? :)


I'm sure I've answered this before.  So here is only a half hearted response 
(better
probably to google for it):

It's a class which has board processing 

Re: [Kicad-developers] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

Hi Dick,

2012/3/18 Dick Hollenbeck 

> On 03/18/2012 11:19 AM, Miguel Angel Ajo Pelayo wrote:
> > We already have something quite useful, but testing is very welcome.
>
> I would be inclined to offer my help on the architectural changes needed
> to make this
> right, before I were to spend any of my time "testing".
>
>
I will be glad to offer my help on those architectural changes, I could do
it while I keep
working on the scripting system. I'm finding it a very grateful work,
because without
very big efforts (thanks to swig) I'm being able to get very good results.


> Finding that time is my biggest problem.  Some of my thoughts:
>

I know what you mean, really ':)


>
> a) This is very important ground work.
>

Not as important as the refactoring you're working on :-)


>
> b) Eventually I hope to be able to help, and it will come in bits and
> pieces.  You will
> see on my personal todo list in TODO.txt, that I have adding "loading
> modules" to the
> PLUGIN API near the top.  This will happen very soon.  See number 2) in
> that file.
>

Nice!, that sounds great, really great.


>
> c) The architectural changes I identified before still need to happen
> before we can call
> this a completely sound design.  I personally am not motivated to merely
> get this done,
> but am motivated to get it done correctly on top of the proper
> architecture.   I do not
> feel that much if any of the work you have done is a waste of time.  Quite
> the contrary.
> However, I am not surprised in the least that you have hit a an
> architectural wall.  It is
> precisely the wall that I warned about.
>

Yes, after going down in the code I agree with you, let's clean up the
house, and when
it's done then we merge.

During that time I could start writing some basic scripts to check all the
object wrappings,,
etc... , the tests, and


(On a personal note, the wall that I am hitting lately is insufficient time
> to spend on
> KiCad.  There are several items before this scripting in my work queue,
> but I feel
> scripting is probably one of the most important enhancements that will
> ever happen to KiCad.)
>

I think it can be a very interesting one, things like the recently proposed
pcb to schematic
reverse engineering functionality could be very well done in scripting, so
executed and maintained out
of KiCad's sourcecode.


> We will soon be moving to all new file formats in PCBNEW, both for
> footprints and boards,
> driven by the move to nanometer internal units.
>

One question, now the internal units (used in the objects as wxPoints are
in 1/10 of mils or inch derived
units, right?) I was quite surprised seeing that when I added 2000 to X it
moved 2.54*2mm (if I'm not wrong) :-)

I think that for easiness I'll define some unit converters like mm(x) or
inches(x) that must map to our internal unit systems,
that would also make the scripts I write now compatible with the nanometer
upgrade.



> At this time we have an opportunity to make very disruptive changes to the
> PCBNEW file
> format, an opportunity which does not come along often.  The beauty of
> having the
> scripting inside the program, on top of the object model, is that your
> work will be
> largely preserved, even as the BOARD format changes, probably radically.
>  (An external
> pure python library which tried to read *.brd files would be immediately
> obsolete.)
>
>
Yes, those changes are hard to make when a project is already rolling,
having the KICAD_PLUGIN and IO_MGR the compatibility is easier to maintain,
for the scripting
must be totally transparent.


>
> I thank you for the progress report, and I honestly believe you are doing
> *very* important
> work, which will eventually get pulled into KiCad.  You have my personal
> guarantee.
>
>
Thanks a lot Dick, I will keep working to make it as good as possible
before merge.


>
> But just like the command line argument patch that came in 2 months ago,
> there will be a
> better time to merge this all in.   After BOARD_ACTIONS, after
> nano-meters, and after we
> have a clean separation of UI from actions.  Otherwise it would be like
> re-modelling while
> someone is cleaning the house.  Yes, I have been saying this for nearly 5
> years, but I
> honestly believe we are now very very close, relatively speaking.
>

Once I feel the scripting work is ready with the current version I will try
to help on that.

What's the idea of BOARD_ACTIONS? :)



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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] Kicad scripting progress :-)

[Dick Hollenbeck]

On 03/18/2012 11:19 AM, Miguel Angel Ajo Pelayo wrote:
>
> Hi All, 
>
> I wanted to share our progress on this, and ask a few questions.
>
> At this moment, we're already able to:
>
> 1) run scripts (python) from inside pcbnew,
> pcbnew.GetBoard()  must return our current BOARD* in the editor.
>
> A little example:
>
>from pcbnew import *
>
>m = GetBoard().m_Modules
>
>x,y=54000,54000
>i=1
>
>while m: 
> m.SetPosition(wxPoint(x+i*2000,y))
> m.SetReference("C%d"%i)
>  i+=1
> m = m.Next()
>
>
> 2) run pcbnew classes and objects from inside a standalone python script.
>
> #!/bin/env python
> from pcbnew import *
>
> pcb = LoadBoard("/tmp/my.brd")   
> m = pcb.m_Modules
>
> x,y=54000,54000
> i=1
>
> while m: 
>  m.SetPosition(wxPoint(x+i*2000,y+i*1000))
>  m.SetReference("C%d"%i)
>  i+=1
>  m = m.Next()  
>  
> SaveBoard("/tmp/my.brd",pcb)
>
> Same example from commandline:
>
> For which I added some functions to easily load or save a PCB file via 
> IO_MGR //
> KICAD_PLUGIN (as Dick asked, it
> was the best way)
>
> I added typemaps for strings<->wxString, and also wrappers for wxPoint 
> and wxRect,
> which let
> us to talk to methods depending on this types.
>
> We have wrappers for most objects (BOARD, COMPONENT, PAD, segments , 
> tracks, text,
> etc... ) and lists (DLIST based),
> but we still miss access to std::vector and std::list objects yet.
>
>
> We already have something quite useful, but testing is very welcome.

I would be inclined to offer my help on the architectural changes needed to 
make this
right, before I were to spend any of my time "testing".

Finding that time is my biggest problem.  Some of my thoughts:

a) This is very important ground work.

b) Eventually I hope to be able to help, and it will come in bits and pieces.  
You will
see on my personal todo list in TODO.txt, that I have adding "loading modules" 
to the
PLUGIN API near the top.  This will happen very soon.  See number 2) in that 
file.

c) The architectural changes I identified before still need to happen before we 
can call
this a completely sound design.  I personally am not motivated to merely get 
this done,
but am motivated to get it done correctly on top of the proper architecture.   
I do not
feel that much if any of the work you have done is a waste of time.  Quite the 
contrary. 
However, I am not surprised in the least that you have hit a an architectural 
wall.  It is
precisely the wall that I warned about.


(On a personal note, the wall that I am hitting lately is insufficient time to 
spend on
KiCad.  There are several items before this scripting in my work queue, but I 
feel
scripting is probably one of the most important enhancements that will ever 
happen to KiCad.)


We will soon be moving to all new file formats in PCBNEW, both for footprints 
and boards,
driven by the move to nanometer internal units.
At this time we have an opportunity to make very disruptive changes to the 
PCBNEW file
format, an opportunity which does not come along often.  The beauty of having 
the
scripting inside the program, on top of the object model, is that your work 
will be
largely preserved, even as the BOARD format changes, probably radically.  (An 
external
pure python library which tried to read *.brd files would be immediately 
obsolete.)


I thank you for the progress report, and I honestly believe you are doing 
*very* important
work, which will eventually get pulled into KiCad.  You have my personal 
guarantee.


But just like the command line argument patch that came in 2 months ago, there 
will be a
better time to merge this all in.   After BOARD_ACTIONS, after nano-meters, and 
after we
have a clean separation of UI from actions.  Otherwise it would be like 
re-modelling while
someone is cleaning the house.  Yes, I have been saying this for nearly 5 
years, but I
honestly believe we are now very very close, relatively speaking.


Dick



___
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

[Kicad-developers] Kicad scripting progress :-)

[Miguel Angel Ajo Pelayo]

Hi All,

I wanted to share our progress on this, and ask a few questions.

At this moment, we're already able to:

1) run scripts (python) from inside pcbnew,
pcbnew.GetBoard()  must return our current BOARD* in the editor.

A little example:

   from pcbnew import *

   m = GetBoard().m_Modules

   x,y=54000,54000
   i=1

   while m:
m.SetPosition(wxPoint(x+i*2000,y))
m.SetReference("C%d"%i)
  i+=1
m = m.Next()


2) run pcbnew classes and objects from inside a standalone python script.

#!/bin/env python
from pcbnew import *

pcb = LoadBoard("/tmp/my.brd")
m = pcb.m_Modules

x,y=54000,54000
i=1

while m:
 m.SetPosition(wxPoint(x+i*2000,y+i*1000))
 m.SetReference("C%d"%i)
 i+=1
 m = m.Next()

SaveBoard("/tmp/my.brd",pcb)

Same example from commandline:

For which I added some functions to easily load or save a PCB file via
IO_MGR // KICAD_PLUGIN (as Dick asked, it
was the best way)

I added typemaps for strings<->wxString, and also wrappers for wxPoint
and wxRect, which let
us to talk to methods depending on this types.

We have wrappers for most objects (BOARD, COMPONENT, PAD, segments ,
tracks, text, etc... ) and lists (DLIST based),
but we still miss access to std::vector and std::list objects yet.


We already have something quite useful, but testing is very welcome.

https://code.launchpad.net/~miguelangel-r/kicad/scripting

I only tested it on Linux/x86, and will test on Linux/x64, but testing in
other systems is welcome.
To build the branch you should compile with:

KICAD_SCRIPTING(for embedded scripting support in pcbnew)
KICAD_SCRIPTING_MODULES  (for module scripting support from python)
USE_NEW_PCBNEW_LOAD
USE_NEW_PCBNEW_SAVE


The problems I facing now are:

a) Some pcbnew functionalities are highly coupled with UI, so dependencies
from objects to UI
are in many places (making the .SO/.DLL module approach very hard), I tried
to split in ui and
non ui .cpp files, but I ended always with linking problems, so the
currently built _pcbnew.so links
all the UI items inside, it works prefectly, but most code won't be ever
called.

b) From a), for example, I'm not able to load a MODULE object from library,
without having a
PCB_BASE_FRAME object:

from loadcmp.cpp:

MODULE* PCB_BASE_FRAME::GetModuleLibrary( const wxString&
aLibraryFullFilename,
  const wxString& aModuleName,
  bool
 aDisplayMessageError )

   This could be fixed by splitting the library functionality in a
different class, and then using it
from those functions (and from scripting).

c) same for DRC, I thought it could be very helpful to run DRC checkings
(automated commandline
scripts for DRC checking) , but it also was highly coupled to the UI.

d) this is minor, but it's there... if you run pcbnew from the same
directory _pcbnew.so is (this is normal
when building), then pcbnew will load _pcbnew.so from it's local directory
(this is some swig feature...),
then GetBoard() won't work (return None) because it's a separeted instance
from our running pcbnew...,
so if you want to test ./pcbnew from your build directory, then move
_pcbnew.so somewhere else ;)


e) other minor, if you make install to /usr/local, then the _pcbnew.so and
pcbnew.py will go to
/usr/local/share/python, which is out of the normal python path, so you
will need to do:

export PYTHONPATH=$PYTHONPATH:/usr/local/share/python

and then run your script.



I will keep working on it, and keep you updated, but any tests/feedback are
really welcome :-)


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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