Hi Miles, On 11/23/2017 04:17 PM, miles mccoo wrote: > In a recent thread > <https://lists.launchpad.net/kicad-developers/msg31700.html> on this list, > it was mentioned that kicad may need to drop support for SWIG/Python due to > wx and wxPython limitations. > > Perhaps I misinterpreted what was said. > It's my perception that the kicad team doesn't see the value in a python > interface that I see > <https://kicad.mmccoo.com/2017/01/26/real-scripting-the-most-important-feature-a-tool-can-have/>. > Perhaps I'm wrong in that too
I might have not expressed myself clearly. I am aware of huge potential in scripting/plugin/extensions interfaces. Our problem is we do not provide a nice interface, we simply expose C++ guts. It means that the users get upset every time we modify a class they use. I do not write many Python scripts, but I worked with unstable APIs, so I can tell what kind of frustration they cause. We *need* an abstraction layer to keep both sides happy, so we can change the C++ methods and the users have Python interface they may rely on. I never said we plan to drop Python support. I was simply afraid that we may spent a lot of time petting the SWIG interface, which we will nuke it and start from scratch because of inevitable switch to Phoenix. The only doubt I had is whether we can simply port our wxPython work to Phoenix. > Anyway, I have a version of kicad working with wxPython 4.0 (AKA Phoenix) > > A more detailed summary can be read here on my blog > <https://kicad.mmccoo.com/2017/11/23/learnings-from-moving-kicad-to-wxpython-4-0/> > and > a diff file of my changes is here: > http://mmccoo.com/random/diffs_for_phoenix This is very cool and appreciated, thank you! By reading your patch, I assume we can keep developing our SWIG files and at one point switch to Phoenix. If this is the case, then I think that work on a better Python interface using SWIG is very welcome, as it will be reused in the future. > The short version: Kicad will probably want to wait to move to the Phoenix > version of wxPython. True, I agree with Wayne - we need to wait until Phoenix is available in major Linux distros before we can even consider switching. Looking at your patch, I guess we could make KiCad compatible with both frameworks to assure smooth transition. Regards, Orson > The main issue is that the Phoenix equivalent of wx/wxPython/wxPython.h > (called from pcbnew/swig/python_scripting.h) exists, but isn't in the > releases yet. See here > <https://groups.google.com/forum/#!topic/wxpython-users/rIwPMKjQBeI>. > > Beyond that, I had some difficulties ensuring that the correct wx and > wxPython versions are installed and used[1] > > Once I did get it running, my kicad python scripts all work (save for the > things that broke since last time I updated kicad). > > > > > > Having said all that, I don't know that there is urgency to move to > Phoenix. AFAIK, wxPython 3.0 works fine with recent wxWidgets. > > > Hope it's helpful. > Miles > > PS - AFAIK, the patch that triggered mention of dumping python due to > wxPython still hasn't been denied or merged. :-) > https://lists.launchpad.net/kicad-developers/msg31700.html > > > > > > [1] on ubuntu, unstalling wxwidget package didn't remove the wxwidgets > libraries. It's quite possible that I was just confused and/or doing it > wrong. > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
