kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/06/2012 04:17 AM, Miguel Angel Ajo Pelayo wrote:
>
>
> 2012/5/6 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto: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.

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 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>
>     <mailto: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>
>     >     <https://launchpad.net/%7Ekicad-developers>
>     >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>     >     Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/%7Ekicad-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 <tel:%2B34%20636%2052%2025%2069>
>     > skype: ajoajoajo
>
>
>
>
> -- 
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo