Modular KiCad with Alternate Top Level Launchers

Introduction:

Modularity in software leads to flexibility and simpler and faster
development of smaller components. Developers in a software suite can focus
on smaller portions of the overall software suite, rather than building and
maintaining a large monolithic link image. But when choosing the modular
approach, then inter-module communications must be considered in order for
the sum of the modules to provide the user with a cohesive solution.

Inter module communications within software is a vast area of study, and the
problems there have been addressed and solved in countless ways. This work
package does it once again, with the purpose of keeping things as simple as
possible, but not simpler. This design assumes that all modules are coming
from the same authors, understand each other, but for speed of development,
have been separated into separate link images, i.e. modules (DSO, DLLs,
bundles). The reason for the smaller modules rather than a larger link image
is for speed of development and simplicity of software re-use and
combinatorial flexibility and in process inter-module communications.

This KiCad work package describes the simplest solution and migration path
to that solution. It introduces only two very simple software interfaces:
the KIWAY and the KIFACE. The two work within the same process only. The two
are cross platform and are built using very simple existing wxWidgets APIs.

The KIWAY is an inter-DSO pathway used to both send messages and to retrieve
addresses. Address retrieval is the basis for exposing software interfaces. A
software interface that is built on virtual functions (accessible via
pointers) is one that you do not have to link to. Limiting what is linked
speeds software development. Limiting use of software to well defined
interfaces improves its design. The KIWAY lives in the program launcher,
near the top of the software stack and is available for use by the software
modules below it. The KIWAY is specific to a KiCad project, a set of
schematics and a board. A program launcher can maintain multiple KIWAYs, but
each is pertinent to only one project.

The KIFACE is an interface that sits at the top of each software module. It
is discovered by the program launcher and tied into a KIWAY for use by any
modules.

Portions of the KIWAY and the KIFACE are already complete and working so
this is not merely a fantasy.

1. End goals of work package:

   A) Produce stub loaders for pcbnew, eeschema, and cvpcb. These are very small link images (main programs) which load very much larger modules (DSO/DLLs): pcbnew.so, eeschema.so, and cvpcb.so, respectively. Usage of a stub loader is identical to current usage of the programs. This is only a step on the path to arrangement flexibility and in the incorporation of some interfaces between the loader and the subservient DSO. All the program functionality is in the module, and it is maintained and developed just like it is now. The stub loader gives a user command line access to the functionality within the major modules, and simpler debugging than the combined suites described below.

   B) Add KIWAY support to the wxWidgets project manager, aka "kicad", and become a module loader for pcbnew.so and eeschema.so. Complete the intermodule communications witin the KIWAY alchemy. The wxWidgets project manager will handle only a single open project at a time. This C++ project manager will remain useful indefinitely for debugging and maintenance of the C++ KIWAY support. However it is not the end all project manager.

   C) Write a new project manager in wxPython. This one will support multiple open projects and will maintain an open KIWAY for each project.

2. Milestones:

   A) Finish end goal A).

   In this form the stub loader will provide a dummy KIWAY to the DSO. On the topside of the DSO is a new interface called a KIFACE, which is used in each DSO participant of a KIWAY. One KIFACE is needed per DSO, although that same DSO can be a participant in multiple KIWAYs. But in the stub loader situation, only one KIWAY is active, and there is only one DSO active in the KIWAY, so this reduces down to a situation fairly close to what we have now in pcbnew for example: a single project, and no ability to talk to another top level window about the project except through files and sockets and footprints. Combine cvpcb.so into pcbnew.so, if this happens before the cvpcb stub loader, then don't write the stub loader for cvpcb, or the cvpcb stub loader can be made to load pcbnew.so and jump into the appropriate top level window (i.e. CVPCB_FRAME).

   B) Finish wxWidgets based single open project manager tasks for end goal B):

   1) Implement loading of a project's schematic, either as the first thing
   loaded into a KIWAY (project) or as subsequent to having loaded the
   board.
   
   2) Implement loading of a project's board, either as the first thing
   loaded into a KIWAY (project) or as subsequent to having loaded the
   schematic.
   
   3) Implement a KIWAY based replacement for the socket communications
   between eeschema.so and pcbnew.so, sometimes called cross probing.
   Comment out the socket based cross probing currently used.
   
   4) Add support for picking a footprint from the schematic component
   dialog. This entails a cross module invocation from eeschema.so into
   pcbnew.so, using exposed interfaces.
   
   5) Add support for editing a footprint from the schematic component dialog.
   

   C) wxPython tasks for end goal C):

   1) Create a swig bridge into the multi-project C++ KIWAY manager, so
   that modules can be loaded, hooked into the KIWAY on a project topic
   basis, and their top level window handles hooked into the top frame of
   the wxPython wxWindow.
   
   2) Hook DSO top level windows into the wxPython wxFrame as a children.
   
   3) Implement some simple project functions: create, open, destroy, copy,
   rename in python.
   
   4) Duplicate some of the "kicad" project manager's UI for loading
   schematic and loading boards.
   
   5) Develop menu based infrastructure to fire wxPython based utilities
   and plugins which are fully topside of any DSO involvement.
   
   6) Rethink the python scripting in view of python interpreter creation
   at the top of KiCad. Research python sub-interpreters and develop or
   find a C++ wrapper for sub-interpreter instantiation. Take a look at
   xbmc source code for possibilities.