* Create separate NETLIST object to hold contents of netlist files.
* Read entire netlist and footprint link files before making applying
changes to board.
* Add BOARD::ReplaceNetlist() function to eliminate the calls between the
NETLIST_READER, PCB_EDIT_FRAME, and BOARD objects.
* Change placement of new components below the center of the current board
or in the center of the page if the BOARD is empty.
* Add dry run option to netlist dialog to print changes to message control
without making changes.
* Add button to netlist dialog to allow saving contents of message control
to a file.
* Eliminate the need to compile netlist_reader_*.cpp in both CvPcb and Pcbnew.
* Add netlist_reader_*.cpp to the pcbcommon library.
* Remove redundant load component link file code from CvPcb.
* Modify CvPcb new to work with the new NETLIST_READER object.
* Add compare() function and < and == operators to FPID object.
* Add REPORTER class to hide an underlying string writing implementation for
use in low level objects. Thank you Dick for the idea.
* Lots of minor coding policy, Doxygen comment, and missing license fixes.
Moved switching canvas routines to pcbnew, as they are used only there right now (otherwise libgal would have to be linked to every Kicad application).
Pcbnew: load footprint from modview: Because modview allows user to choose the footprint library, the selected library is forced when the footprint is loaded.
I am not sure this is 100% better, but this new behavior has some advantages, mainly in the footprint editor (you can load a footprint outside the selected library)
bit string version of property_tree. The ram resident structure of the ptree is
mostly compatible with one created using the xml_parser from
boost::property_tree, with slight differences in the way atoms are stored. The
result is you can use Format() to convert from xml to s-expression, but not the
other way around. You can write a simple s-expression beautifier in just a few
lines of code.
The main value however is the s-expression parser, i.e. Scan(), which is an
alternative to crafting a custom recursive descent parser for a particular
grammar. The tipping point depends on whether you want to read only a small
portion of a much larger document. If so, then using the ptree will likely be a
"faster to code" route. Documentation on how to navigate a ptree can be found on
the boost website and there are a number of examples in the
pcbnew/eagle_plugin.cpp file in this project. Powerful path navigation support
makes it easy to extract a subset of a ptree.