* Created separate SVN version header.
* Add true config.h for platform dependency checks.
* Add dependency check cmake module.
* Remove some leftover hand crafted make files.
* Remove non-cmake build instructions from COMPILING.txt.
* Fix split _() strings causing Visual C++ compiler error.
* Fix lots of compiler warnings.
* Change project file parameter container from wxArray to boost::vector_ptr.
* Removed lots of redundant header definitions.
* Fixed green_xpm redefinition in ercgreen.xpm.
* Remove some dead code and unnecessary class methods.
pads option.) Haven't fixed the via issue
(since I don't quite understand why it is doing this, nor does it occur in 100% of the cases), but now you can just
turn
off magnetic tracks when I desire to move vias by small increments. Magnetic tracks are on by default. Original
via complaint here:
http://tech.groups.yahoo.com/group/kicad-devel/message/1155
Also mostly gotten rid of the annoying "Unable to drag this segment: two collinear segments" error. Now, if two
(or more) segments are collinear, they are merged into one equivalent segment when you try to drag them while
maintaining slope. I can't imagine any cases where this would be a bad thing (and I have plenty of experience where
the error was not desired!). Note I say *mostly* because there still seem to be some length=1 (e.g. 0.003mm) segments
at the end of valid-length segments. I do not want to remove them because this would change the board layout, though
in a basically imperceptible way. We could maybe have an option to clean & remove these minimal-length segments, but
I worry that they serve to connect things slightly off grid & those things on-grid; also, removal may cause DRC
errors. It would be good if we could avoid their creation.(?)
================================================================================
+eeschema
* commiting my changes to allow multiple instances of a given schematic file within
a hierarchy:
** internally, m_currentScreen has been replaced with m_currentSheet,
which is a list or 'path' of screens. The path of screens is used to
generate
a series of timestamps, which is converted to flat component reference via
a look-up
table in the schematic files.
** this means that m_currentScreen is no longer used -- use GetScreen().
** GetScreen is virtual, as some of the dialogs keep around a WinEDA_BaseScreen
pointer.
** all sub-sheets in a given schematic must have different names to generate a
meaningful netlist.
charras