kicad-developers team mailing list archive

[Mark Roszko <mark.roszko@xxxxxxxxx>]

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

The goal is I wouldn't need to care. The engine and configurability is
really all I'm after and we should be able to swap out the actual
netlist logic with ease.
If I end up with a dependency on the netlist generation itself then I
should be shot.


>Please do not use XML for any kicad files.  Reading XML is painful.

I disagree on it being painful, I find s-expr painful because now you
get to play find the missing parenthesis in a line with 20 of them.
And XML is more fault tolerant of missing tags.
But let's ignore disagreement that and I'll go suffer with s-expr.

I can't use wxConfig because there will be arrays of options to display, i.e.

<options>
     <option>
          <name>Group components by footprint?</name>
          <type>boolean</type>
          <default>checked</default>
      </option>
      <option>
          <name>Excel BOM Template>
          <type>filepath</type>
      </option>
</options>

And doing arrays in a INI format is not probably worse than your
"reading xml being painful".


>Do you mean NETLIST::MANAGER::AddNetlistExporter() for every available netlist exporter?

Yes, every available exporter, its just a way of tracking and avoiding
the current superglobal. Every python script will be its own exporter
object for easily calling up in the dialog windows.



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

Hence the whatever extension part ;) It's a pretty small detail.