kicad-developers team mailing list archive
Mailing list archive
Re: Getting kicad to work with wxPython Phoenix
On 11/23/2017 12:04 PM, Maciej Sumiński wrote:
> 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
>> 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
>> a diff file of my changes is here:
> 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.
This would be a big win for the project if the python scripting code
could be ready to go when phoenix becomes widely available. It would be
nice to be able to use python 3 instead of python 2.
>> 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
>> Beyond that, I had some difficulties ensuring that the correct wx and
>> wxPython versions are installed and used
>> 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.
>> PS - AFAIK, the patch that triggered mention of dumping python due to
>> wxPython still hasn't been denied or merged. :-)
>>  on ubuntu, unstalling wxwidget package didn't remove the wxwidgets
>> libraries. It's quite possible that I was just confused and/or doing it
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp