kicad-developers team mailing list archive

[Mark Roszko <mark.roszko@xxxxxxxxx>]

I am hoping this is separated enough from any eeschema refactoring
Wayne plans on doing by shoving it in its own corner :)

1. The goal is to make external user plugins more "powerful".
Currently you need a python/xslt file PER possible output
option...i.e. csv with grouped parts vs. csv with independent parts.
This isn't the most user friendly.
2. Plugins will gain/maybe require a "knet" (or whatever extension)
config file in xml format.
Inside it will define
- Author
- Script Version
- Array of UI options in a standard format allowing for checkboxes,
dropdowns and text inputs, and also normal text labels to add
descriptive text if needed


3. A flow I am imagining:

NETLIST_MANAGER will be instanced inside the SCH_FRAME

On startup of eeschema. Somewhere in an appropriate spot the following
will be called

NETLIST_MANAGER::RegisterEngine(NETLIST_ENGINE_PYTHON)
NETLIST_MANAGER::RegisterEngine(NETLIST_ENGINE_INTERNAL)


NETLIST_ENGINE_PYTHON and NETLIST_ENGINE_INTERNAL will both derive
from NETLIST_ENGINE


Inside register engine, they will call NETLIST_MANAGER::AddNetlist()
for every available netlist
In the Python case:
Search \netlist\python\ folder for *.knet files and matching *.py files
In internal case
Register fixed class references to the existing NETLIST_EXPORTERS_* we have

The "netlists" registered will derive from a NETLIST_TOOL class



Now when a user goes to the netlist dialog. The dialog window will
request from NETLIST_MANAGER::GetNetlists().
It will iterate through and populate the avaliable netlists.

For each netlist it will request from the
NETLIST_EXPORTER::GetOptionsForm which will return a reference to a wX
panel
that holds all the translated from config file options. This panel
will be used in the dialog window.


Once a user selects what they want and presses Netlist. The dialog
window will call NETLIST_ENGINE::Generate( NETLIST_TOOL reference,
netlist_options )

The engine will now invoke the proper logic to generate the netlist,
in the internal case it simply translates the options to the boolean
flag system we have for now.
 In the python case it'll translate the options to a command line arg
string and call the system python.


4. Why a NETLIST_ENGINE_PYTHON?
The goal is to allow multiple engine types, i.e. NETLIST_ENGINE_RUBY,
NETLIST_ENGINE_PERL which will all handle formatting the execution
lines for the respective languages and any additional baggage that may
be required. It should be relatively light weight. They can then
handle error output specific to their scripting languages easily.
After that, we just have a few "official" scripts and then sit back
and relax as users make their own stuff.

Note, this does not aim to use SWIG python bindings or anything like
that, but rather integrate with system tools. Could it be changed
later for the python binding stuff? Maybe, but this is the "first
step".


5. What about BOMs?
Because BOMs are generated from the detailed kicad netlist, it'll be
extremely similar. The search path will probably be different, i.e.
\bom\python. There will probably be a derived BOM_MANAGER from
NETLIST_MANAGER and the same for BOM_TOOL, etc. Lightweight container
classes.


6. What about xslt?
Well, a really good case can be made that XSLT is really hard to write
even though its turing complete and so support should be dropped in
favor of python and other languages.

7. One possible issue I have is figuring out how to serialize selected
options to kicad's config file for storage as the "last used
settings". Not a huge issue to solve just annoying.