kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Attachment: signature.asc
Description: OpenPGP digital signature