kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

I'm adding an example bellow:


2012/5/6 Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>

>
>
> 2012/5/6 Dick Hollenbeck <dick@xxxxxxxxxxx>
>
>
>>  >      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 <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
>>
>>
>
>
> --
>
> 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