On 05/06/2012 04:17 AM, Miguel Angel Ajo Pelayo wrote: > > > 2012/5/6 Dick Hollenbeck <[email protected] <mailto:[email protected]>> > > 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 <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > > > 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 : [email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > 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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
