kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

You may want to wait until after I commit my eeschema refactor changes
after the stable release.  Otherwise, there will most likely be large
merge conflicts.  Virtually all of the code I am refactoring effects the
NETLIST_OBJECT, NETLIST_OBJECT_LIST, SCH_SHEET_PATH and SCH_SHEET_LIST
code.  All of which are used to generate the netlist.  You might be able
to work on the your engine manager code but anything that touches these
objects will go through a major upheaval during this transition so you
may have to fix a lot of merge conflicts.

On 11/4/2015 10:51 PM, Mark Roszko wrote:
> 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.

Please do not use XML for any kicad files.  Reading XML is painful.  We
have standardized on an s-expression style file format and have syntax
generation, parser, and formatter code already in place which is proven
and robust.  The generic netlist is in XML because it is intended to
only be used as an intermediate file for post processing.  Our actual
netlist is in the s-expression format as is the board, footprint
library, fp-lib-table, and worksheet files.  At some point eeschema,
symbol libraries, and the project file will be converted as well.  The
other valid option would be wxConfig file format if it is a
configuration file which this may be.

> 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

Do you mean NETLIST::MANAGER::AddNetlistExporter() for every available
netlist exporter?  There is only one netlist for the currently open
schematic.

> In the Python case:
> Search \netlist\python\ folder for *.knet files and matching *.py files

We've been moving to .kicad_xxx file extensions.  Please follow this
naming convention for consistency within the project.

> 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.

I don't know that anyone will miss the XSLT stuff as long as there is an
equivalent exporter in python or some other language.

> 
> 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.

Look at the path configuration config file code I wrote in
PGM_BASE::loadCommonSettings() and PGM_BASE::saveCommonSettings() in
common/pgm_base.cpp for an example of how to serialize to and from a
config file.  This will save you some time.  It's not difficult but it's
not very well documented.  I had to dig through the wxWidgets source to
figure out how to do it.

All in all, your proposal seems reasonable.  Of course it's always
easier to evaluate actual code than written proposals.  One thing that
would help me is to create some skeleton code using well documented
header files before you actually start writing any code.  This would
give me an idea of how the code is structured.

> 
> _______________________________________________
> 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
>