kicad-developers team mailing list archive

[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).



> >
> >
> >
> >     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