kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

2012/5/6 Dick Hollenbeck <dick@xxxxxxxxxxx>

> 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 <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
> >
> >     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
> >     <https://launchpad.net/%7Ekicad-developers>
> >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> >     <https://launchpad.net/%7Ekicad-developers>
> >     More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
> > --
> >
> > 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