kicad-developers team mailing list archive
Mailing list archive
Re: Getting kicad to work with wxPython Phoenix
Maciej Sumiński <maciej.suminski@xxxxxxx>
Thu, 23 Nov 2017 18:04:30 +0100
spf=pass (sender IP is 188.8.131.52) smtp.mailfrom=cern.ch; lists.launchpad.net; dkim=none (message not signed) header.d=none;lists.launchpad.net; dmarc=bestguesspass action=none header.from=cern.ch;
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
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.
> 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
Description: OpenPGP digital signature