← Back to team overview

kicad-developers team mailing list archive

Re: kicad github wiki


On 1/23/20 9:15 AM, Wayne Stambaugh wrote:
> The only other page is "Modular KiCad with Alternate Top Level
> Launchers". I'm not sure, but you might want to migrate this document
> to gitlab.

Two of the 3 launchers have been implemented.

The one not implemented is a python project manager.  What my vision for that was
primarily was two fold:

1) Easier extension of UI features for non C++ developers.

2) Finally capitilizing on the "class PROJECT" data aggregation so that multiple projects
could be open at the same time.

3) Create competition within the project, at the project manager level.  This was on the
theory that competition breeds success.  We see it in Linux Desktops, and elsewhere.
Mutual exclusion is not a requirement.

(I have never taken to the "C++ invokes python" construct.  I think a "python invokes C++"
construct is more elegant and simpler.)

When I started working on phase III of the modular KiCad design, I got road-blocked by the
radical departure of wxPython from SWIG.

But as I recall, the trick to getting it started again is to develop a python callable
interface to KIWAY.  Because this lets you open the wxFrames in C++ after execution
arrives in C++ at the KIWAY layer.

That is, speaking approximately, the trick to getting this to work is to create the python
mapping to the C++ class KIWAY.  Make


or SIP equivalent functional.

Then you can simply load a PCBNEW or EESCHEMA wxFrame similar to how SingleTop does.

Holding multiple concurrent projects would be nice, but you will have to deal with
multiple open copies of any library opened by more than one project.  This probably means
referencing the libraries from more than one place rather than including all open
libraries in the PROJECT instance.  Shared pointer or something like that.

I know there are some python enthusiasts and gurus out there, take this ball and roll with
it if you want.  Maybe it snowballs.