I'm adding an example bellow:
2012/5/6 Miguel Angel Ajo Pelayo <[email protected]> > > > 2012/5/6 Dick Hollenbeck <[email protected]> > > >> > 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 <Swig Object of type 'wxRect *' at 0x88389c8> >>> pcb_rect.this <Swig Object of type 'wxRect *' at 0x8ef1800> >>> wx_rect.this = pcb_rect.this # it doesn't work: >>> wx_rect.GetX() Traceback (most recent call last): File "<stdin>", line 1, in <module> 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 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 >> >> > > > -- > > 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 : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
